Skip to main content

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.

Original Post

Replies sorted oldest to newest

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

 

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.

Now that I have sometime I thought it would be interesting to set up and use the record and play back feature. I have TIU with a WIU and topped off with an AIU. I have downloaded the MTH APP and paid for the full upgrade. Everything works so no issues there. I tried to use Barry's book and he talks about using  the thumb-wheel to access this feature which there is not one on my tablet. 

I have looked or thought I have for a way to use this feature. If someone know a link or some sort  directions on how to do this I would really appreciate it.

Thanks Arnold

Add Reply

Post
The DCS Forum is sponsored by

OGR Publishing, Inc., 1310 Eastside Centre Ct, Suite 6, Mountain Home, AR 72653
800-980-OGRR (6477)
www.ogaugerr.com

×
×
×
×
Link copied to your clipboard.
×
×