DS64's, jmri, routes, and all that

[GaryHinshaw]

[Sorry for the long post.]  I've finally finished installing and wiring the remaining Tortoises in my staging yard and I'd like to make some headway on the control interface for operating it.  I have some DS64 stationary decoders to control the turnouts and I'd like some advice on the best way to configure them for my application.  I'll start with a wish list and then pose some questions.  The yard is a simple stub-end setup with 9 storage tracks converging to 1 through a compound ladder with 8 turnouts run with two DS64's.  Here is the wish list, in order of importance:

1. I want to use routes to enable one-button control of the ladder based on the track being accessed.
2. I would like to be able to operate the routes from the computer (or a wireless tablet talking to the jmri server).
3. I would like to have local push-button control (one button per track), and it would be nice if it could function without jmri running.
4. I would like to have the option to lock the control panel so that the ladder is only operated by a dispatcher/terminal manager.

Here are my questions:
* I think I know how to achieve either 2 or 3 separately, but I'm not sure if I can have both simultaneously.  Can I set up routes in jmri and locally (either in the DS64's or the DCS100) independently?  I know the DS64 can operate a single turnout from either jmri or a local pushbutton, and I see that jmri correctly picks up the turnout state when the push button is used, so it seems like it should work with routes.

* I gather that routes are much simpler with jmri.  Can I configure the push button inputs to activate routes via jmri, so I don't have to program two sets of routes?  (I realize this would require jmri to be running though.)

* It looks like I can lock local control of a DS64 with OpSw 10, but that seems to be on a per DS64 basis.  Can I set up scripts that lock particular combinations of DS64's with one click in jmri?

Thanks in advance for any suggestions you have.

-gfh

[jagged ben]

All of these replies are 'to the best of my knowledge', which may have gaps.  There are probably work arounds for the problems I'll mention.  The JMRI yahoo group might be a good place to ask.

1. I want to use routes to enable one-button control of the ladder based on the track being accessed.

I believe with DS64s you would basically have two general options:  1) use the DS64 inputs directly, or 2) connect the buttons to something else that would generate turnout commands.  The something else could be a RR-cirkits Tower Controller which would generate turnout commands on loconet.  Option 1 would not require DCC to be working if you power the DS64s with something besides DCC track power.   Option 2 would require DCC to be operating but not JMRI.

One thing I'm not sure about is having a route that uses both DS64s.  You might have to use a couple 2 pole buttons to send separate electrical signals to each DS64.

2. I would like to be able to operate the routes from the computer (or a wireless tablet talking to the jmri server).

This is relatively easy.  Setup a panel in JMRI or some other software which sends turnout commands to the DCC system.

3. I would like to have local push-button control (one button per track), and it would be nice if it could function without jmri running.

See answer to first question.  Not very hard. 

4. I would like to have the option to lock the control panel so that the ladder is only operated by a dispatcher/terminal manager.

Now you are getting greedy.  It will be most difficult to combine this with the 'without jmri running' part of wish #3.  Not sure if that is even possible with software, but see advice at beginning of post.  It would not be so hard to set up this functionality with software if you were willing to have JMRI operating all the time.  But I believe the easiest solution might be a hardware option; Put the common(s) for the pushbuttons on normally-closed relays that can be opened by some other hardware controlled from JMRI. 

Here are my questions:
* I think I know how to achieve either 2 or 3 separately, but I'm not sure if I can have both simultaneously.  Can I set up routes in jmri and locally (either in the DS64's or the DCS100) independently?

I believe it is simple to program the routes in the DS64s to respond to turnout commands.  Then you can send turnout commands from throttles, computers, smartphones, over the internet, however you lik.

*

I gather that routes are much simpler with jmri.  Can I configure the push button inputs to activate routes via jmri, so I don't have to program two sets of routes?  (I realize this would require jmri to be running though.)

I could be wrong, but I don't think the DS64's own inputs can activate jmri programming.  You'll need other hardware for that.

It looks like I can lock local control of a DS64 with OpSw 10, but that seems to be on a per DS64 basis.  Can I set up scripts that lock particular combinations of DS64's with one click in jmri?

