Accurate stopping of trains in RailMaster programs

[TrainDriverJ]

I would like to be able to stop and start trains accurately with eLink and RailMaster. I am given to understand that if I program a train to an outer destination and return and then repeat this several times the train fails to stop at the exact same place. This would be a shame as it is exactly why you would introduce programming.

 

Obviously there must be a variable if exactly the same train is used and the time is the same. I suppose whatever it is may or may not be overcome. Perhaps it is the DCC signal or locomotive mechanism? Has anybody experimented?

[Chrissaf]

I believe this can be a more noticeable problem with sound equipped locomotives. The loco goes through a sound sequence before moving off. Some sound sequences can have a random element to them. Even if the moving off delay from what has been scripted is no more that 100ms, it only takes 10 repeats of the automated train movements each with a delay element in them for the whole script to get 1 second out of sync. A locomotive can travel a fair way in 1 second.

.

I should point out that I don't use RM program scripts. So have no practical experience to base this statement on, but loco creepage via program scripts has been reported on the forum a few times in the past, thus my theory has a basis in logic.

[Chris Surrey]

Accurate stopping of locos is something I would like too. As well as the sound issue mentioned by Chris, there are many other potential interruptions that can affect the timing of a loco such as momentary loss of power due to dirty track,  minor speed changes with differing wagon or carriage loads. The only way to resolve these variables is for the system to know where a loco is and stop it where required - ie loco detection. Until this is forthcoming, true automation remains a pipedream. 

[St1ngr4y]

Hi guys,

I completely agree with Chris (Surrey) that LD would be the best answer for accurate stopping of trains. However in the absence of this, I would like to mention two techniques which I have used on my layout to improve the accuracy of stopping trains in the correct places.

Like yourselves, I find that running trains under program control can produce different results from day to day, for some of the reasons you have mentioned, but also, even different temperatures from day to day. The first thing I would mention, before describing the two methods in detail, is that I always use the decelerate command in programs to prepare for a stop. I find this much more reliable and realistic than using the deceleration CV value in the loco decoder.On my layout, the places where I want my trains to stop fall into two categories - hidden sidings and visible places like station platforms, goods yard, engine shed sidings.

For the hidden sidings, realism of deceleration isn't necessary, so as soon as the last visible part of the train has entered the tunnel, the program immediately issues a Forward to Shunt command to reduce the train to a crawl quickly. The next part of the process is achieved by electrical wiring. I have 8 hidden sidings which are all bi-directional and fan out at each end via electrofrog points. This means that each siding already has an Insulating Rail Joiner at each end where the electrofrogs are situated. By putting a second IRJ on the same running rail just over a loco's length further down the siding, you can make a stopping zone by arranging to have this isolated section of rail switched off when a loco enters it. When ADS2FX accessory decoders were first introduced a few years ago, some of those I bought stopped working and I had to have them replaced. However, one of the broken ones I kept, because I noticed that, although the solenoid outputs were frazzled, the onboard latching relays were still working, and therefore the frog polarity switching terminals were still operative. By using the centre and one of the outside terminals of the frog polarity set, I could use each port on the decoder as a simple on/off switch. The following diagram looks complicated, and I apologise for that. I have included only two of my eight hidden sidings, but it shows the isolated sections at each end of each siding.

/media/tinymce_upload/765d94fe6f8609263a050f80d73e0c9d.png

I have used blue and yellow in the diagram to show the polarity of each track, and you will see that on one siding the isolated rail is blue and on the other it is yellow. This continues on all of my eight sidings - the odd-numbered tracks have blue isolated sections and the even-numbered tracks have yellow isolated setions. So at the decoder, I have the two ports configured as 11 and 12. On the layout diagram, I have two pairs of red/green point buttons (but no point), one pair configured with address 11 the other with address 12. Clicking red button 11 switches all of the blue sections off, and green on again. Buttons 12 do the same for the yellow sections. At startup, these are switched on, and at the end of each program which uses them they are left on.In a program, a train entering the top siding from the left, will be slowed to a crawl, and at a point in time when the loco has passed the first isolated section, port 11 is switched left to turn off the power in the blue sections. When the loco reaches the isolated section it will stop. The program will allow a leeway of 5 seconds, issue a stop command to the loco, wait another 5 seconds then switch port 11 right to restore power to the section.

I used an ADS2FX decoder because it was to hand. I am sure people will point out that there are other pieces of kit available which will perform the same function at a lower price.

