Making precise slow speed station stops (automation)

[David]

For the eventual layout a major component will be automation - I want a lot of other traffic moving on its own, making station stops and generally behaving in a realistic manner.

 

To make a station stop I need to combine 3 elements:

 

* Trains of varying length need to be able to come to a complete stop at a set point, with a maximum various of 5mm. If Densha de Go has taught me anything it's that you lose a lot of points for overrunning a station.

 

* Trains should not come to a sudden stop, they should slow down gradually and smoothly. Densha de Go has also shown that you can't slow down too fast, or you'll waste a lot of time coasting along the platform. You also lose points if you have to speed back up again because you undershot the end.

 

* It has to be economical. Platforms will already cost a lot due to turnouts, the platform itself, and TomyTec figures. Another $150 to install 8 detection zones is not good, assuming they even perform well packed in that close.

 

Obviously detection zones, based on a load (the train) being placed on an isolated section of track, are the basic building block for automation. But I think something more clever is needed for the stations. Optical detection comes to mind, but neither of the two options seem good: Embedded in the track it can detect a passing train, but that brings us right back to cost because of the quantity. In theory IR and similar optical systems can do range finding, but I think this has been shown to be impractical for precise control at this scale.

 

I got one idea watching video of the new TomyTec bus system and how it was able to stop precisely inside the painted lines of the bus stop. That system uses magnets and reed switches. What if we placed reed switches under the track, and a magnet in the cab cars? (the motor car might also accidentially project a magnetic field). If the microcontroller component could be done cheaply enough it could be used to provide a large number of detection spots to plot the exact position of a train (we can assume the train is traveling in one direction only) on the platform track.

[inobu]

Automation = computerization.  

Economical DCC computerization = JMRI.  

Precision speed control =speed table mapping.

Station to station automation = scripting.

 

You can script your trains route and manage its starts and stops by time based scripting. Scripting allows you to write DCC commands that will execute in time intervals which can be synchronized with the stations train schedules.

 

Programming the deceleration trim will allow you to pin point the precise time to enter the stop command resulting it a consistent stopping point along the platform.  

[Martijn Meerts]

If you only want single direction travel, and want all trains to stop at the exact same spot, all you need is 2 occupancy detectors per block. Depending on which digital system you use, 2 occupancy detectors aren't all that expensive.

 

The problem I've had with read switches before, is that they tended to get stuck, making them unusable. Also, if you hide them under the track, and hide the magnet inside a car, you'll probably need fairly strong magnets.

 

 

There's various options for computer control. JMRI is one, but there's also RocRail (free) and iTrain (low price). Obviously, there's bigger ones, but they're overly expensive ;)

[CaptOblivious]

I've been thinking some about this problem too. A couple things I've considered:

 

An array of IR-LED/detector pairs placed under the station platform, facing the track. If you used several, you could keep on the actual speed and position of the train. Might be visible, though the LED and detector would only need a small hole drilled in the side of the platform. If they are positioned so that they see the trucks only, you can get a fairly accurate and fine-grained measure of speed and deceleration.

 

Option two, for increased hidability: Magnets in trucks, hall-effect sensors inside platform, facing trucks. More reliable (and more expensive) than reed-switches, hall-effect sensors are pretty cool, and provide an analog output suitable for a very small amount of range-finding (maybe a few mm in either direction, which would be all that you need for precise placement at the platform end).

 

After that, it's up to you how you process those signals. An Arduino would be an ideal candidate, I think, for processing them and passing them on to JMRI or the like. The smallest Arduinos can easily be hidden inside the platform.

[The_Ghan]

If you only want single direction travel, and want all trains to stop at the exact same spot, all you need is 2 occupancy detectors per block. Depending on which digital system you use, 2 occupancy detectors aren't all that expensive.

 

Why two?  I'm setting up my layout for occupancy detection (Digitrax BDL-168s) but the wiring diagram supplied shows one detector per block.  Further, I can't fathom how two detectors per block might operate differently.

 

I'm also interested in this topic and plan to automate trains stopping at stations.  I was hoping that I can just do this with JMRI or TrainController.  No?

 

Cheers

 

The_Ghan

[Martijn Meerts]

If you only want single direction travel, and want all trains to stop at the exact same spot, all you need is 2 occupancy detectors per block. Depending on which digital system you use, 2 occupancy detectors aren't all that expensive.

 

