WiThrottle Turnout Control on JMRI -- or Not

Been meaning to ask this question, given several attempts to follow the documentation just never quite takes to a straightforward explanation of it among the JMRI documentation I’ve found. I have a NCE PowerPro that is linked via a serial cable and serial-to-USB adapter to the computer.

How do you get remote control turnouts to show up on the WiThrottle app?

At one time, I figured it would simply be an icon or something you’d activate. Then I thought it had something do with PanelPro, but there’s no clear path there to it, either. And I have no need to build panels, it’s all dark territory anyway.

I see something about a Webserver in JMRI, but again no clear path to just finding the small screen in JMRI from the WiThrottle that let’s you individually control turnouts.

Doesn’t seem like it should be like a big a deal to implement. Is there simply a setting or menu I’ve been missing that will add this to my WiThrottles?

And the same question applies to Macros. How do you access them fro the WiThrottle?

Mike,

On WiThrottle, on the throttle page, if you scroll through the engine functions, the last page should be turnouts. I do believe you have to add all turnouts in the “Turnouts” table on JMRI. Each turnout can have a name.

The web server feature serves inba web page ALL JMRI windows including the panel drawn. Very handy because now you can use WiThrottle or any browser on the network to get a rendering of your panel and visually click it.

When I rebuild my layout (right now house is under renovation), I plan to use Android tablets set to the JMRI web page as control paneks around the layout.

NP

NP,

Thanks, that’s a very useful start. I checked to see if I just didn’t scroll all the way down on the list the Wi Throttle generates and all I have right now are consists and individual locos. No turnouts down at the bottom.

Then I got to thinking, you said Throttle page and Function list, not the Address page. So I went and looked at the Functions. I do have a bunch of them, up to F27. Would those be the turnouts, just need to be relabeled?

I did enter turnouts at one time, but may not have saved them correctly or something. At least I know where to start and that’s progress. Will give this a try later when I have a break.

No, those are the rest of the functions. Turnouts should show up if you create a turnout table in JMRI. I’m going to guess you are right that you didn;t save it somehow - it can be tricky, and this made the rounds of the JMRI list for a while, but when you create panels you don’t ‘save’ them, you ‘store’ them. I gave up following the conversation after a while so I still don’t know what the actual justification for that is, when Linux, Mac, and Windows all use the word ‘Save’ to indicate committing your changes to disk.

–Randy

Randy,

OK, that was the final piece of info I needed. Found where to get the turnout table, “stored” it in the Throttle folder that contains WiThrottle, and it’s working. I see that I have Routes available also now. I presume that’s Macros in NCE-speak?

Thanks to both of you. I figured it would be easy once someone got me to the right path.

Well, mostly. All routes with a pure NCE system are macros, but not all macros are routes, since macros can do other things besides trigger turnouts.

–Randy

Close enough for what I have here. I use Macros solely to control access to my 7-track, double-ended standard gauge staging yard. One group , 1 to 7, operates both throats to line it up to receive or emit a train. The second group, 11 to 17, operates just the north throat to the specified track, with the third group 21 to 27, operating the south throat to the specified track. That’s so I can have trains working either end of staging indendently, although it’s really not busy enough to need it most of the time.

I’ll give it a try a little later, as well as fill in my other half-dozen or so so remote turnouts.

Glad the turnouts page is working Mike.

I have a Digitrax system. On it, the “Routes” table (everything in JMRI is in a table) sets a set of turnouts closed or thrown. This functionality is all coded in JMRI and not in the Digitrax throttle.

I like it this way better because all logic is concentrated in one spot, the computer.

Have you started on detection and signaling yet? With a layout like yours it will really light it up. Semaphores get expensive, but a few on your branch will be just awesome.

Later,

NP

NP,

I messed with the Routes screen a little and remain puzzled by it, cause I need to figure out what the mean by “trigger” I guess. So may have to wait this week. I’ve got an ops session on Saturday to prepare for and a dissertation draft due by Friday, so my hands are a bit full. Not a big deal, though, as Macros only apply to my standard gauge staging. Crews can call the dispatcher to line things up with a NCE hammerhead device, but mostly people what to run narrowgauge, so it often doesn’t matter.