I will show how I semi-automatically bring trains to a stop in visible places in a further post, as this one is longer than I intended.

Ray

[St1ngr4y]

Hello again,

In order to explain my method of stopping trains in visible areas, I have included this image of the second half of one of my programs. This program brings the "Heart of Midlothian" train from its hidden siding into platform 4 behind Gresley A4 60004 "William Whitelaw".

/media/tinymce_upload/deb6328f0c664e9221e5d6022630d7c6.pngThe first command begins a gradual deceleration from 50 to 20, which speed it reaches just as it enters the platform. During the deceleration, a station announement is made and a couple of signals are changed as the train passes them. About half way down the platform, a harsher deceleration is started, going from 20 to 5 speed steps in about 7 seconds.

Now, I can hear you saying, all you need to do now is click the Stop button of the loco's throttle when it reaches the right place. However, first of all you need to have that throttle on display to be able to do that, and secondly, I find that sometimes throttle buttons don't react when a program is running.

When I first started using RM a few years ago, I did a lot of exploring of the system, and I found a command available in the program editor dropdown list, which was nowhere to be found in the manual. This command is the "Pause Message" command, which you will see in the program at 90 seconds. The way this works is that when executed, it displays a simple message box on the RM window, saying "Press Enter to continue" at which point following commands are not executed until the Enter key is pressed. So immediately after the Pause command, I have a F12 Brake command followed by a Stop command. I play a station chimes sound just before the pause command, so that I can be looking at the train without having to watch the screen for the Press Enter message. BUT there is a fault in this command, which I can't complain about because it's not in the manual. The fault is that, during the pause, awaiting the user to press the Enter key, the program execution clock continues to run in the background. So if you have several commands after the pause and within a second or two of it, the program execution software tries to catch up to the clock by executing as many commands as it finds which are behind the clock, in as short a time as possible, which is not really desirable. The way around it is to place those commands which you DO want to action immediately straight after the pause, in the example the Brake and Stop commands, then to leave a 10 second gap to the rest of the program.

You may have noticed that I have changed the F12 command to a "latching" command by adding on/off to its description. The reason for this is that for "spot" commands which don't have on/off in their descriptions, RM will issue a command to switch on the sound, then it will loop for about 2 seconds doing nothing, before issuing a switch off command. This has the effect of delaying the Stop command for 2 seconds longer than required. The final command in the program simply causes the F12 status to be returned to the normal "off".

Ray

[RB51]

Hi Ray, I have watched this post without comment for a few hours in case someone came back with something more pertinent that I am about to add.

 

I don't know if this has ever been said to you but in my opinion your knowledge and expertise with programs, signals and the RM software generally puts you in a "second to none" position. The way you explore, experiment and then explain your findings are all commendable attributes and worthy of note.

 

Thank you for so willingly assisting us.

 

R-

 

 

[St1ngr4y]

@RogerB

 

Very kind of you to say so, R-

 

Now I'm blushing  😳

 

Ray

[96RAF]

I have found tables never come out right on the forum so I spreadsheet them and grab a screen shot.

 

The current RM recommended method of creep error reset by crashing the buffers although crude at least gives the same starting point for end to end operations. Not much help in mid route stop scenarios though.

 

Unfortunately due to the many factors giving variations that can creep into the elapsed time over a route there is little we can do until a positive local sensor is introduced.

 

Well done to the guys putting extra effort into these problems on behalf of others. Much appreciated.

Rob

[TrainDriverJ]

Many, many, thanks RDS. This is almost exact. Sorry I have not got back sooner as it is my 60th birthday today and I have been riding on the footplate of “The City of Wells” at ELR. Just got back.

 

I'm glad I got to see it like this as it is much more meaningful alongside my conclusions. I was concerned about re-posting again in different formats as I do not know which one would work and I was in danger of simply repeating “this mess” which I did not want as it would just annoy readers.

 

The first column 41 entries” is the trips in the “out” direction. So this should read Trip Out. The 4th column for 21 entries is the trips that are “Out And Back” direction. This should read Out And Back. Meaning the last 2 columns are not needed. I did this to see if the was a difference when going in the reverse direction which there was.

 