Why two?  I'm setting up my layout for occupancy detection (Digitrax BDL-168s) but the wiring diagram supplied shows one detector per block.  Further, I can't fathom how two detectors per block might operate differently.

 

I'm also interested in this topic and plan to automate trains stopping at stations.  I was hoping that I can just do this with JMRI or TrainController.  No?

 

Cheers

 

The_Ghan

 

Just 1 would work as well, but gives you no precise control of where the trains stop. Also, trains will get different running characteristics over time, meaning that if they stop where they should initially, after several months of running they might start driving faster or slower, which in turn means they'll stop at a different spot. Some software allows you to get around the issue though, by adding 1 or more speed traps, where the train speed is constantly measured and updates in the software.

 

If you use 2 detectors, the first one would be the brake section where the train starts to slow down to minimum speed. The 2nd one would be the stop section, where the train stops. Obviously, with a stop section, you'll be a lot more certain where the train stops.

 

 

Not sure about JMRI with regards to complete automate a layout, but I would expect it's possible. With TrainController it's definitely possible.

[David]

The software side isn't a problem, JMRI provides an open API for using a Digitrax PR3 or other DCC-Computer interface, I can provide the rest (that's part of the fun). My main concern is what Martijn Meerts talks about, the fact that ideal stopping distance based on a series of blindly issued speed steps, and actual reality (temperate, motor wear, wheel slip, track pickup, missed packets) are not the same. It reminds me of some high school robotics - making the assumption that if you timed how long it took for the robot arm to make a 1 degree turn, you could accurately move it without any sensor feedback. There is a reason specialized motors (servos) exist.

[The_Ghan]

Just 1 would work as well, but gives you no precise control of where the trains stop. Also, trains will get different running characteristics over time, meaning that if they stop where they should initially, after several months of running they might start driving faster or slower, which in turn means they'll stop at a different spot. Some software allows you to get around the issue though, by adding 1 or more speed traps, where the train speed is constantly measured and updates in the software.

 

If you use 2 detectors, the first one would be the brake section where the train starts to slow down to minimum speed. The 2nd one would be the stop section, where the train stops. Obviously, with a stop section, you'll be a lot more certain where the train stops.

 

Not sure about JMRI with regards to complete automate a layout, but I would expect it's possible. With TrainController it's definitely possible.

 

Hmmm ... I'm thinking of going with TrainController, but it's expensive.  I've already downloaded the demo and I like the way it works.  With regard to speed traps I would imagine (and I'm not this far into it yet) that a speed trap can be set across multiple blocks using one detector per block ... I shall explore, but I take your point.

 

Cheers

 

The_Ghan

[Dani]

I'm doing some tests with Rocrail (it's all for free!! and also has Androc to take the control from your Android phone!!!!):

 

* I have one detection zone at the begining of the station (one for all tracks) (ZONE A)

* I also have one detection zone in each track of the station, all at the same distance of the end of the track (ZONE B)

 

With RocRail you can setup all trains entering ZONE A to reduce the speed at V_mid or V_min softly following the inertia of the loco. (V_min and V_mid is configured particulary in each loco parameters)

 

When the traing enters in ZONE B, Rocrail can order to stop this loco, but following the special configuration of each loco. Each loco can be configured with a delay time before stopping, so you can compensate the different inertias and speeds to make all them to stop in the same distance.

 

I'm testing this for my layout right now, but theoreticaly it can be done without problems.

 

Hope this helps.....

[Martijn Meerts]

The software side isn't a problem, JMRI provides an open API for using a Digitrax PR3 or other DCC-Computer interface, I can provide the rest (that's part of the fun). My main concern is what Martijn Meerts talks about, the fact that ideal stopping distance based on a series of blindly issued speed steps, and actual reality (temperate, motor wear, wheel slip, track pickup, missed packets) are not the same. It reminds me of some high school robotics - making the assumption that if you timed how long it took for the robot arm to make a 1 degree turn, you could accurately move it without any sensor feedback. There is a reason specialized motors (servos) exist.

 

I believe it's Railware that first came with the whole 1 detector per block is enough, because their software was intelligent enough to stop trains exactly where you wanted them to stop. They forgot to mention (in their marketing) that this depends on the actual speed of the train, and the speed will definitely vary. Add 2 cars and your speed will already be different, albeit very slightly.

 

 

