Stop position using RailMaster recorded programmes

[Michael_A]

I find the fact that trains will not stop in the same place incredibly frustrating to the point it makes recording sequences useless, other than for point, signal or route setting.

 

I was thinking of using a point decoder to drive a relay to switch

 

an isolating section to stop a train (with a relatively long slow run at the end)Was thinking I could use a signal in the stop position which would also mark this on the RailMaster layout.

 

Has anyone tried this? Pros? Cons?

 

Thanks

[idlemarvel]

Ref your frustration I think it depends on how accurate you want to be and the nature of your layout. I have a small loop with three fiddle roads on one side and station on the other. I can get e.g. Pendolino to stop within an inch each time even after

 

a few repeats. It does take some time to get the time exactly right (tenths of a second) but if I manually position the loco in the same start position at the start of an operating sequence it seems to be accurate enough for my tastes. But the total running

 

length is only about 16 feet, I can imagine on larger layouts it would be a bigger problem. If you have an end to end layout I have heard users programming the train to go slightly too far at the fiddle yard end and have some soft foam rubber at the end of

 

the track to stop the train in exactly the same position.

As for your suggestion of having an accessory decoder controlled isolating section, it's a neat idea and I can see how it would make a loco come to a (perhaps abrupt) stop in the same position, but

 

I haven't tried it. You'd have to consider turning the sound off before the isolating section to avoid sudden silences!

[AlfK]

Michael, I would like to echo your frustration at lack of accuracy using my new elink with Railmaster, tested via doing repeated stopping of the same train, travelling the same loop of track over and over again (at different running temperatures, even

 

doing a 6 lap warmup session prior to getting the tape measure out proper) - differences of 0.5" - 6" variation.

 

On my layout, which has only a 6" maximum beginning/end buffer distance on some blocks, this means that this setup is probably not for

 

me.............shame when on first sight it looked good.

 

[Fishmanoz]

The accepted way to be able to achieve accurate positioning is to have loco detection, so you know exactly when a loco arrives at a particular place on the layout. Hornby RM Support are already working on this feature. If you check in RM, you will find

 

the software for it is already in the program and you can set it up and see all of the different things that can be done once a loco is detected. What we are waiting for is the hardware to implement it. They have a post in one of the threads here talking about

 

it. Might be the Desirable Features thread but not sure.

 

Many feel that RM will not do what they need until this feature is available.

[St1ngr4y]

Michael_A said:

I find the fact that trains will not stop in the same place incredibly frustrating to the point it makes recording sequences useless, other than for point, signal or route setting.

I was thinking of using a point decoder

to drive a relay to switch an isolating section to stop a train (with a relatively long slow run at the end)Was thinking I could use a signal in the stop position which would also mark this on the RailMaster layout.

Has anyone tried this? Pros? Cons?

Thanks

Michael,
In

your recorded program, how do you control the stopping of your train - are you relying on the speed curve CVs in the loco decoder, or are you using the decelerate command which can be used in a RM program? I prefer the latter, and I achieved excellent results

with both the accelerate and decelerate commands before v1.48 of RM was introduced. At that version, they decided to enhance the commands by adding a rate of acceleration/deceleration parameter to the end of these commands. Since then, performance has not

been so good, and in particular the rates of deceleration/acceleration seem to be different between execution in the program testing window and the main window, and also different between a program run by itself in the main window and when the same program

is run under the new CHAIN command.
Ray

[idlemarvel]

I was interested in the idea of using isolating sections so I did a few tests. In summary using an isolating section gives you more consistent and predictable results, but the more simple programming approach is probably okay for small layouts and limited

 

number of operations. For more details read on.

 

Two tests were performed on a short length of clean straight level track. A class 08 shunter was programmed to go forward to 10 mph for 15 seconds, stop, and reverse to 10mph until either the isolating

 

track was reached (test A) or 15 seconds had passed (test B).

Test A used a program controlled isolating switch to stop the loco dead. Test B used program control to stop the loco, in theory at the same stopping point. Each test was performed in a loop

 

10 times, and the difference in the distance from the initial stopping marker was measured in units of sleepers (approx. 7mm). The stopping point was just over 4 feet (49 inches or 1.245 mm) from the isolating track starting point.

 

The results from

 

Test A showed that the stopping distance varied by less than 3 mm or 1/8 inch, less than a quarter of one per cent of the total distance, and did not increase over time.

 

