Route-setting problem.

[HLT 0109]

Technological developments are both a blessing and a curse, and I am hoping someone can suggest a solution!

 

I have a large layout under DCC control using NCE Power Cab with SB3a booster and Pro Cab.  I have about 75 points operated by solenoid point motors controlled by Hornby R8247 accessory decoders.  This arrangement (whilst not perhaps what I would choose if starting again) has worked well enough for nine years.

 

Enter JMRI computer control which, among other things, has made route setting a straight-forward exercise.  However, because the Hornby R8247 uses just one, internal CDU to power its four outputs, it does not reliably switch a route using points wired to the same R8247 - because there is insufficient time for the CDU to recharge before the next pulse is required.  Route setting is possible from the NCE handsets but the problem is just the same.  With both systems the delay between pulses can be adjusted (more so with JMRI) and I have tried up to 2 seconds - that's a heck of a delay if there are 10 points in the sequence - and it is still not reliably sufficient.  Following recent modifications to the track which added a single slip and two more curved points, I purchased two DCC Concepts ADS2FX decoders; as these have a separate CDU for each output, they would be the ideal solution but, at £25 each, I woould be faced with a £750 cost to change from the R8247s.  There is the 8FX @ £60 which would cut the cost to about £480 and, perhaps I could trim another £60 off by using just one output from each of some of the R8247s.  But that is a lot of money for the convenience of route-setting.  I have thought of re-wiring all outputs to different points - if I get it right, it should work - but that means "reporogramming" the layout in JMRI as well as a huge rewiring task.  I would also have to re-learn the point numbers for handset control.

 

I suspect there is no answer to this conundrum but will read replies with great interest.  It woould help if, in JMRI route setting, one could set the order in which the point motors are fired - but I think it occurs in number sequence.

 

Thank you for your time.

Harold.

[10000]

I'm not familier with JMRI, I use CTI. 

 

In CTI I can specify the order in which actions happen. 

 

Does JMRI not have a scripting system which you could use to set the routes and define the order in which they fire and set a delay if needed?

[Stephen Freeman]

Hi,

I thought this problem had been solved a long time ago. Somewhere on JMRIs website there may be at least one or two "start of day" routines, one of which I probably did for a large 0 gauge layout using mainly Tortoise motors (about 40 of them I think). Basically you want to make sure that only one or two are being fired from one Accessory Decoder at a time of course. It was about 14 years ago so sorry I can't remember more. I think you will need to be using Panelpro though rather than a handset.

Edited October 22, 2017 by Stephen Freeman

[NIK]

Hi,

 

If JMRI does not have this feature built in I think a JMRI script could be written to deal with this problem in software with perhaps no need to do any electrical changes.

 

I was thinking that for each route the JMRI script would make a list for all the points to be operated. It would then activate a Turnout command to all appropriate turnouts numbered 1,5,9,13,17 etc. then it delay for n seconds, and would do for all applicable points numbered 2,6,10,14,18 etc and on to 4,8,12,16,20 etc.

 

 

Perhaps you could ask on the JMRI users group about how to get/create such a script.

 

 

Regards

 

Nick

 

 

[Nigelcliffe]

It doesn't need new code, scripts or similar for Nik's suggestion. 

 

Create multiple routes, such as "StartofDay1", "StartofDay2", etc..  and have them perform different parts of the switching.  They can be cascaded by having an Internal Turnout which is set as the last operation in the first route, and that Internal Turnout then triggers the second route to run.   If more than one route is needed, then a second Internal Turnout can act as a second trigger.   And so on. 

[NIK]

It doesn't need new code, scripts or similar for Nik's suggestion. 

 

Create multiple routes, such as "StartofDay1", "StartofDay2", etc..  and have them perform different parts of the switching.  They can be cascaded by having an Internal Turnout which is set as the last operation in the first route, and that Internal Turnout then triggers the second route to run.   If more than one route is needed, then a second Internal Turnout can act as a second trigger.   And so on. 

 

Hi,

 

Yes but if there are a large number of routes then won't there need to be four times as many 'internal' routes rather than one script to cover all routes?.

 

Also the OP didn't seem to be talking about Start of Day but general route setting using one CDFU/four output Hornby point decoders.

 

 

Regards

 

Nick

[HLT 0109]

Thank you gentlement for your guidance.

 

Clearly I need to familiarise myself with JMRI scripts - something i have not even looked at!

 

NIgel - I understand what you are saying.  When I set up each of my routes, I listed the points in the order I hoped they would be triggered - ie trying to give time for recovery but my sequence is ignored.  However, if each sequences in a given route is split into a series of routes and I can get one section to trigger the next, that should have the desired effect.

 

Nick, if I can achieve the sequence you outline, that would work well I think.  I am not familiar with the term "StartofDay" in this context but it looks as if Nigel is in fact saying the same as you but, instaed of (or perhaps in addition to) separating the sections of a route by an increased delay, I should use an internal Turnout as a trigger for the next section.

 

