I have been playing and experimenting with the DCS Record-Play feature.  It is challenging to get all the steps executed correctly during the RECORD process.  However, I have noted upon playback, even when started from a precise mark on the track,  that the engines gradually come up "short" when pinpoint locations are required for an accessory load/unload operation.  I am trying to figure out how to compensate for this error.  I realize the longer the route is, the more error that is introduced.  You can't just give the engine a few inches "head start" because events early in the session then will be off.  What has been your experience in attempting to compensate--is the error repeatable and predictable?  I assume distance is internally measured by counting total revolutions of the flywheel motors.

Gary Liebisch

Columbus, OH

Super 'O' since 1958!

Original Post

I have never had luck with an engine starting and stopping, or executing some command, at an exact spot on any of my 9 PS2 and 2 PS3 engines.  I no longer even try to use it.

It will never work that good... There are way too many variables that the system can't compensate for... the biggest one being wheel slip. 

I do use macro record feature quite frequently to perform common switching tasks and engine swaps.  Just make sure everything is in the right spot when you begin. 

H1000

Here's where I cast my wish again.  Inexpensive sensors which you can embed in your existing track which are wired to an I/O board which handles multiple sensor sets.  The I/O boards talk to a master DCS interface board.  The master interface board handles multiple I/O boards.  Software should be able to control anything connected to your DCS.

Steve

shorling posted:

Here's where I cast my wish again.  Inexpensive sensors which you can embed in your existing track which are wired to an I/O board which handles multiple sensor sets.  The I/O boards talk to a master DCS interface board.  The master interface board handles multiple I/O boards.  Software should be able to control anything connected to your DCS.

@SanDiegoMark may have exactly what you want. Check out this thread: https://ogrforum.ogaugerr.com/...omatic-train-running

 

H1000

Multiple RFID readers can get quite expensive for a larger layout.  I settled on positioning RFID readers at defined entry points where trains would enter the main line, and then tracking the train's progress with traditional third-rail sensing.

That approach can't track complex moves of the train by an operator (like reversing), but works fine for automated operation.

Gary Liebisch posted:

... I assume distance is internally measured by counting total revolutions of the flywheel motors.

Which of course explains why it's a metaphorical fool's errand to use the record function to precisely position the engine after multiple loops over time since errors will accumulate.  This is the same headache the DCS trolley/subway guys have trying to automatically stop right at the station platform after multiple loops over time.

The sky's the limit if you are willing/able to add sensors and write software for a computer-based system.

But if computer-based control is not in your comfort zone there have been sporadic discussions of non-software alternatives for DCS users.  Specifically, the problem is how to automatically stop a DCS (command control) engine in response to some position based event...in this case being at the exact unload point for dumping coal, logs, whatever.  The most common example I've seen is to stop an engine for block control or when approaching a drawbridge in the "up" position.  There are 2 solutions that I'm aware of.  1) reduce the track voltage to a voltage that is enough to keep the engine alive (i.e., DCS electronics does not shut down) but not enough to spin the motor.  This is a tricky affair with your-mileage-may-vary results.  Or, 2) insert a relay in the engine to cut power to the motor(s).  The relay is controlled by some external trigger like a light bulb in the track bed or whatever.  The track voltage stays at full command voltage but the engine stops, the engine sounds will go to the idle engine sound even if the electronics is trying to drive motor.  That is, in DCS the engine sounds are based on the flywheel activity rather than the commanded engine speed.

So, addressing the OP's specific application, the idea would be for the recorded program to activate an AIU output to enable the stopping trigger (e.g., the lightbulb in the track bed).  If going slow enough, removing motor power to a DCS engine will reliably stop the engine within an inch or so every time.  That is, the record-play would command the engine to go, say, 1 foot past the desired stopping point and the trigger-relay mechanism would stop it right on the dime so to speak.  There would be no accumulated error after multiple loops.  To be clear, this requires a modicum of DIY'er persistence though the actual cost would be modest compared to a computer-based system.

 

Last edited by stan2004

Here is a "workaround" I have discovered.  It is possible to override the playback of a session with additional manually enter commands.  So if a train stops "short" of its desired spot by several inches, and if you leave a suitable gap before the next recorded command is executed, you can take control of the engine and creep it up to where it was supposed to stop.  Of course reverse is also possible, but looks sloppy on execution.  It may even be better to program in the stop to be intentionally "short", so that the manually executed "creep" will always be in the forward direction. If you leave an extra 30 sec or 1 minute gap to perform these manual maneuvers, the train will then pick up the next programmed (departure) command at the end of your gap.  In my case, I was trying to get the Lionel 3469 Dump car to stop in the very narrow window that the 497 coal loader requires.  Leaving a 45 sec. gap after the train stops allows me to manually position the car before it dumps.  This technique also has the added advantage of correcting where the train"should be" if accumulated creep up to that point in the playback needs correction.

Gary Liebisch

Columbus, OH

Super 'O' since 1958!

Add Reply

Post
The DCS Forum is sponsored by
OGR Publishing, Inc., 1310 Eastside Centre Ct, Suite 6, Mountain Home, AR 72653
330-757-3020

www.ogaugerr.com
×
×
×
×
Link copied to your clipboard.
×
×