The results from Test B showed that the stopping distance gradually increased,

 

reaching 35 mm

or 1 3/8 inches after 10 sequences, which is well over two and a half per cent of the total distance.

 

Test B was repeated but the return time was increased by 0.1 seconds, i.e. 15 seconds outbound, 15.1 seconds on the return. This

 

time although the stopping distance gradually increased, the amount was much reduced, about 14 mm or ½ inch after 10 sequences. Increasing it by 0.2 seconds caused the stopping distance to reduce by several inches, making the results worse.

 

Conclusions

Using

 

an isolating section to stop a loco dead improves the accuracy of stopping distances considerably, to within a fraction of a per cent, in a consistent manner, no matter how many times the sequence is repeated.

 

Using purely program control, with minor

 

tweaking, can achieve comparable results for up to the 10 sequences measured, but over time the discrepancy between the desired and actual stopping distance will continue to increase, and at some point cause operational problems such as hitting buffers or

 

not clearing a point.

 

Observations

For some reason the loco did not cover the same distance going forward 15 seconds as it did reversing 15 seconds. This might be for several reasons; perhaps the track was not exactly level (it was checked with a

 

long spirit level) or the motor might be better spinning one way than the other. Adjusting the return time compensated largely for this difference.

 

Clearly this test was over a short distance, with no curves, points, inclines or other elements that

 

would add to the variability of performance. These would make the isolating section approach even more attractive especially if repeated operational sequences are desired.

 

If you want details of how I set up a program controlled isolation section see

 

this document on dropbox: https://db.tt/S9AU1zEc

 

 

[Michael_A]

Thanks for all the replies.

 

I am using the speed control to bring the train to a stop. Even adjusting the timing in the programm only helps temporarily, there are so many other variables. Problem is if you are stopping at a signal, in a station,

 

or before a set of points, then stopping in the wrong place either looks wrong, or means you have to back the train up to clear the points. And of course the error is accumualitive, so if you want to use the same programme in sequence, then it becomes impossible.

 

 

 

I guess there is a limit to the technoöogy, especially when based on nothing more than running time. Kind of makes it not fit for purpose though! I think I will wait and see how loco detection will be incorporated. I assume this will mean reading back

 

data at the same time as sending data, so this will be an interesting technical challenge. I have a feeling it will be connecting to the programme connections which might mean more wiring.

[Michael_A]

idlemarvel said:

I was interested in the idea of using isolating sections so I did a few tests. In summary using an isolating section gives you more consistent and predictable results, but the more simple programming approach is probably

okay for small layouts and limited number of operations. For more details read on.

Two tests were performed on a short length of clean straight level track. A class 08 shunter was programmed to go forward to 10 mph for 15 seconds, stop, and reverse

to 10mph until either the isolating track was reached (test A) or 15 seconds had passed (test B).
Test A used a program controlled isolating switch to stop the loco dead. Test B used program control to stop the loco, in theory at the same stopping point.

Each test was performed in a loop 10 times, and the difference in the distance from the initial stopping marker was measured in units of sleepers (approx. 7mm). The stopping point was just over 4 feet (49 inches or 1.245 mm) from the isolating track starting

point.

The results from Test A showed that the stopping distance varied by less than 3 mm or 1/8 inch, less than a quarter of one per cent of the total distance, and did not increase over time.

The results from Test B showed that the stopping

distance gradually increased, reaching 35 mm
or 1 3/8 inches after 10 sequences, which is well over two and a half per cent of the total distance.

Test B was repeated but the return time was increased by 0.1 seconds, i.e. 15 seconds outbound, 15.1

seconds on the return. This time although the stopping distance gradually increased, the amount was much reduced, about 14 mm or ½ inch after 10 sequences. Increasing it by 0.2 seconds caused the stopping distance to reduce by several inches, making the results

worse.

Conclusions
Using an isolating section to stop a loco dead improves the accuracy of stopping distances considerably, to within a fraction of a per cent, in a consistent manner, no matter how many times the sequence is repeated.

Using

purely program control, with minor tweaking, can achieve comparable results for up to the 10 sequences measured, but over time the discrepancy between the desired and actual stopping distance will continue to increase, and at some point cause operational problems

such as hitting buffers or not clearing a point.

Observations
For some reason the loco did not cover the same distance going forward 15 seconds as it did reversing 15 seconds. This might be for several reasons; perhaps the track was not exactly level