I could be wrong, I believe you have to physically press a button on the DS64s to change this setting.   It doesn't sound like a setting that Digitrax set up to be changed during normal operations.

[GaryHinshaw]

Thanks for all the feedback jb, I'm going to do some experimenting and report back.

The first experiment is a simple one with OpSw 10: it behaves just the opposite of what I expected.     jmri has a Configure DS64 tool that lets you change OpSw settings on the fly via this control panel:



You would think that ticking OpSw 10 disables local push button control of a turnout via the S input, but it has just the opposite effect: ticking OpSw 10 disables remote control via jmri or the throttle, but still allows local control.   

On the the next test....

[Bangorboy]

Gary,

It's been a while since I played with this -- family health concerns -- but I remember clearly this much:

1.  I hated doing routes in the DCS, and in the DS64s for the same reason; the routes get erased if you reset the device.
2.  Routes are easy to set up in JMRI, and you can save your configuration and reload it anytime to restore the routes.

I have a double ended staging yard with ten tracks, a simple ladder on one end and a compound ladder on the other.  Entry to a given track on either end is controlled by clicking one icon, which triggers the whole route to that track.  Later, I plan to install several small touch screens around the layout which will allow me to trigger these icons with a finger touch as opposed to the current mouse clicks.

Another point, in case you decide to go with routes in your DS64s, you can make the last turnout in a route be the top number for another route.  A Ds64 route can have up to 8 turnouts included.  If you need more than 8, make the last turnout be the trigger for another route of up to 8 turnouts.  BUT:  program the second route on a different DS64 from the route which triggers it.  One thing to note:  The route doesn't have to include any turnouts physically connected to that particular DS64.  All of the turnouts on a DS64 can be controlled by routes stored on other DS64s.  There's some kind of a quirk in the DS64 firmware that makes it work better (more reliably) this way than having it trigger another route on the same DS64.

Also, just FYI, the JMRI developers didn't set up a way for JMRI to read or program routes in DS64s.  I heard, but can't cofirm, that they thought the JMRI route implementation was better, so made the DS64s routes unnecessary.  Whatever, if you want to read and program DS64 routes with your computer, you can download a program called Loconet Checker.  Stephan Trachsler has written a gem.  It will read all the settings on all of your Digitrax Loconet devices, and you can save the baseline.  If one device loses its settings, it can restore them.  If you want to change settings you can use it to do that.

I'm getting long-winded here and may be wandering into areas you don't want to hear about.  I'm just getting back into running my layout again as of last week.  If you have any questions, I can try to answer them, and can probably go to the layout and test them for you.

[GaryHinshaw]

Good info Bill - thanks.  Your description of internal and cascaded routes is much clearer than Digitrax's!  I realize that's not saying much, but it should still be noted.

I set up my first routes in jmri this evening and it was dead simple.  For a 2-turnout, 3-route configuration exiting the yard, it took me less than 10 minutes to define the turnout and route tables and have them operational, starting from scratch.  Cue the Tortoise Symphony!  Given that simplicity and flexibility - and the fragility of internal routes - I vastly prefer jmri as the way to go.

That brings up a philosophical question: should I be wary of implementations that require jmri to run the layout?  Up until recently I have been avoiding this because it's a single point of failure, but it really isn't any different than relying on a command station, etc. to function, and it only takes two minutes to plug the laptop in and boot up jmri, so it's not a major inconvenience.  Anyone have any horror stories about going this route?  (Pun intended.)

As far as user interfaces go, I love the idea of using small touch screens for control panels, as I noted in another recent thread.  This seems entirely feasible with jmri, and by the time you factor in the cost of buttons and indicators, maybe not even that much more expensive.  I'm going to start playing with panels on the laptop soon to get a better sense of what's possible now.

-gfh

[Bangorboy]

it only takes two minutes to plug the laptop in and boot up jmri, so it's not a major inconvenience.  Anyone have any horror stories about going this route?  (Pun intended.)