For now, it’s all dark territory and will most likely staty that way on the narrowgauge. I’ve envisioned signals at several locations on the stadnard gauge, but just not needing it strongly right now. I do have a good resources to draw on besides the forum, though, if I do. An office colleague of my wife’s helps teach a course in signals in the RR engineering program at the big U in town. He’s a railfan/photographer, although not a model railroader.

The ‘trigger’ is the turnout you trigger that then fires the rest of them in a particular route. Sort of like your macro number. I haven’t tried it in JMRI, but in straight Digitrax, theis turnout number can be a real oen or a fake one.

Say your route needs turnout 10 normal, turnout 11 reversed, and turnout 12 reversed. You can call this route 1, and use turnout 1 as the trigger, such that when you set turnout 1 to normal, it sets the other 3. OR you can tie it to turnout 10, so when it is set normal, the other two are set. There are use cases for doing it either way. The turnout number is accessory address, so if the route was triggered by a non-existent made up address, you would operate that turnout from your throttle to fire the route.

–Randy

Randy,

Then this is sorta like a "turnout"being just about any decodered device, including imaginary ones?

That’s maybe what I was getting wrong, because I thought, the first one in either ladder will be easy, but then what about the rest, since they mostly start with the same turnout and I was thinking it won’t work if I give them all that same number?[*-)]

OK, I’ll fiddle with that more and see if I can do one, while trying to think outside the realm of the material world a bit.

So say you have a through track, with turnout address 10 for the turnout leading to the ladder. There are two others in the ladder, for 3 total ladder tracks. Call those address 11 and address 12. Tracks from top to bottom are the through track, then track 1-3. Assuming a standard ladder, no compound ladder tricks, any turnout set to straight through (closed, normal) (except for the first one on the through track, of course) leads to the next turnout up the ladder.

So you can make route 100, closed which sets turnout 10 to normal, train bypasses the ladder

Route 101 (and here you can make it closed or thrown, it’s just a trigger) selects track 1, which means it sets Turnout 10 reversed and turnout 11 reversed.

Route 102 selects trac 2, so Turnout 10 reversed, turnout 11 normal, turnout 12 reversed.

Route 103 selects track 3, so Turnout 10 reversed, turnout 11 normal, turnout 12 normal.

In each case you only need to adjust those turnouts that are involved in the route and may have been set differently in a different route. With this example, if after you’re selected track 3 with route 103, now you want a train to go straight through. SO you invoke ROute 100, which sets Turnout 10 to normal. The poisitons of turnouts 11 and 12 do not matter in this instance. Each route up the ladder though has to set the preceeding turnout back to normal in case a lower number track was previously selected.

It really is pretty much the same as a macro, just stored in the JMRI panel not the command station. SOme stationary decoders also support routes internally in the decoder, the concept is the same. There will be a series of CVs in the decoder where you load the needed switch addresses and positions for each route.

Generally this is for what you’ve aready used macros for. Selecting a yard track, or selecting a terminal platform. In the case of a passenger terminal, maybe there’s a double slip in the throat. Having routes defined makes

Randy,

Thanks for the detailed explanation. I’ll give it a try when I get a chance. Was going to tonight, but ran into another issue after rebooting the computer. My turnout table seems to have become disassociated from the WiThrottles. I did “store” it, and can still see it in the Throttle file where I placed it and it worked fine before. I can’t see any way to open that file and can’t see any other way than to maybe go back and re-enter it all. Is there a simple way to reassociate the turnout table and, better yet, ensure this doesn’t happen. I thought I was covered with the Store command, but guess not?

Well, this is not a good evening down at the computer barn. I tried to just build another turnout table like I did last night and it does not compute. The other tables I built last night were working, then I rebooted and despite being stored and visible and formerly working, now nada.

I also took a stab at the Macros with the NCE macro editor. It pulls them up, but at least one was incorrect as displayed and I can’t figure out out how to correct them. Down at the bottom is a Save button and it’s grayed out and thus doesn’t work. Tried a few things and don’t see anything changing.