Just 1 would work as well, but gives you no precise control of where the trains stop. Also, trains will get different running characteristics over time, meaning that if they stop where they should initially, after several months of running they might start driving faster or slower, which in turn means they'll stop at a different spot. Some software allows you to get around the issue though, by adding 1 or more speed traps, where the train speed is constantly measured and updates in the software.

 

If you use 2 detectors, the first one would be the brake section where the train starts to slow down to minimum speed. The 2nd one would be the stop section, where the train stops. Obviously, with a stop section, you'll be a lot more certain where the train stops.

 

Not sure about JMRI with regards to complete automate a layout, but I would expect it's possible. With TrainController it's definitely possible.

 

Hmmm ... I'm thinking of going with TrainController, but it's expensive.  I've already downloaded the demo and I like the way it works.  With regard to speed traps I would imagine (and I'm not this far into it yet) that a speed trap can be set across multiple blocks using one detector per block ... I shall explore, but I take your point.

 

Cheers

 

The_Ghan

 

Traincontroller is a good program, but as you said expensive. With the latest release and the bronze, silver and gold versions it seems to be better at first glance, but when you check the features for each version, you'll quickly come to the conclusion that in many cases the gold version is the only thing that works well ;) You could have a look at RocRail, which is similar to Traincontroller, but it's free. It's not (yet) as advanced as Traincontroller, and it's definitely not as easy to use, but might be worth having a look.

 

 

I'm doing some tests with Rocrail (it's all for free!! and also has Androc to take the control from your Android phone!!!!):

 

* I have one detection zone at the begining of the station (one for all tracks) (ZONE A)

* I also have one detection zone in each track of the station, all at the same distance of the end of the track (ZONE B)

 

With RocRail you can setup all trains entering ZONE A to reduce the speed at V_mid or V_min softly following the inertia of the loco. (V_min and V_mid is configured particulary in each loco parameters)

 

When the traing enters in ZONE B, Rocrail can order to stop this loco, but following the special configuration of each loco. Each loco can be configured with a delay time before stopping, so you can compensate the different inertias and speeds to make all them to stop in the same distance.

 

I'm testing this for my layout right now, but theoreticaly it can be done without problems.

 

Hope this helps.....

 

 