I use a discarded desktop PC now, and have used a discarded laptop in the past.  You don't need much computer power to run JMRI.  You can avoid having to plug your good PC in, and you can set up the JMRI computer to automatically load and open JMRI and whatever wndows within it on bootup.

I'm going to start playing with panels on the laptop soon to get a better sense of what's possible now.

Biggest advantage of doing the panels in JMRI is making changes.  You don't have to go to great trouble to rebuild a physical panel to add, remove or relocate items on the panel.  And if the new panel doesn't work as you planned you can go back to the old one with no rewiring.  (You did save the old panel, didn't you?)

edit:

I have been avoiding this because it's a single point of failure

  You answered your own concern there.  I haven't had any problems with JMRI through several versions and updates.  All have worked well.  At first, I thought you were avoiding it so you wouldn't have to bring the laptop into the train room to run trains.  You can still operate the DS64s with pushbuttons or throttle commands even with JMRI turned off.  You would lose the routes in JMRI without it.  See my comment above concerning using an old computer to run your JMRI and put a copy of Loconet Checker on there.  You'll use it.
end edit

[jagged ben]

... That brings up a philosophical question: should I be wary of implementations that require jmri to run the layout?  Up until recently I have been avoiding this because it's a single point of failure, but it really isn't any different than relying on a command station, etc. to function, and it only takes two minutes to plug the laptop in and boot up jmri, so it's not a major inconvenience.  Anyone have any horror stories about going this route?  (Pun intended.)
...

A couple potential pitfalls, but they may not apply to you...

If your garage isn't climate controlled you may no want to leave a dedicated computer there.  We unfortunately have this situation at our club and we've lost a couple computers over the years (like, they failed to turn on), and our guess is that they couldn't handle the temperature variations.

Also, at the club I've lobbied for a maximum amount of 'analog' functionality without any digital components, meaning JMRI, decoders, DCC, etc.  That's because there's only two or three guys at the club who know how to get most of that stuff working and if they are not there on a run day, we'd be SOL.  But since this is your personal layout, and presumably you're going to be around with the knowledge to re-program decoders or anything else when needed, that probably doesn't apply to you.  (Sidenote though:  Keep meticulous documentation and digital backups of your programming!  Use JRMI for all decoder programming so you can store the programming in the roster and re-program in seconds in case you have to replace a unit.) 

This also leads to a larger point:  On the whole I feel that the more significant choice is relying on digital components for basic functionality at all.  Between DS64s, JMRI, and a homemade diode matrix, I believe the likelihood that they will require service, maintenance or replacement is in the order I listed them, with the first two far ahead of the third.   I think it's not very likely that you will find JMRI to be less reliable than the DS64s themselves.  My choice would be to build all the digital stuff on top of an analog substructure that works without decoders at all  (and then you have two systems for operating in case one fails).    But that wasn't among the options you asked about, and you certainly don't need to do it if digital works satisfactorily for you.

[GaryHinshaw]

Thanks for the thoughtful comments gents.  I spent a bit more time over the weekend setting up my first panel in Panel Pro, and, like everything else I've tried in jmri, it was very straightforward.  In relatively short order I was able to control turnouts from the panel graphic and have the turnout state displayed on the panel, all with a very minimal DS64 setup.  Power at your fingertips!  This experience gives me a great deal of confidence in jmri, and I'm strongly leaning towards handling all digital turnout control using it, rather than local inputs to the DS64's.  That still leaves a number of questions:

* How should I port control from the laptop (where the panel currently resides) to the operators?  I *believe* that jmri can serve these panels through its web server and that a wifi client tablet can act as a local panel, but I have not tried that yet.  This has immense attractions: its totally wireless and easily reconfigurable, (and panel changes automatically propagate to the client).  If it really is that simple, I'm tempted to dispense with hardware control panels entirely.  (Though turnouts in industrial areas would still be hand-thrown or analog powered.)

* Can routes be controlled from a panel?  Single turnout control is straightforward, but I have yet to see how to link a panel element to the route table.  I haven't looked at all the documentation yet though.

* If I go this route, is it foolish to not provide some form of analog control of the turnouts? (By this, I mean something like a diode matrix for route control in the yard.)  It adds quite a bit of work and hardware complexity for something that would be just a backup.  This is just echoing jb's last comment; now I solicit opinions from the group.

-gfh

P.S. Bill, I looked into Loconet Checker and it looks extremely useful.  Sadly it's only a Windows app at this time, so I'll have to look into Wine or such to run it on my Mac.

[Bangorboy]

Gary,

* How should I port control from the laptop (where the panel currently resides) to the operators?  I *believe* that jmri can serve these panels through its web server and that a wifi client tablet can act as a local panel, but I have not tried that yet.  This has immense attractions: its totally wireless and easily reconfigurable, (and panel changes automatically propagate to the client).

You're assumptions are right on this part.  Not sure wether I'm going to go wifi or USB for my panels.  I think I'm going to use USB connected touch panels as I think they can be considerably cheaper than tablets, etc.

* Can routes be controlled from a panel?  Single turnout control is straightforward, but I have yet to see how to link a panel element to the route table.  I haven't looked at all the documentation yet though.

Yes.  In the PanelPro menu, see Tools >> Tables >> Routes.  You can create a route and add turnouts to it, specify which turnout triggers the route, etc.  The trigger can be an actual turnout, or a virtual one (they call it a "system turnout").  When you click Add/Edit Route a window will open with all the parameters, including a list of all the turnouts in your Turnout Table to select which ones are in the route and which way they will be thrown/closed.  You do have to add the turnouts to the Turnout Table before you can include them in a route.  Oh, by the way, if you are looking at the layout diagram this choice is not under tools in that window -- on the menu at the top select Window >> PanelPro, then go to Tools >> Tables >> Routes.  You can activate the Route from a Sensor instead of a Turnout.  That's the way I control mine.  And you can have the routes activate a Sensor of your choice when the route is set.  For instance, I have a route which sets all mainline turnouts to enable a free run around the layout.  When it is aligned, it lights a green light on the panel.  If changes are made and then later reversed while operating and the route becomes aligned incidentally, the light will come on again.
Enter
Your specific comment about linking a panel element to the route table:  In the route edit window look for the line "Enter Sensors that trigger this Route".  You can put in up to three.  Alternatively, just below that there is a place to Enter a Turnout that triggers this Route (optional ).

* If I go this route, is it foolish to not provide some form of analog control of the turnouts? (By this, I mean something like a diode matrix for route control in the yard.)  It adds quite a bit of work and hardware complexity for something that would be just a backup.

Totally up to you whether you want a way to control the turnouts with pushbuttons.  If you are using solenoid snap switch turnout motors, a diode matrix would work.  If you are using Tortoises or other stall motors, diode matrix won't work, but Allen Gartner has several diagrams for how to set up routes.  Not sure how that would work with JMRI.  However, as long as you can identify the turnout numbers you can set each turnout individually with a throttle as a backup to the routes.

One caution:  Be careful you don't set up a route where the route triggers any sensor which triggers the route, or a sensor which triggers another route which in turn triggers a sensor which triggers this route.  You get the point.  Any circular path like this will continuously cycle the routes, turnouts and sensors, creating a problem.

[GaryHinshaw]

Very helpful Bill!  I had yet to really grasp the role of sensors in jmri, but with your hints, I read more about using them to trigger routes here,  specifically the subsection Controlling Routes from Sensors.  The key thing I was missing is that internal sensors can be used as (virtual) control panel push buttons and they can be easily linked to route activation.  So I now have a prototype panel where the sensors/buttons trigger the routes by track number, and they change display state so that the selected route is active (display lit) and the rest of the routes are inactive (display dark).  This is exactly what I wanted, and it was all trivial to set up once I knew the jargon.  Even better, none of this functionality requires the inputs of the DS64's to be hooked up - just the outputs to the Tortoises, so the hardware implementation is pretty simple too.

I think I'm going to use USB connected touch panels as I think they can be considerably cheaper than tablets, etc.

If you have any suggestions for brands and models of touch panels, I'm all ears.  I haven't researched that at all yet, but I'm now pretty certain this is the way I want to go.

And thanks for the warning about the dreaded infinite loop.  Sounds like the voice of experience.   

[jagged ben]

If you are using Tortoises or other stall motors, diode matrix won't work, ...

Not true whatsoever.  See diagram I posted in this thread.

Now if you are talking about a backup option for decoder controlled turnouts, it can be a little more complicated.  That's because you are talking about hooking up pushbuttons and decoders in parallel, and you need to be sure that's okay with the decoder and/or its warranty.   But it can be done.  The Lenz LS150 has this as a documented feature.  It may work with other decoders, too. 

[Bangorboy]

Yes, Ben.  You're right.  I was talking diode matrix and thinking capacitive discharge circuits.  Don't want to be zapping Tortoises!  But I should be more careful about what I'm talking about.

On the local pushbutton controls, DS64s can be set up so they will operate from JMRI as discussed, but also have pushbutton operation of the turnout outputs.  It can be set two ways:  Use two pushbuttons, one for Closed and one for Thrown; or use a single pushbutton to toggle the output.  The wires on the pushbuttons go from a common on the DS64 to the button, then to the input on the DS64 for that particular turnout.

I haven't looked at this for about 15 months, so I'm straining to remember.  I think if you do only the inputs from JMRI via Loconet and the hard inputs from pushbuttons, then JMRI will not update as the turnouts are changed locally.  I think you have to set up the DS64 somehow to give feedback to Loconet for JMRI to see the changes.  I can't remember if that's internal to the DS64 or you have to use an output from the DS64 to trigger a sensor which then puts the info on Loconet.  I'll have to look into that, but maybe someone can answer from the top of their heads.

Also, with my 15 month hiatus my info about USB touch screens is quite outdated.  I'm going to have to start from scratch to do that.  Sorry. 

It'll probably be a couple months out before I do that.  Right now, I'm trying to get occupancy detection and transponding working in about four more blocks, so my Surroundtraxx system can follow the trains.  JMRI does track a specific loco through the blocks I have set up so far, and the Surroundtraxx sounds awesome, but is non-directional until I get the blocks programmed into it.

Yes, sadly the infinite loop problem is described from experience.  Not pretty

[GaryHinshaw]

Ok, a brief update.  If I wire push buttons to the DS64 inputs, I can control the turnouts either from the local push buttons (with or without jmri running) or from the jmri panel.  In all cases, the turnout state is correctly recorded on the panel and in the turnout table, without any additional sensors.  Somehow the DS64 is providing that information to Loconet and jmri. 

The one thing that is slightly inconsistent with my current testbed is that the route sensors I mentioned above only reflect the state of the last route selection.  If I change single turnouts "by hand" (either local push buttons or jmri single-turnout commands) the route sensors do not track which route is lined (but the track diagram does).  I suspect I could work out a Logix table that combines turnout state and route state to accurately update the sensors, but that is probably a project for another day.  Also, I think I am happy to have a backup panel that consists of push buttons hooked up to the DS64's, in case I don't want to boot up jmri.  If I decide I want "analog routes" later, I can add a matrix, but I don't think anything I'm planning now precludes doing that in the future.

Thanks again to both for the very helpful input.

[jagged ben]

... Somehow the DS64 is providing that information to Loconet and jmri. 

In JMRI, find 'Monitor Loconet', and you can get a clue as to how. 

...  If I decide I want "analog routes" later, I can add a matrix, but I don't think anything I'm planning now precludes doing that in the future.

Nope, it doesn't.

[Bangorboy]

Glad you're happily making progress, Gary.  I'll be watching to see if you have more questions, as I'm sure Ben will too. 

One thing that puzzles me, you said

If I change single turnouts "by hand" (either local push buttons or jmri single-turnout commands) the route sensors do not track which route is lined (but the track diagram does).

Did you enter the sensor in question into the route editing window to be set when the route is set?  If I change my routes by operating turnouts individually, the sensor changes as the route is interrupted or again as the route becomes satisfied by individual turnouts being aligned as defined in the route.  I mentioned earlier my route to set the mainline.  It works exactly that way.

You can have great fun with the Logix programming.  Press on!