All the cool options are enticing, but I’d just like a clear path to simple things to start with. Like many programs, it probably does a lot of things, but the proliferation of features seems to threaten the ability of new users to navigate beyond the multiple cul de sacs. There always seems to be the need to fiddle across multipls panels to get one thing to work. Might be easier to have more panels that do one thing simply. It’s a little like trying to follw the X-files if you don’t watch regularly. Mysterious is cool, confusing is just frustrating.[banghead]

Still no solutions, but what’s happening – or not – is more obvious now. Deeleted all 4 previous Turnout Tables. Like I did the first time, I rebuilt one and saved it in the Throttles location. It is among the choices you seem to have automatically come up and it worked before, so why not? Inside it were two .xml files showing Throttle and WiThrottle, so I made the Turnout Table the third file. Pulling up the WiThrottle. Yes, it’s there and work. OK. So I made sure to Store (save) both the File and the Panel. And it’s working.

So what is the one thing you’ll be doing a lot of with JMRI? Yes, Save (different from Store? I don’t know and they don’t say.) where it shuts everything down and restarts. No problem.

Except – POOF![X-)] – my Turnout Table has gone MIA when it restarts.

So maybe Store isn’t Save? There’s certainly no button for Save. Neither is there a button to do anything with the file except leave it where it is and edit it there. I have no problem with any of that either…

And my no longer functional Turnout Table is sitting right where I left it and where it worked just moments before I hit Save and restarted JMRI.

I do have a problem in that I certainly don’t intend to reenter the Turnout Table data every time after I hit save. I presume I can clean it out and rebuild it ever time, but that’s not going to happen. It ain’t 1995 anymore.

So, JMRI works well for some things.

For other things, it may work, it may not.

There’s no documentation for many small things that are very basic and lots of documentation for big cool things that may or may not work, but do you dare invest the time to do something when it just sits there and laughs at your gullibility that Store and Save are the same thing?

I know this is the sort of thing where they’d like people to take a more hands on approach to things. I’ve been involved in things like that before myself, including softwa

I’ve been frustrated over and over by certain spects of JMRI, it just doesn;t work in an intuitive way. I’ve kept my mouth shut on things like the Store vs Save debate because frankly I am not willing to contribute code - I HATE Java with a passion and I know enough other languages that actually work without weekly updates that I stay away. So I have no place to relaly complain to JMRI developers. My other experience was trying to do a simple automation loop on a friend’s layout, he had an irregular loop around his one town that he wanted to run 3 or 4 trolleys around, with them stopping so they didn’t run into each other. He picked up a BDL16 on the cheap and had it all wired in. JMRI detected it, and filled in the detection table, but I was getting a lot of false reads - the trolley would be on blokc 5, but 9 and 14 would also light up. Everyone said it was just because BDL16’s are old and don;t work with high frequency drive decoders. Frustration 1 was laying out the path. I missed one section, but you can’t go back and add it later - the use of XML makes a mess of that and they were out of order. I had to delete it all and redraw, making sure to not make a mistake. I got past that, but still the false detections messed up trying to run between waypoints using some of the scripts that people have provided. I finally gave up. Came back the next week, and my friend, who is a lawyer, not a computer guy, had downloaded a trial copy of RR&CO and HAD THE TROLLEYS ALL RUNNING all by himself. Yes, there is a huge price difference, free vs lots of $$$, but it’s the little things in JMRI, that just don;t make user interface sense, that are the root of most of the issues. I don;t even bother any more - I have no reason to save all my locos in a database (well, I do have them in a database, once concerned with the road number, maker, purchase date, cost, value, etc). I model a railraod and an era when the locos had nothing more than headlight, no special affects, and I c

Randy,

