Yeah, it can be a bit baffling. You should have a TurnoutTableConfig.xml file saved in DecoderPro. I get to it by going to PanelPro, clicking the Panels menu, then selecting Open Panel.
My Turnout Table now comes up on launching JMRI, so haven't had any troubles since getting it working. But that may just be how I blundered into things and may not be how your JMRI is configured. Stevert's explanation is a good one in the post just above here.
Mike Lehman
Urbana, IL
you can only store in the tools, tables, turnouts. Why not open existing turnout table that was preiviouly stored?
And where is the xml file and the name of it??
or is the turnout data stored in the profile xml files ???
If i use the preference, start up, open turnout table -- no data even if i have stored it before shutdown. how to specify what turnout table i want to load???
even in version 4. this problem still exists.
StevertEdit: I forgot to mention that you can also have that saved file loaded automagically when JMRI starts: Edit-> Preferences-> Start Up-> Files-> Add File
I think that's actually what did it. All I know is I could see the file, but it wouldn't be accessible on the throttles. Believe me, I'm not using "linked" as a technical term, just as an indication things started working together finally. I go straight into MEGO (my eyes glaze over) about three steps into setting up anything that requires more than a single button push. I suspect about half the population is like this, but that's a very unscientific estimate.
Having lots of options/preferences to configure is great for flexibility, but I get totally lost with 'em. Heck, I have trouble keeping Word files straight a lot of the time.
I do appreciate the patience you've shown.
mlehman Stevert So a single panel XML file with your stored layout configuration can be created and/or opened in either of them without needing any sort of "linking". OK, that's good to know. That crucial initial link to the file is required, I assume. It doesn't happen automatically, although the file does seem to generate when you Save as it was there, just didn't seem to do anything. I suppose there are occassions when you might not want to reference that file once you've saved it, but I can't imagine what that would be. This is one place where having the link be default/implicit in saving it would be good for rank JMRI newbies like me. Or maybe having a "stupid easy" build available for WiThrottle users to make entry easy for the most common features they'll likely use?
Stevert So a single panel XML file with your stored layout configuration can be created and/or opened in either of them without needing any sort of "linking".
OK, that's good to know. That crucial initial link to the file is required, I assume. It doesn't happen automatically, although the file does seem to generate when you Save as it was there, just didn't seem to do anything.
I suppose there are occassions when you might not want to reference that file once you've saved it, but I can't imagine what that would be. This is one place where having the link be default/implicit in saving it would be good for rank JMRI newbies like me. Or maybe having a "stupid easy" build available for WiThrottle users to make entry easy for the most common features they'll likely use?
Mike,
You seem to want to believe that some sort of file "linking" needs to be done. That's not the case!
Storing your layout state (panels/tables/etc) causes JMRI to save an XML file. Where it's saved is determined by either the defaults in your preferences or profile, or by you via manual intervention to override those preferences.
When you want to reload that layout state, you simply have JMRI open that saved XML file, no matter where it is**. That's all there is to it!
**The "Open Panels" dialog, of course defaults to the location you've specified in your preferences. After all, that's what preferences are for. But it's just a normal file-selection type of dialog, so you can point to a config (panel) file that's located anywhere the computer has access to. That can be a local hard drive, a network share, a USB drive with your friend's panels, or whatever.
Edit: I forgot to mention that you can also have that saved file loaded automagically when JMRI starts: Edit-> Preferences-> Start Up-> Files-> Add File
StevertSo a single panel XML file with your stored layout configuration can be created and/or opened in either of them without needing any sort of "linking".
mlehman I suspect saving it in both Decoderpro and PanelPro and linking the files correctly after many, many tries finally did it...but it's really just a mystery to me.
I suspect saving it in both Decoderpro and PanelPro and linking the files correctly after many, many tries finally did it...but it's really just a mystery to me.
There really isn't any mystery to it. You simply have to "store" the layout information (panels, tables, etc) by "saving" the physical panel file that contains that information.
For example, my stored configuration contains two panels (one of the entire layout and one of the yard area), my turnout table (which includes all my turnouts and all my DS64 route triggers), a few internal sensors in the sensor table, and a few Logix. JMRI puts it all in a single XML file.
When you you need to "bring back" that stored configuration, all you have to do is open the stored panel XML file that contains it.
And again, as I mentioned before, DecoderPro and PanelPro are both entry points into the same back-end code. They are designed to promote different functionality, but you can do everything from either of them.
So a single panel XML file with your stored layout configuration can be created and/or opened in either of them without needing any sort of "linking".
I'm happy to report that I somehow muddled through the complex array of screens and have managed to save and recall my Turnout Table, instead of having to re-enter it at every reboot. How? I have no idea, so I'm not sure I'm much help. I suspect saving it in both Decoderpro and PanelPro and linking the files correctly after many, many tries finally did it...but it's really just a mystery to me.
So I did want to add a happy conclusion to this very frustrating thread. I don't intend to bash JMRI, just note that some really basic stuff is more arcane than it should be to get folks in the door and comfortable with using it. I tend to be stubborn, so it worked out in the end. Makes me wonder how many throw up their hands and walk away instead, which isn't good.
Stevert,
Not bashing JMRI, just observing from a system user's point of view. I suspect it's something about finding my way through the thicket of options for something that should be pretty intuitive -- or at least has a button to push instead of a house to build. Or maybe even just a straighforward, step by step.
I understand about the desire of software engineers to provide lots of options, but that is pretty immaterial to most users. They want something where functionality is inherent, with options for when you feel brave enough to venture off the path and into the woods. In that sense, JMRI is getting close. The WiThrottle is a great answer to several of the needs I have at this point and remains so. It's just frustrating it's that easy to walk in and get that close to it meeting every need I have. Kind of like one of the horror movies set in a mellow old mansion when you suddenly open the wrong door and find yourself staring into an abyss. Maybe it's just dark down there, but the sulphorous smell make it's seem more like the Gates of Heck.
I'm not sure you're interpreting the 1150 number right. It may be an indicator of great popularity. It may also represent 1100 times when people find themselves up the creek when they thought they packed a paddle and 50 who take to it like a duck to water. The thing is it doesn't reflect frustration levels that may be encountered after you have the software at hand. Most people don't join groups in the first place and it's becoming even less of a habit. Google has changed the equation for that, among other factors. If you can't really search and easily find an answer then you tend to come to the conclusion there is no answer.
A good example is this page, which I assume works so long as you keep it on the PC, laptop or whatever you're using and don't shut it down after entering the turnout table, as it seems to do just fine.
http://jmri.sourceforge.net/help/en/html/tools/Turnouts.shtml
The question seems to be "what am I doing wrong in saving/storing/whatever"? I can only assume it would work on the WiThrottle at the point (but I could be wrong) presuming it could find it's way to the data, which is after all just sitting there in plain view.
I've tried it enough different ways that I need to keep coming up with new filenames to enter the data, because even after deleting the old files that don't work to try again, it still insists they're being used -- somewhere down that scary hall to the basement I guess.
It would be a merely aggravating issue and not a showstopper if there was an easy way to repopulate the turnout table when it loses its way after every reboot. But there isn't. It has to be manual data entry all over again. That Turnout Table you just made is old news once JMRI reboots. Why is that the default instead of simply returning to the previous state? I've tried various ways to get it to show up at startup, but the only thing I get is the blank form and not any I already filled out. What's weird is that sometimes it's not even listed as an option in the choices on the Start Up menu. Other times it is, I guess maybe after I get frustrated and delete the old one. Then it tells me the names I selected are still in use. At that point, I'm resisting the urge to find a baseball bat and just smack it...
Panel Pro, Decoder Pro, and Decoder Pro 3 are all just different entrance points to the same back-end code. All the same functionality is available from any of them, although depending on which front-end you use the menu items to access that functionality may vary. I assumed, since you were working with turnouts, that you were using Panel Pro. Bad assumption on my part, but the instructions I gave would work no matter which entrance point you used.
But regardless of my bad assumption, JMRI works well, and has a very active user community that the developers frequent and where issues and problems are discussed, and in most cases, resolved. Their Sourceforge project page says it's been downloaded 1150 times so far this week alone, so somebody likes it.
Unfortunately, you now seem to be at a point now where you'd rather bash JMRI than learn how to use it. I cannot offer any further assistance.
Hi Mike,
I'm no jmri expert or computer expert. I would strongly recommend that you join the Yahoo jmri users group. The top developers hang out over there and they have been very helpful for me.
They have turned a computer illiterate into a jmri using fool.
Good luck
Derek
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.
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.
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!
Randy,
Guess I'm not alone in my frustrations
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.
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 can program an address faster with my throttle than with JMRI. I've standardized on Loksound for sound, and as such purchased a Lokprogrammer. JMRI will NEVER be able to reliably and quickly read an entire Loksound decoder, since they are limited to publicly available protocols. Loksound has a proprietary protocol in addition to normal NMRA programmign methods, which allows the Lokprogrammer to read or write the entire decoder in a minute or two.
I REALY REALLY don't want to write my own code for Loconet, but JMRI is the only option with real looking CTC panel controls. Eventually I plan to have a physical CTC machine, but even then I need somethign in between to be the logic glue. Doing panels and setting the logic USED to be VERY easy in JMRI. I haven't tried with any of the newer versions, I sure hope it still is.
I can't say where the change happened - I think in tryign to add even MORE stuff to the suite - is used to be basically programming and panels. Then they added operations and a bunch of other stuff, and IMO some of the original 'base' feature have suffered. Ops is more or less a database storage and matching thing, it really has little to do with DCC control or programming.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
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! -- 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 software. But there's a whole lot of mystery stuff going on and much that simply baffles, as in where do you turn next. No, it's not joining another mailing list. That's a bad habit I've recently nearly broken a very bad habit, so just not going there for reasons unrealted to JMRI per se. However, if basic things are so difficult and undocumented, then it will eventually cause a project like this to grind to a halt. There's no easy door in and most people don't want to learn the magic handshake anyway, they just want to looks things up and try them. When you're rewarded by the coolness, that works well. Here, you're trying to keep you nose above the mud as you slowly sink from sight...
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.
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?
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 it each for someone to make the correct settings so their train can enter or leave the chosen track without running against a switch set wrong. We have a double slip at the exit of one of the yards on the club layout and until it was electrified (worked fine manually, it was a Peco) and put under dispatcher control, people would always have one set of points set wrong on it and inevitably derail. Now it's all controlled b the dispatcher with JMRI and routes set up - you call in an ask for permission to enter the main from whatever track number you are on and one click sets everything to line you out.
You would typically NOT use routes for just one turnout, and for operational flexibility, probably not for both ends of a passing siding - ie, a route that sets both turnouts either for the main or for the siding, since this could interfere with more complex movements like doubling the train for a saw by, or maybe directing two short trains into the same siding to let a third past.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.