As you say, Nick, I can seek further help from the JMRI users group and that is probably where further queries about this should be raised.  I will update this thread when (if) I get a satisfactory outcome.

 

Thanks again,

Harold.

 

edited to remove repeated sentence

Edited October 22, 2017 by HLT 0109

[HLT 0109]

Harold, it's easier (and certainly cheaper) to change the internal CDU so it charges the capacitor(s) quicker. I have no idea how the CDU is wired internally (others who have it might know) but if it's resistor based, then lowering the resistor value will improve charging times no end! Perhaps it allows for an external CDU to be used? If so, that one might charge faster anyway. Soldering a CDU together from electronics parts on a strip of Vero board (or similar) isn't too difficult if you can wield a soldering iron properly, based on an existing design you'd replicate, and probably for sure a lot cheaper as well!

Thank you for that.

 

I wondered about an external CDU but I don't see how it would work: as it would need to be triggered by the DCC command, where would it be connected to the power supply, and where would the outputs be connected in order to get the instruction to the correct point motor? 

[Ray H]

I had problems on a DC layout with a CDU not re-charging fast enough. It needed an increased voltage supply. Just a couple of volts was all that it needed. Is this an option? 

[smokebox]

If we are talking about Hornby point decoders, they definitely can't (normally) be used with an external CDU.

 

There is a way of doing it, where the CDU drives a relay and the relay operates the points via a CDU.

[Trip]

Harold,

 

If you don't get a good answer on the jmri users list I can easily knock you up a script to fire points in any order you like. 

[HLT 0109]

Harold,

 

If you don't get a good answer on the jmri users list I can easily knock you up a script to fire points in any order you like. 

That''s very kind of you Trip.  I took one look at scripts and my eyes glazed over!  I don't think I could ever work it out.  Instead, I have today been trying Nigel's suggestion of having two routes linked by an internal turnout.  It has taken me three hours to sort out two routes - each with 7 or 8 points.  Some of that time was in understanding the options and next time I expect it will be quicker - but I kept finding one point that just refused to change despite setting the interval between switching at 3 seconds.  In the end, I resolved it by changing the reluctent point into the first section of the route rather than the second.  I had the problem with both routes and the solution worked for both.  Just ten more routes to do - several of them need three or more sections.  I have not raised the question yet on the JMRI Users site - I thought a bit of practice first would be beneficial.  I should be very grateful for a bit of script as a guide  . . . .   could you please provide me with a script for points 16, 20, 43, 63 followed by internal turnout 93 to trigger 13 and 63?

 

Many thanks,

Harold.

[Trip]

Hi Harold,

 

I've sent you a PM. In short, send me your layout and routes (in the jmri xml file) and I'll see what I can do.

[RAF96]

I use the Horby acc-decoders with relays so that an external CDU can be used (Gaugemaster unit). 2 relays per point motor, hence a large relay board mounting the acc-decoders as well, but a solid state switching PIC method may be possible to make it more compact.

 

The wiring diagram is in my gallery to view, but in principle the DCC fires into the coil of a relay and the relay dumps the CDU into the solenoids.

 

Alongside this is a rotary switch/press to make switch for manual control when the DCC (via PC) is not in use. My diagram does not show any advised diodes to protect the acc-decoder against relay coil backlash currents but so far I haven't bust anything without them.

 

I find I can sit there and press the straight/curve buttons continuously all day and the GM CDU will keep pace, even with some points being paired and if I 'cycle' the DCC side the Hornby internal CDU also keeps pace but the PC sometimes fails to send, although when initialising a route of up to some 8 points via Rocrail it was 99% reliable.

Edited October 25, 2017 by RAFHAAA96

[Trip]

Here's a script that will do what you want I think:

import jmri as jmri
from jmri_bindings import *
import time

class MyTurnouts():

    def __init__(self):
        pass

    def setTurnouts(self, turnoutList):
        for point in turnoutList:
            name, action, delay = point
            t = turnouts.getTurnout(name)
            t.setCommandedState(action)
            time.sleep(delay)

# Edit this bit with your own list of turnouts:
turnoutList = [
    ["LT1", CLOSED, 2],    # set the turnout called LT1 to state 'closed' and wait 2 seconds
    ["LT2", THROWN, 3.5],  # set the turnout called LT2 to state 'thrown' and wait 3.5 seconds
    ["LT3", CLOSED, 0]     # set the turnout called LT3 to state 'closed' and don't wait
]

MyTurnouts().setTurnouts(turnoutList)

Edit the list of turnouts to match your turnout names (either system or user name will work) and the direction ans delay you want. You're not limited to three, add more lines as you need to. A delay of zero effectively means do the next one at the same time so you can batch them up.

 

Once you've get that working I'll show you how to do it for multiple routes and have the script fired automatically by the JMRI route.