Guess I’m not alone in my frustrations[(-D]

I was really working up some enthusiasm on JMRI, which is rare as a 3-headed chicken around here. I actually get exposed to my fair share of frustration with what people are building, software-wise, because my wife is a programmer over at the big U. You ain’t seen nothing yet until you get a whole bunch of really smart people, only half of whom have even a clue about what the back end of software looks like, arguing over the architecture they should have had scoped out months ago – and suddenly want to do something different, because it seems like a small and easy enough thing…

So I have some understanding about such things. JMRI takes that and then blesses it with a volunteer base, something else I know a little bit about through herding cats as what was effectively the COO for a substantial non-profit. Volunteers are great, but they often have their own trajectories in terms of interests. They’re certainly not employees.

Really what would do JMRI good would be to spend 3 to 6 months on cleaning things up and making sure all the basic stuff is well covered – either good, easy to follow GUI or better documentation of the things 90% of users want and use. There would still be time to dream big about that next killer app, but let’s get the trains running on time, the trash taken out and make sure the fire alarms are working and the roof is not leaking. That might actually lead to more user engagement than the latest “here’s new cool stuff, now figure it out” approach. Because it’s sure got me down.

The “store vs. save” thing doesn’t make sense to me, either, but it’s never caused me any problems. I guess they way to think of it is that JMRI “stores” your panel/layout info by “saving” one or more files under the covers.

Anyway, populating and (saving or storing) your turnout table is easy. To populate it, with Panel Pro running just send a command to each of the turnouts on your layout. JMRI will “see” those commands and use them to populate the turnout table.

Then you have to (store or save) it, either in a panel or just as a table. That’s explained here, starting with the second section on that page.

There’s lots of online doc and tutorials available, including links to videos, on the JMRI web site. There are also a number of YouTube vidoes that user have made.

Having said that, yes, JMRI is all volunteer-driven so the doc may not be perfect. But you can always get the answers you need on the JMRI list where the folks who write the code hang out, and use those answers to update the doc and make it better!

Save seems to mean what it usually does. Store sounds a lot like Save, but Store seems to mean “It’s here now, but gone later, even though you can see it sitting right where you left it, except it’s doing nothing for you from that point on.”

Maybe Store is the zombie version of Save, because the only thing it really does for you is eat at your brain as you ponder why they didn’t just make it Save?

And if you actually need to use Panel Pro to make it work, why go to the trouble of making it almost work under DecoderPro? That just doesn’t build my confidence about jumping on the learning curve for PanelPro just to find out that may frustrate me as badly as this particular issue has done for me.

I suspect it’s more than one person every six months like me who gets into this ditch. How many just walk away at that point, muttering under their breath about the whole affair? And probably mentioning it to other people when they ask, “Say, how’s that JMRI thing going?”

If this was something unusual and arcane, like how do I signal a double slip switch with Pennsy position signal heads, I could completely understand. But geting to within site of the city walls only to find the gates locked againt the barbarians is rather deflating when you’re talking about something as basic and universal as controlling turnouts.

If this was something where enough bread crumbs had been left so you could find your way home, then it might be worth the trouble to document once I was all proud about working it out. But after spending several hours researching and poking around, there simply does not appear to be any way to make it work. Should I start trying to learn PanelPro? I just don’t see that, considering I have no need for signals or other such complications.

Considering it’s only faoir to give it a try in PanelPro, I did. And like Charlie Brown trying to kick that football…

It does exactly the same thing. Sure, manually load it as full of data as possible, because there seems to be no way other than to manually fill in the Turnout Table. But you’re just wasting time, same results. It’s also baffling when it tells me that a name has already been used, because I’ve deleted every visible file. Which may be the root of many of these problems, the curse of MS and all its goofy top heavy feature-bloat, but it has a hard time getting out of bed.

I may load it before an ops session and hope it holds up. Fortunately, most of the remote turnouts are on the standard gauge side of things. Those needing something thrown when using their WiThrottles will just have to call dispatch for help if it goes belly up. It would be a really neat feature, provided they can get the whole mess the 5 more yards it needs to get to the finish line. As it is, turnout control is clearly not ready for primetime in JMRI. Even if I wanted signals, etc, which i don’t, at this point I’d be seriously considering other options before dropping the big bucks on a bunch of hardware that needs support from a program that can’t find the file you just handed it.