My hidden yard is set up like this. 1 common detector for each of the hidden yard tracks, and than 1 detector for where the train has to stop. The disadvantage of this system is that it only works in 1 direction (unless you add the same system for trains traveling the opposite direction, but that defeats the purpose.

 

 

 

A while ago I did some posts about setting up blocks for computer control, it's al fairly rough and basic, but it might help some people:

 

- Part 1: http://www.jnsforum.com/index.php/topic,370.0.html

- Part 2: http://www.jnsforum.com/index.php/topic,372.0.html

- Part 3: http://www.jnsforum.com/index.php/topic,403.0.html

[gavino200]

I'm wondering if anyone has made progress with the problem of making precise stops? Did it turn out that this can be well with blocks alone? Or are people using optical detectors instead. I have a little experience using optical detectors for a DC reversing loop. I've found them to be reliable and relatively easy to use. They could be hidden in the track bed fairly easily. I have been assuming that automation with precise stops would require both blocks and optical detectors. Anyone having a reliable experience with precise stops without sensors?

 

[Madsing]

I have not played with automation for a while, but iirc I could achieve 1~2 cm accuracy on the stop position with block current detection alone. Each of my blocks are divided into 3 zones, A, B and C. A and C are fitted with current sensors. Depending on the direction, the train will enter the block from the A side or the C side. If it enters from the A side, it starts to decelerate when the A current sensor is triggered. By the time it reaches the C zone on the other side of the block, the train speed is very low and it will stop very quickly as soon as the C current sensor is triggered. Same for the other direction but with the A and C sensors swapped.

In Rocrail, there is even a feature called BBT Block-Brake-Timer which, after a calibration procedure, automatically decelerates the train linearly from the A to the C sensor without relying on the DCC decoder deceleration (https://wiki.rocrail.net/doku.php?id=loc-bbt-en).

[Martijn Meerts]

8 hours ago, gavino200 said:

I'm wondering if anyone has made progress with the problem of making precise stops? Did it turn out that this can be well with blocks alone? Or are people using optical detectors instead. I have a little experience using optical detectors for a DC reversing loop. I've found them to be reliable and relatively easy to use. They could be hidden in the track bed fairly easily. I have been assuming that automation with precise stops would require both blocks and optical detectors. Anyone having a reliable experience with precise stops without sensors?

 

 

There are various ways to achieve it. The most secure way is still to have a separate detected stop section. At least then you'll always know the train will stop at the same position. Depending on the first set of wheels that are detected of course.

 

Software has also gotten a lot better though, so you can get really good results with a single occupancy sensor per block. For example, in iTrain (which I've been using for a while now, pretty sure other programs can do the same), you can specify where in a block a train should stop. So, if a block is 1 meter long and your signal is positioned 5cm before the end of the block, you can specify that the stop position should be say 85cm (or -15cm). Based on the train's length, speed, type, etc, iTrain will slow down the train, and come to a stop at 15cm before the end of the block / 10cm before the signal.

 

This does have some requirements though, all the blocks need to have their lengths added to iTrain, as well as have the stop position specified. Also, all trains need to have gone through a speed measurement so iTrain knows how fast a train runs per decoder step. These measurements might need to be redone once in a while, since driving characteristics and speeds will start to change once the motor starts to wear out. The length of the trains also needs to be specified, as well as the distance between the bumpers and the first axle that causes an occupancy detector to fire. The acceleration and deceleration in the decoder also needs to be turned off (I believe it's CV4 and CV5, both of which should be set to 0)

 

It's a bit of a task initially, but it does allow for some interesting operations. For example, a train can be set to stop either at the end of a platform, or if you have short train, at the center of the platform. Also, in iTrain you have both locomotives and trains. A train can have any locomotive, so if you do some shunting and hook up a different loco to a train, the length will automatically be adjusted as well. You can even split a train into 2 parts, and each part will have its own length.

 

 

Personally, I'm going for a combination. All my single direction blocks have a entry sensor and a stop sensor, all my multi direction blocks have 3 sensors (2 entry, and a center sensor). I will however also specify all the lengths of the blocks. That way, iTrain can determine where a train should stop, but I still have the stop section as backup in case a train overshoots the stop position.

[gavino200]

3 hours ago, Martijn Meerts said:

 

Personally, I'm going for a combination. All my single direction blocks have a entry sensor and a stop sensor, all my multi direction blocks have 3 sensors (2 entry, and a center sensor). I will however also specify all the lengths of the blocks. That way, iTrain can determine where a train should stop, but I still have the stop section as backup in case a train overshoots the stop position.

 

Thanks for the information, Martjin. I think I'd like to incorporate sensors. Especially for the holding yard. It wouldn't take much inaccuracy for a train to hit the buffer at the end of the line and derail itself. 

 

What kind of sensors are you using? Do they plug directly into your ECos system or do you have a separate electronic setup for them?

[Martijn Meerts]

I currently use occupancy detectors from Littfinski, they're based on the s88 occupancy detection bus. For now I have them going directly into the ECoS, however, I recently ordered a uCon s88 master, which allows me to hook up the occupancy detectors directly to the computer via a network interface. I have also ordered one of the 16 port Digikeijs occupancy detectors, but not tried it yet.

 

The s88 master has 3 ports, so you can have 3 chains of occupancy detectors instead of a single one. This has some advantages, like allowing more sensors / detectors, and you can split the layout a bit. For example, 1 chain for a yard, 1 chain for a local line and 1 chain for a shinkansen line. In my case, I'll use 1 chain for the helix and yard, which use the Littfinski detectors, 1 chain for the large station area using the Digikeijs detectors, and 1 chain for much of the rest of the layout.

 

[Kiran]

Optical sensors have their own advantages. They can be very useful for making exact stops but I decided to use short detector blocks at the ends of a larger block. The good thing about current based detection is that they don't need an additional power source. But one has to make sure that that the first and last cars of the train are definitely drawing some power. Usually this is not a problem for push pull trains because of the head and tail lights draw enough power for the sensors to trigger. I do have some trains like Amtrak carriages which don't have a tail light but this can be easily fixed by adding interior lighting to the carriages. In the worst case scenario, resister wheelsets is an option too. Something like JMRI can start slowing down the train when it hits the longer block and as soon as it hits the shorter block, the train can come to a stop. In JMRI at least, I used scripts for each of my trains. I am not sure if there is a GUI-based way of doing this with JMRI/other software packages.