for those that have more sophisticated layouts (a la LCC, C/MRI) where sensors and controllers are accessed over communication buses, the glass panel may be a feasible alternative to conventional control panels using switches and LEDs.
in aviation, the glass cockpit refers to the use of computer screens instead of dials, gauges and switches. They allow different information to be displayed depending on flight mode and new information after upgrades.
a central processor (e.g. PC, Raspberry PI) connected both to the layout bus (e.g. RS-485) and having a WIFI connection, can provide graphical display information to as many glass panels as desired.
While a screen may be small, colorized routes can make it easier to see if track is unoccupied (black), occupied (red) and which routes established by turnout positions and clear (green).
a zoom feature can be used to completely display a section or show a specific turnout and change its position. Assume a route thru an interlock can be selected.
A glass panel eliminates the need to build the panel -- no panel, artwork, switches, LEDs, and its cost may be justified in the savings of panel components. It can easily handle changes to the layout.
while tablets may be too expensive ($60+ Amazon Fire), smart phones are more reasonable (~$20) although smaller.
obviously a glass panel is not for everyone and may not be appropriate in some locations (e.g yards) on a layout.
i believe software for glass panels can become readily available and easy to install and configure even for less techy model railroaders.
By eliminating the need to build and wire panels, the layout may become operational sooner as more time is available for trackwork, structures and scenery.
greg - Philadelphia & Reading / Reading
AN interesting idea, putting model railroads effectively ahead of the protoype. I have no doubt the current style dispatcher applications used by the real railroad will eventually transition into something more resembling the dynamic glass panel.
There was an article not too long ago (maybe it was in the other mag) where instead of control panels, the layout owner was using small touch screens in somewhat this manner.
There's a sort of think like this that Hans Tanner has been workign on using the smart pixl LED strips. It's all very much DIY at this point but once someone crafts the firmware it wouldn't be a leap to package it witht he hardware so it all just plugs together and the user just has to enter sme simple questions. He's shown it used as both control panels and actual signals on the layout. His efforts have been so far directed at making the devices Loconet compatible, but there's no real reason the Loconet library in the microcontroller couldn't be replaced with an LCC library.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
rrinker AN interesting idea, putting model railroads effectively ahead of the protoype.
The Pacific Southern Railway shares dispatcher screens with several laptops. Giving those laptops control of turnouts and signals was unintended and had to be defeated.
Can't you already do this with a browser on a tablet and JMRI?
I have the right to remain silent. By posting here I have given up that right and accept that anything I say can and will be used as evidence to critique me.
carl425 Can't you already do this with a browser on a tablet and JMRI?
Yup, this is old news.
I've been doing it for several years now with JMRI and a couple Android tablets and a Win10 tablet placed at various locations around the layout. And I certainly wasn't the first!
JMRI runs on the desktop machine at my dispatcher's desk and serves up the virtual, local control panels that have been built and sized to fit each of the tablets.
One of the JMRI developers has even pre-packaged JMRI on a RaspberryPi image you can just copy to your SD card and be up and running:
https://mstevetodd.com/jmri-raspberrypi-access-point
I could move my installation to an RPi or the Win10 tablet, but I'd need something to display the dispatcher's panels anyway, so for me moving it doesn't make sense
But lots of folks are goung the RPi route, though, as various aspects of it are discussed on the JMRI list quite often.
EDIT: Forgot to make the link clickable!
using something like VNC, you can share a screen and allow control from multiple screens. Is that how JMRI works, or does have JMRI have separate screens for different sections of the layout?
gregc using something like VNC, you can share a screen and allow control from multiple screens. Is that how JMRI works, or does have JMRI have separate screens for different sections of the layout?
You don't need VNC, because JMRI has a built-in Web server. You can access (AFAIK) just about all of it's functionality from a browser.
In my case, I have main dispatcher panels that are (normally) displayed on the host computer, and some local control panels that are displayed via browser on tablets located at strategic locations around the layout.
http://jmri.org/help/en/html/web/index.shtml
thanks for explaining. using a web browser is an interesting approach. i wonder how the graphics is maintained, i'm not familiar with JMRI
There's a guy near me who for many op sessions has a dispatcher using JMRI in another state. Skype to talk to the crews (linked to the radios the crews use), and accesses the JMRI panel remotely over the internet to line routes and monitor occupancy. And if that wasn't enough, it's a mixed layout, NCE for control, and a standalone Loconet for the detection and signalling part.
You can also, at least with Loconet, possibly with other protocols, have multiple computers with JMRI connected all to the same layout, each one running a specific part.
rrinker You can also, at least with Loconet, possibly with other protocols, have multiple computers with JMRI connected all to the same layout, each one running a specific part.
With LocoNet, there are are actually three ways to accomplish this using JMRI.
One is simply to have a separate instance of JMRI and a separate LocoNet interface device (PR3/PR4, LocoBuffer, etc) on each computer.
The second is connect your JMRI instances using it's in-built LocoNet Client/Server ability, and the third is to connect your JMRI instances to the LocoNet via the LocoNetOverTCP LBServer.
In most cases, though, that's probably overkill. For local panels distributed around the layout, and even for the remote dispatching Randy mentions, using JMRI's Web Server to serve up the panels is all you really need.