[Trip]

I should have included instructions on how to use this:

 

Open the JMRI help menu and select 'locations'. Look for the script location. Save the above text into a file in that folder called 'my_turnouts.py' (or whatever you like). Then, from the 'panels' menu, select 'run script'. That should open the script location and you can select your new script.

 

If nothing happens open the system console (also from the help menu). There might be error messages there that will help diagnose the problem. 

[HLT 0109]

Many thanks!

 

As a start, I have copied and pasted the detail from your previous post into a Word document (albeit it on my main PC which is not connected to the layout) and am pleased to see that it has copied correctly!  In view of the hour of the day, I do not propose to proceed further at the moment but will pursue the matter, probably on Friday.  I have located the script location so I think I can see what to do.

 

Thanks again

[Trip]

The code needs to be saved as a text document, not a word document. The difference is that a word document contains lots of details that are not relevant to the script, for example font type and size, paragraph spacing and so on. JMRI will not read a script that is in word document format.

 

Instead, use a text editor, for example Notepad, which just saves the text and nothing else. It should be saved as a python file with the file suffix .py, for example 'my_turnouts.py'. It should be saved in the 'scripts' location folder, open help/locations and see where that is.

 

There should already be a file in that folder called jmri_bindings.py along with a bunch of other scripts that come with the JMRI distribution (some of which are written by me   )

Edited October 26, 2017 by Trip

[HLT 0109]

Good! Achieved that.  I now have the details you drafted in "My_turnouts.py" text file from Notepad in the jython folder - and I also see your jmri_bindings file.  It looks as if I am ready to do some editing tomorrow.

 

Thank you once more.

[HLT 0109]

Not having much success with this.  Having found out how to access the error logs, I discovered that JMRI sees an error in the script set out in post 17 -  it says there is a colon missing in line 9 at column 35.  Since it is not clear from post 17 whicvh is line 9, I opened the file in the jython folder, only to see that the whole script was set out in one line!  So, I have been unable to determine where the missing colon should be.  I have compared my edited script with that in post 17 and everything seems to be as instructed.

 

Instead I have tried Nigel's suggestion of using internal turnouts to trigger separate secions of a particular route but that is hit and miss although, with (a lot) of trial and error, I have got two route to work satisfactorily.  It looks as if turnouts change in number sequence but I cannot be sure if all "ITs" change before any "NTs" and if 9 changes before or after 13 (as it starts with a 9 rather than a 1).  

 

I will triumph in the end, just not sure by which method.

 

Harold.

[Nigelcliffe]

Not having much success with this.  Having found out how to access the error logs, I discovered that JMRI sees an error in the script set out in post 17 -  it says there is a colon missing in line 9 at column 35.  Since it is not clear from post 17 whicvh is line 9, I opened the file in the jython folder, only to see that the whole script was set out in one line!  So, I have been unable to determine where the missing colon should be.  I have compared my edited script with that in post 17 and everything seems to be as instructed.

 

 

 

Use a different text editor, ideally one designed for editing software code.   I use "Notepad++" though there are many other alternatives. 

 

The report of missing colon may be correct, or the missing character might be well before that place (and might be a different character).  Unfortunately, code can be extremely fussy about tiny errors. 

 

- Nigel

[HLT 0109]

Thanks Nigel - I have been trying further and have had differing results!

 

I have been messaging Steve Trip but have not yet received a response to my latest submission in the followig terms:

 

"Please see the attached file - text version of the py file I have created.  The system console reports the following error "Line 54 no viable alternative to input  'My_Turnouts".  I have managed to overcome other error reports but cannot do so with this one.  It is also a mystery to me why the line number references seem to bear no relationship to the number of lines in the script."

 

I wonder if you have the asnwer, Nigel?

 

I did wonder whether there should be a closing bracket at the end of the last line but, when I tried that the error message was that it was looking for an RBRACK

 

Harold.

My-turnouts.txt

[Nigelcliffe]

There's a missing closing square bracket after the list of turnouts , and a missing closing round bracket on the last line.

 

 

Can't guarantee that's the only bugs, but those are fairly obvious from a quick read of the code.   

Its also something a decent code editor will help with, as it will flash the corresponding opening bracket as you add a closing bracket, thus you known that the brackets are correctly handled. 

 

 

- Nigel

[Trip]

What Nigel said: there's a closed bracket missing from the end of the turnout list, and a closed parenthesis missing at the very end. If you compare your text with the text I posted in #17 you'll see the differences.

 

You might want to download a (free) copy of pycharm. It actually highlights errors like that in red. Even Notepad++ (also free) is much better than notepad.

 

https://www.jetbrains.com/pycharm/

[HLT 0109]

There's a missing closing square bracket after the list of turnouts , and a missing closing round bracket on the last line.

 

- Nigel

Thank you Nigel - I'll give it a try.  Also had a PM from Steve.

 

Harold.