(it was checked with a long spirit level) or the motor might be better spinning one way than the other. Adjusting the return time compensated largely for this difference.

Clearly this test was over a short distance, with no curves, points, inclines

or other elements that would add to the variability of performance. These would make the isolating section approach even more attractive especially if repeated operational sequences are desired.

If you want details of how I set up a program controlled

isolation section see this document on dropbox: https://db.tt/S9AU1zEc

[Michael_A]

Dave, fascinating and thanks for the wiring diagram. I was catually going to use the function outputs of a loco decoder to drive low power relays. Cheaper than latching relays and a point decoder. Hattons do one for a tenner, 4 outputs. Guess I wil need

 

a back emf diode too.....

[idlemarvel]

Michael_A said:
I was actually going to use the function outputs of a loco decoder to drive low power relays. Cheaper than latching relays and a point decoder. Hattons do one for a tenner, 4 outputs. Guess I will need a back emf diode too.....

If

you get this working could you report back to the forum please?

Ref other comments about loco detection being the ultimate answer, I am not completely convinced by this. If I understand correctly, what detection does is tell you that a loco has passed

a detector (using barcode, RFID, whatever). You have to use that info to take some action such as stop the loco. Surely that latter process will also be prone to the same variables as program control, so the loco wouldn't stop exactly in the same place each

time? I can see it would be more accurate than purely relying on timing, but maybe not as accurate and consistent as the isolating section approach. Of course there are other benefits to loco detection, but for this particular problem of how to stop a loco

in exactly the same place consistently it may not be the best answer. But I have no practical experience of loco detection so I would like to hear what others think.

[Fishmanoz]

Michael_A said:

Thanks for all the replies.

I am using the speed control to bring the train to a stop. Even adjusting the timing in the programm only helps temporarily, there are so many other variables. Problem is if you are stopping

at a signal, in a station, or before a set of points, then stopping in the wrong place either looks wrong, or means you have to back the train up to clear the points. And of course the error is accumualitive, so if you want to use the same programme in sequence,

then it becomes impossible.

I guess there is a limit to the technoöogy, especially when based on nothing more than running time. Kind of makes it not fit for purpose though! I think I will wait and see how loco detection will be incorporated. I assume

this will mean reading back data at the same time as sending data, so this will be an interesting technical challenge. I have a feeling it will be connecting to the programme connections which might mean more wiring.

I think there is a little fuzzy

thinking going on about how this might work. For a start, take a look at https://www.hornby.com/forums/hornby-forums/hornby-railmaster/5103/?page=1#post63370 at the HRMS post where they give a good basic description of the system and the parts that make it

up.

Now go into RM System Settings and look at the Loco Detection tab. There you can see that there is provision for inclusion of 2 loco detection controllers, just like there is provision for 2 conventional DCC controllers under the General tab. Further,

the loco detection controllers have com ports to be defined for them, so they are going to connect to you PC and RM via USB cables, again just like your eLink or Elite.

Then, just as HRMS says, go into Track Design and add a loco detector to your layout

and see all of the options you have available to you as actions to take when a detection is made. Once RM delivers on these, it is clear the power of an RM system will increase dramatically.

Just on loco detection errors mentioned above, I agree that

there may be some. But unlike errors in timing in getting from A to B on a layout, which are cumulative if you perform the operation more than once and may be relatively large in the first place if A and B are widely spaced, now we are only talking about non-cumulative

errors in stopping distance between detection and coming to a halt. These are likely to be relatively small and so relatively easy to accommodate in your program. But we will have to wait and see on this one, and hopefully the manual will have information

on dealing with them.

One final point while you are still looking at HRMS's post on the Loco Detection thread. Click on their user name and it will show you their recent posts, all of which you will find interesting. And if it doesn't appear this way,

go to the end of the Desirable Features for RM thread and take a look at what they say about the next big upgrade.

[Gregd99]

Having run a layout with auto-control for 4-5 years I agree that loco detection is the most simple, reliable answer.

 

I use IR detection across the track. To stop a train at a given location I detect the start of the train and then the end of the

 

train. When the train has passed through the detector I am able to stop it with quite good precision. nb this can be +/- a few cm which is fine for most but not all things.

 

If I need a really precise stop then I could (but have not yet needed to) have

 

a detector that triggers a hard (emergency) stop when interrupted.

