Skip to main content

PanelPro™

Other Apps

Tools

JMRI provides powerful tools for working with your layout.

Layout Automation

JMRI: PanelPro Frequently Asked Questions

How does JMRI tie into the rest of my layout?

Jim Betz responded with this on the JMRI User's alias when asked for an overview:

  1. JMRI works like a throttle - it sends and listens to the messages on the "command bus". Nothing more, nothing less. And that is actually - A LOT - and is the true beauty of JMRI. In the case of DecoderPro the commands that are being used and monitored are those related to programming a loco. In the case of PanelPro the messages/commands that are being used are those pertinent to block occupancy, turnouts, etc.
  2. Each system has its own "command bus" or "computer interface" - i.e. its own set of commands (think 'command format') that it uses. This is why you can't use a Digitrax throttle on an NCE system. Many people refer to the command bus as a "throttle net" - to distinguish it from the track bus. And it is important to note that the messages on the two are not identical in all cases. Some systems are similar enough to each other in order to make it possible to use a throttle from one on another ... but this is relatively rare (very few layouts actually make use of it). Another solution is CMRI - which has its own command set. JMRI also is smart enough to "speak CMRI" (as well as the ability to "speak" Digitrax and NCE and Lenz ... etc.) The difference being is that CMRI is a command set and hardware that is focused only on the RR support systems (signals, turnouts, etc.) and does not have the ability to control or program trains. And, in point of fact, does not "know" whether the layout is DC or DCC. Most of the layouts that have implemented CMRI recently have used the CMRI hardware and JMRI (PanelPro) for the human interface.
  3. On DCC layouts the command station is the interface between the track and the throttle/command bus. You use the throttle bus to acquire a loco ... and to send control messages to the command station - which 'forwards' your throttle changes to the locos ... and to the stationary decoders ... via either the track -or- command bus (or both).
  4. It is possible - some will even say desirable - to separate your train support (track bus) from your layout control support. Although it may not be intuitive - you don't have to use the same system that you use to control trains to control the turnouts and signals - simply because messages don't need to cross that boundary. This is why some have recommended you consider an environment such as NCE for the trains and CMRI or Digitrax for the layout support (PanelPro).
  5. Because Digitrax and CMRI have published their interfaces there are more products available for layout control for those two systems than for NCE. Both RR-CirKits and Team Digital have excellent products out that work for Digitrax (for instance). As far as I know there are no such products for NCE. I do not know what is/isn't available for Lenz.
  6. PanelPro is still developing at a rapid rate. Many layouts are already up and running using PanelPro - but the most recent developments that have just recently been made available in PanelPro make using it a -lot- easier than it used to be. Actually, if you are talking just turnouts and block occupancy then PanelPro has been usable for some time. Signaling is getting better all the time.
  7. When you start doing signaling then "everything changes". Because signaling requires that the block occupancy and turnout status be used in the decision process of "what aspect should be displayed on which signals at this point in time". This requires layout specific code/logic. I'm assuming that you want a computer to make these decisions. It is possible to implement a system where a human being, usually the dispatcher, does all of the decisions ... the more complex the layout/signaling system the more errors the dispatcher will make. And there is also the "workload" issue(s)... but a computer running PanelPro is usually loafing and has more than enough power to keep ahead of the needs of the layout.

    Implementing layout control (turnouts, block occupancy, signals, etc.) is not an "easy deal". And, in my opinion, it is not something you should attempt to teach yourself - or to do it alone with just the help/guidance of online lists such as this one. I am not saying "don't use online" ... I'm saying that if you want to do this as easily as possible then you should seek out those who have gone before and enlist their face-to-face support/guidance. Yes, you can do it your self - no, that's not the best way to do this and you will find you make -many- mistakes that will cause considerable delays and rework. Many layout automation projects have gotten stalled for just this very reason.

    And just so this gets mentioned ... adding capabilities such as block occupancy detection, computer controlled turnouts, and signals is not inexpensive and needs to be budgeted/spec'd out. And you may find that you will need to re-wire some or even major portions of your layout in order to support them correctly/at all.

How do I save my work?

There are several ways to save your panel. This is because the program has to store both configuration (turnouts, sensors, etc) and layout (the details of your specific panel) information.

Usually, the easiest way is to use just one file to contain everything. For example, you can store your panel(s) in a file called "MainPanel.xml" (or something like that), and set the preferences to load that file. Then, all you have to do is save that file again whenever you change something. One caution: Make sure that you still have the panel open when you save the file! If you close it, then save the file, it will of course write a version of the file that doesn't show the panel. And save this file from the "Panels" menu, using the "Store Panels..." item.

This works because panels are stored with all the configuration information at that same time (which guarantees they'll work when reloaded)

Can I store just the configuration information?

You can store just the "configuration" information in a file, which you can save without worrying about whether your panel(s) are open, etc. If you do this, you can also save your panels to their own, separate files.

To do this:

This puts config info, but not panels, in the file.

Now, to ensure this configuration information automatically loads when the program starts:

Where should I put my custom icons and other files?

The best place to put your own files is in the JMRI Preferences directory (all JMRI apps use the same directory). You should put any locally-modified versions of files here so they don't get overwritten by a new version of the program. Any files that the program writes to contain local information, e.g. roster entries, are also written here.

The location of this varies by computer type.

Make sure you find the preferences, and not the original application package. They are kept separate to simplify updating the program version. You'll know you've found the right place if you see the preferences files that store your applications settings: PanelProConfig2.xml. You can also search for this file to find this directory

Screen shot of file tree If you have created icons that you want to be able from the panel editor, put them in a directory called "resources" in the Preferences directory. They'll then show up in the "files" part of the selection box when you press a "Change icon..." button on the panel editor.

For example, if the Preferences directory contains the files shown below, you'll get the file display shown at the right.

> ls resources/ decoderpro.gif green.gif icons red.gif tester.gif > ls resources/icons/ something tester.gif > ls resources/icons/something/ tester.gif

It's also possible to put your files in the resources directory within the JMRI distribution directory that you get when you install the program. This is not recommended, because files there will likely be overwritten when you install a future version (a newer version of a file, perhaps to fix a problem, will overwrite your copy; the replacement is based on the file's date). More information about the JMRI Configuration Files