Routes not working

[zandall]

Railmaster Pro latest version Jan 2020, Hornby eLink with P9300W 4A PSU, PECO settrack & Streamline medium radius points, SEEP PM2 point motors, Hornby R8247 Decoders.

I've set up 12 points on a layout each with routes defined. Some are two points used as crossovers on a single decoder output. Clicking a point button on screen works every time. Clicking on a route doesn't operate the Streamline points. I can hear the point motor(s) click but it doesn't switch over. The Settrack points however work OK. I've tried changing Points timer to 1.5 and Double pulse=1 in the INI file but to no avail. I assume it's probably a power problem and the decoders aren't recharging quickly enough but then they appear to have an individual CDU per output. I can't detect any stiffness in the Streamline points - if anything, the Settrack ones seem stiffer but they work.

Anybody got any ideas I could explore further please?

Thanks.

 

[St1ngr4y]

Have you tried the INI file entry "Points timer" with a value higher than 1.5, say 3 ? Do the route indicators on the individual points icons on the layout diagram change as you would expect ? R8247 decoders do NOT have a separate CDU per output port - there is one per decoder, so all four ports on the decoder share the CDU.

 

Ray

[Chrissaf]

TIP: As a newbie poster on the forum, just be aware that the 'Blue Button with the White Arrow' is not a 'Reply to this post' button. If you want to reply to any of the posts, scroll down and write your reply in the reply text box at the bottom of the page and click the Green 'Reply' button.

.

See also – further TIPs on how to get the best user experience from this forum.

https://www.hornby.com/uk-en/forum/tips-on-using-the-forum/

.

[96RAF]

I wonder if the settings apply only to the screen and not routes. If would be good to to be able to confirm if the set delays work in programs as well or if you have to specifically tell it to wait.

 

Report it in to HRMS anyhow and see what they say.

[St1ngr4y]

I wonder if the settings apply only to the screen and not routes. If would be good to to be able to confirm if the set delays work in programs as well or if you have to specifically tell it to wait.

 

Report it in to HRMS anyhow and see what they say.

 

Hi Rob,

 

I have just tried this using my one and only remaining R8247, which is configured to port addresses 33-36. I set up 2 routes called A and B. Route A sets all four points to the right. Route B sets all four points to the left. At first, the INI file had Points timer=0.25, and with this setting, only the first port 33 was firing satisfactorily. I changed the INI file setting to Points timer=3, and afterwards, both routes worked fine. I then created a program which first of all changed all 4 points right (all lines had 10 secs as the execution time) then at 15secs it tried to change them all back to the left. This failed miserably i.e. the Points timer=n INI setting is ignored in a program, which is reasonable because you can specify exact times in a program. Of course, setting the INI value to 3 means that it takes ages to start a session if you are setting a lot of points at startup.

 

Ray

[96RAF]

Thanks for that ray. So it looks as if you have to build in your own lag times and fire routed points individually in a program.

[St1ngr4y]

Hi Rob,

 

That's correct, and there is no program command which can be invoked to execute a route in a program. Similarly, "Other Points/Signals" configured for points or signals, are not invoked in a program when those points or signals are switched.

 

Ray

[Fishmanoz]

Try rewiring such that the route doesn't require ports on a single decoder to be fired sequentially. For example, if you have a route which needs to set all ports 1-4 on each of decoders A and B, don't have the firing order A1, A2, A3, A4, B1, B2, B3, B4.  Arrange it to fire A1, B1, A2, B2, A3, B3 etc.  Or if 3 decoders involved, make it A1, B1, C1 etc.

[96RAF]

If the route firing methodology follows the firing order set for start up then you only get a choice of changing this in RM Pro. In basic RM as Ray says the firing order is set by initial point listing order in the track-plan.

 

I didn’t like routes in RM, much preferring the Rocrail method of being able to place a start, intermediate and stop buttons on the plan and set a route by simply clicking the applicable buttons. Rocrail will also work out for you all possible routes there and back on a layout plan. Something RM could learn from.

[Fishmanoz]

Thanks for that clarification Ray, I didn't realise that.  In fact, I think I'm falling for the fundamental problem with RM - assuming that it knows where things are, and it doesn't. 

And Rob, given the above, any chance of RM learning from Rocrail in this respect means a complete change in RM fundamental design such that it does know the relationships beteeen everything on the layout. Ie.  it would need to know all of the which is connected to what relationships along the layout that it currently doesn't. I think that means design again from scratch. 

[St1ngr4y]

@Fishmanoz

 

I don't think it is so easy as that, Fishy. I am pretty sure that the order in which the points in a route are fired is the order that those points appear in the layout file. This, in turn, depends on the order in which the points were added to the layout. So in your example, the eight points could be deleted from the layout then re-added in the order A1, B1, A2, B2, A3, B3, A4, B4. Then the route could be added to each point in turn. This philosophy could help speed up the startup switching too. If you have 10 x R8247's, then with hindsight, it would be ideal, when creating your layout in the designer, to add all of the port 1 addresses first, then all the port 2's etc. Then you could have a fairly short Points timer= setting in the INI file.

 

Another way around Zandall's problem is to use RM programs instead of routes. In this way, he would have control over the firing order and the amount of time between the firing of each point.

 

Ray

[96RAF]

Don’t hold your breath Fishy. Whilst it would be good if they would, I doubt it will ever happen. It is something that should have been thought of and built into the initial design spec. Dare I mention loco detection which sits in the same bracket, another case of too little, too late. We are also still waiting for several known bugs to be fixed and certain kit to be incorporated that has been ‘in work’ for years e.g. Train-Tech sensor signals as opposed to their normal digital signals.