of course..... this all depends on having a train going at a "stoppable" speed. the approach that i use is an upstream detector is used to command a speed reduction to "slow" and then the

 

next detector is able to stop the train in a reasonable distance.

 

I found learning about auto-control really interesting and led to me studying and understanding some of the train signalling systems that implement the fast/slow/stop logic described

 

above.

 

have fun!

[idlemarvel]

Thanks Fishmanoz and Greg, very interesting and informative comments.

[Gregd99]

To run a train for 30 seconds and then stop it by a program can be fun (for some people).

 

When you start to look at stopping at a precise location your are actually starting to look at the start of control theory!! is it enough that the location

 

is precise (predictable) or does it need to be accurate (the right location)?

 

All sorts of factors come into the equation. what is the response time of the detection system? is it fixed or is it variable or a combination of the two? is the behaviour

 

of decoders repeatable (generally yes)? do all trains behave the same way (generally no.... a shunter will have a shorter stopping distance than an express)? in my case with IR detection gaps between carriages can be detected at slow speed. How should this

 

be handled?

 

The sorts of factors above led to my track needing to be segmented and protected by signals. It was necessary to know each trains speed so that it would stop before a signal..... I didn't mind if it was 5-10 cm before a signal but after

 

the signal was not acceptable.

 

All of the stuff above can be a great learning experience (code for it needs research, time and enthusiasm but you learn something) or for others it makes their eyes glaze over....

 

Have fun with what works for you!!

[St1ngr4y]

I can't understand why, in this thread, I am the only one to have mentioned the accelerate/decelerate commands. My layout is a double track oval, about 75 feet in circumference. At one end, the tracks split into 8 hidden sidings. Down one side I have a

 

6 platform station. Within a program, I can start a train from a hidden siding, which emerges from a tunnel at a scale speed of around 60 mph, and using the decelerate command, it will stop at a platform in the station, within about a centimeter, every time.

 

After a few doors banging sounds, station announcements, and a guard's whistle, the train will accelerate away, coming to a stop at it's starting point in the hidden siding. During it's journey the train will also have passed several colour light signals,

 

which are changed to red, by the program, at exactly the correct time as the train passes.

The rates of acceleration/deceleration which are achievable using these program commands, are extremely realistic, much more so than is possible by 'manual' control

 

either through RM or the Elite directly.

I'm not sure whether train detection will improve what I've got already...

Ray

[Gregd99]

Ray,

I did some measurements with hornby decoders and locos a few years back and found them to be very precise. If I set the decoder for loco X to 50% throttle then the speed around a loop would vary very little. I don't have the data with me but as

 

i recall the precision was something like +/- 0.5% I thought that that was very impressive.

 

if I translate that to your layout with a 75' circumference (pretty impressive!!) then that would give a variability of +/- 0.375'/loop or 4.5".

 

You

 

are reporting a 1cm variability (or 0.04%!!). This is really impressive! If you drive the train around the loop 10 times then that could be 10cm difference if the variability is to do with speed error in the loco/decoder. if on the other hand the change is

 

due to command station (elite+pc) latency then perhaps it would still only be 1cm.

 

the elite (and I guess the elink) has a feature that causes commands from the pc to be discarded occasionally. This requires the command to be resent - I think that this

 

will happen automatically inside RM - various threads have mentioned double commands. If the re-transmission takes 200mS to detect and implement then the command will arrive at the loco 0.2S late. If the loco is doing 10mph this is about 0.4" error but at

 

60mph it would be an error of about 2.4".

 

under manual control lost commands don't matter as moving the knob on the elite causes many throttle commands to be sent. One will get through. If it is a point operation is lost you scratch your head and press

 

the button again using your visual/aural location detection system to detect the error.

 

If the PC or the elite were momentarily busy with another task there might be a small delay in send the command to the loco.

 

The thing that cause me much

 

grief was the need to repeat commands occasionally. this meant that occasionally points would change under or after a train or that a loco would hit the buffers at the end of a siding. The solution was to detect the failed command and resend.

 

I am sure

 

that much is possible without worrying about any of the complexities above and that these complexities are not interesting to many people.

 

I run three trains simultaneously under computer control on a smallish 3 loop + 3 siding layout that is about

 

30' in circumference. this requires trains to stop/start according to the location of the other trains. i found that the location feedback was essential.

 

it's all fun and we all have different interests and objectives.