The variations should be -16 to 28 in the foot of the 3rd column as this was the undershoot and overshoot variation values of the whole of the 41 iterations. Also the variation -80 to -39 is the conclusion of the 6th column so should be at the foot of the 6th column. This makes the maximum difference of the variation on the outward trip of 44mm (note not a minus figure) and 41mm (note not a minus sign) for the out and back trip. This helps to prove the theory that any trip no matter what length or direction of travel should result in a similar variance irrespective of the of distance of operation. A change to the program in regards of time would be needed to bring it within tolerances on the return journey.

 

You should therefore always be able to operate a train with 44mm of spare clearance assuming no other factors ever come into play. I will have to do further experiments to see if this hold true for trains that are not returned to a starting point on each iteration as the plus and minus values may make the train creep further and further away form this tolerance.

 

I would be most grateful and indebted if you could make these minor amendments and get rid of that “horrible mess”. Many thanks, John

[RDS]

The table referred to by John above, is now on the next page of this thread.

 

Happy Birthday John, hope you had a great day.

[RDS]

This is the information posted on the 11th December following experiments carried out by TrainDriverJohn

 

I think you guys have got it all figured out already but I did do a few experiments. 

Loco R3284TTS Railroad Flying Scotsman (no Carraiges)

Straight test track (cleaned with good connectors}

RailMaster Program. 75 seconds consisting of sound on/off use of function buttons (whistles) forward to shunt then acceleration and deceleration commands before stop. The programmed returned journey is exactly the same except the program is using reverse instead of forward.

On each iteration the loco was placed back on the start line.

The results are:

/media/tinymce_upload/9e7e2857a38bcabd1a63501cd7954f70.jpg

 

Conclusion

1. It is obvious that it is impossible to know where the loco will come to rest on any given journey.

 

2. The return distances are considerably shorter. I believe this to be due to pushing the tender rather than pulling it. The variations are the same though so on the return journey you could compensate for this by placing extra time in the return journey program to bring it back closer to the start line.

 

3. Even after doubling the journey the variation remains similar. It would therefore be reasonable to conclude that any distance would produce a similar result.

 

4. After trying 41 iterations it appears that you would have to have at least 44 mm from the buffer after having recorded your shortest distance.

 

5. Further experimentation is needed to establish if it is possible to have reasonable tolerances and therefore is a practicable use of this type of program when the loco is not returned to the start line on each iteration.

 

6. Further experimentation is needed to establish what would be the outcomes if a load was attached to the loco. This might just result in the conclusion in 2. This of course would mean that if you had a terminus to terminus journey you would have to stick to the same configuration or a change in the program times would result.

 

7. The loco running could be interrupted any time dirt on the track etc. this would almost invariably give a result outside of expected tolerances.

 

8. It is already looking like an alternative method to this may be a better idea. Nice try but no cigar.

 

9. Of course all the old hands knew all this and have already been there done that.

[RDS]

I hope I have got it right now John. 

If not, no problem, let me know and I will have another attempt and then I will remove all of this.

[TrainDriverJ]

Thanks again RDS. Yes this is how I had it now. I promise I won’t do this to you again! I’ll follow the advice above in future and do “snip” picture of the table and post that.

 

I think it shows enough that the stopping is more or less random but within a target area but need to do a few more experiments first.

[RDS]

No problem at all John.  That size of table would not have pasted well.  I am quite happy to post it for you. 

 

I have developed a technique for posting a spreadsheet and I will post the details under the General Discussion Section, of how it can be done.

[St1ngr4y]

@TrainDriverJohn

 

If you can be bothered, it might be useful to remove all of the function commands, leaving only the speed commands, and see if that makes much difference to your tests. Sometimes functions can interfere with the accelerate/decelerate commands, especially "spot" sound commands which don't have "on/off" in their descriptions.

 

Ray

[TrainDriverJ]

@RDS

 

I have typed my data into a spreadsheet as I didn't know about your kind offer until it was too late. I will be doing more so your article about how to post spreadsheets would be most beneficial, and I think to others as well.

 

@St1ngr4y

 

Okay will do. I have several tests in mind with my ultimate intention, that within a reasonable running period and therefore, a reasonable amount of iterations that a target area of a stopping tolerance zone could be achieved that people would find acceptable to use on their model railway. Obviously this may not be possible and some people may not think it would be accurate enough for their operations but at least I'll know limitations. If any of my tests fail this then it is time to give up and state that RailMaster is not up to the job in it's own right.

 

I will continue it's just the time especially being near Christmas now but I will do some more and post the results and any conclusions.