First Steps in Computer Control

[KingEdwardII]

I controlled a train and switched some points on my layout from a computer for the first time yesterday. I know this is routine for many folk who post to these forums, but I still think it is a significant milestone for anyone building a model railway, since it is far from trivial to enable this.

 

I am still experimenting, but my goals are clear:

1. control the physical aspects of the layout from a large computer touch screen (points, signals, lights) instead of a physical control panel
2. provide (semi) automation so that I can run multiple trains simultaneously on the layout
3. control one or more trains from a wireless handheld

 

Currently I am using a Digikeijs DR5000 as the command station, LAN (Ethernet) connected, with DR4018 accessory decoders driving MTB MP1 point motors. The computer is a Raspberry Pi 400 with a 22inch Iiyama touch screen, connected either via Ethernet or via WiFi, although I can run the same software on my MacBookPro.

 

I am experimenting with both RocRail and JMRI. Mainly because they are a) free. b) support the computing platforms I use. (I don't have a Windows machine, although I do run Windows programs on my MacBook in VMs).

 

RocRail has enabled me to produce a control panel for the layout and control the points from the touch screen, driving the DR5000 via the Loconet protocol over the LAN. It is also able to provide on-screen windows for driving trains. I attach my current RocRail control panel - a first attempt and probably containing mistakes aplenty, but you have to start somewhere! The yellow marked rectangles show the status of each point and you simply click on the alternative rectangle for a given point to throw the point. With crossovers, a single click moves both points.

 

JMRI is harder work for creating the control panel, but I am an expert Java programmer and I suspect I shall use JMRI a lot more in the future simply because it is open source written in Java and so straightforward for me to tweak and extend as needed. 

 

I am interested to hear more of other folks' experiences in controlling their model railways from computers, especially with regard to the software and its configuration. I've read material about some of the commercial programs like iTrain, which certainly seem much more polished than RocRail and JMRI, but which have very healthy costs associated with them.

 

Yours,  Mike.

[RobinofLoxley]

I will be interested to see how it all goes as this is the route I am hoping to do down, but I am still in the early stages of layout building.

 

I get why with programming skills you would go the way you have. I will go for iTrain and consider it a small part of the overall cost. The forum will probably save me the cost in due course.

 

But please keep posting, a great milestone for you

[DY444]

I got fed up with other people's products not being able to do what I wanted so several years ago I started developing my own suite of software tools using C#/.net which has been evolved and refined over the years.  If I want a new feature then I just add it.  I see it as the control equivalent of scratch building and if you have the necessary skills and time then I thoroughly recommend it as an approach. 

[Ian Morgan]

Merg has a lot of members working with computer control, using RocRail, iTrain, JMRI and home brewed solutions. Could be worth joining to access the forums and knowledgebase there.

[KingEdwardII]

As well as RocRail, I have been working on a JMRI implementation for my layout - slower going as it turned out. Here is my first attempt at a Layout Panel, kind of equivalent to the RocRail control panel in my earlier posting:

Here, the circles represent turnouts of one kind or another - with Green representing turnouts in the "straight" position and Red representing turnouts in the "thrown" position.

 

JMRI differs from RocRail in a number of respects including:

• It models crossovers directly and covers my case where I have a single DCC turnout address for both point motors
• Clicking in the circles changes the related turnout position
• It does not model 3-way points at all, requiring you to use a pair of RH & LH points instead - this is disappointing simply because not all 4 combinations of point positions are allowed in practice and I shall have to use some form of. script to implement this limitation instead
• JMRI models both single slip and double slip diamond crossings. However, editing the on-screen icon is tricky and unreliable, hence the weird shape on my double slip in the bottom centre of the panel

In some respects, the schematic approach taken by RocRail is easier to get to grips with although the final diagram is more faithful to the layout in JMRI. JMRI also stores data about the "physical" turnouts separate from that of the representations in the panel. This leads to more work since you have to define things in two places. This separation may be better in the long run, but it makes starting a slower process.

[KingEdwardII]

4 hours ago, DY444 said:

I got fed up with other people's products not being able to do what I wanted ...

Yes, that is one reason why I am an enthusiast for open source software - the important thing is not that it is free, but that anyone has the ability to take the existing work and alter or extend as they see fit. And that their modifications are available to all in return.

 

I like the analogy you make to scratchbuilding - but expecting everything to be scratchbuilt is a hard demand on many modellers and many make the compromise to use RTR models, or to take RTR models and tweak them (weathering, cut-and-shut modifications, etc), or to kitbuild, again with modifications. I make the same analogy with software - it is often far too much to expect the average modeller to write all their own code. Some folks are happy with the RTR commercial software like iTrain, whereas those who are prepared to tinker can choose packages like JMRI knowing that they have a good foundation and where it does not meet their needs, they can extend or tweak as needed. Even good commercial software is wise to provide extension points that allow purchasers to add or modify functionality - this was the foundation for success for spreadsheets, for example, with their macro and scripting languages.

 

RocRail unfortunately falls down a crack here - not fully commercial but not open source and so not providing the natural approach of tweak and extend available to open source projects. This rears its head painfully in the RocRail documentation which is lamentable at best.

[KingEdwardII]

47 minutes ago, Ian Morgan said:

Merg ... Could be worth joining to access the forums and knowledgebase there.

Ian,

 

Yes, I am contemplating joining MERG. However, getting my head around RocRail, JMRI and the potential of iTrain is keeping me busy for the present. Plus building all the other aspects of my layout, of course 

 

Yours,  Mike.

[BoD]

I use and like Rocrail because it does all of the things I need it to... and it’s free, although you can donate if you want to.  Indeed there are some features unavailable if you don’t.  I don’t need those so it’s not an issue. Computer control was not something that was essential but was something I wanted to try and  enjoyed getting to grips with.
 

As I said though, I’m more than happy with it because it allows me to operate in ‘manual’ mode only, using the computer to operate turnouts and signals, or various automatic modes where I can just sit with a coffee and watch trains passing by.  I also use it to operate the main route whilst I shunt away.

 

I’m sure that all of the other software does this too, some better than rocrail and there are many features that I don’t use or need.  When I first started investigating computer control I downloaded rocrail to experiment with and have just stuck with it ever since.  
 

I agree with you that the documentation is somewhat lacking but I found that more in the structure of it than the actual content.

[Nigelcliffe]

2 hours ago, KingEdwardII said:

As well as RocRail, I have been working on a JMRI implementation for my layout - slower going as it turned out. Here is my first attempt at a Layout Panel, kind of equivalent to the RocRail control panel in my earlier posting:

Here, the circles represent turnouts of one kind or another - with Green representing turnouts in the "straight" position and Red representing turnouts in the "thrown" position.

 

JMRI differs from RocRail in a number of respects including:

• It models crossovers directly and covers my case where I have a single DCC turnout address for both point motors
• Clicking in the circles changes the related turnout position
• It does not model 3-way points at all, requiring you to use a pair of RH & LH points instead - this is disappointing simply because not all 4 combinations of point positions are allowed in practice and I shall have to use some form of. script to implement this limitation instead
• JMRI models both single slip and double slip diamond crossings. However, editing the on-screen icon is tricky and unreliable, hence the weird shape on my double slip in the bottom centre of the panel

In some respects, the schematic approach taken by RocRail is easier to get to grips with although the final diagram is more faithful to the layout in JMRI. JMRI also stores data about the "physical" turnouts separate from that of the representations in the panel. This leads to more work since you have to define things in two places. This separation may be better in the long run, but it makes starting a slower process.

 

 

Whilst you're free to use JMRI in any way you wish,  I'll point out a few things...

 

The Layout Editor (which produced the drawing above) is for constructing a logical description of the track and signals.   If you push the layout editor further, you can set blocks, and place signals at the end of blocks, and have JMRI work out the rules (turnout positions and track occupancy) to determine the signal aspects.   

But, as a logical description, the visual appearance options are limited.   There is some scope to change the appearance, but it doesn't offer everything. 

 

Another way to produce a panel is the "Panel Editor".   That's gives you any graphical representation (draw your own icons to represent things, if the supplied icon libraries don't suit).  It can include a background (static graphic layer).   Track can indicate multiple things if transparent icons are carefully drawn (eg. lower layer might indicate occupancy by having either "transparent" or "broad red" line,  and a layer above the occupancy icons can indicate turnout direction with a transparent background and black for the track).    Another layer might indicate routes which have been set, or signal aspects.  Some elements can be "clickable" (eg. change a turnout), whereas others are only displaying information and don't respond to clicks.  
You can have multiple panels, and they can overlap in functionality.  So, specific panels for areas of the layout, or designed to display on phone screens, can be built.  

 

 

If the rules for operating the layout are described in the Layout Editor, then any Panels created in the Panel Editor will obey those rules, and change accordingly.   So, an approach is to do all the rules/logic in the Layout Editor,  and then the graphical creation of what you want to see in the Panel Editor.   When running the layout, use the Panel Editor panels, not the Layout Editor.  

 

 

- Nigel   
(years ago,  I co-wrote a set of tutorials for panels in JMRI, still mostly valid, though a number of elements have been improved over the years.  Its referenced on the JMRI website.  ). 

 

 

[KingEdwardII]

Nigel,

 

Thanks for your comments about JMRI.

 

I have not yet got my head around the Panel Editor, although it may be more suitable for some of my purposes. However, the Panel Editor definitely has a steeper learning curve which is why I started with the Layout Editor.

 

My initial goal is to have an on-screen system for controlling turnouts, followed by the idea of having a set of routes that can be selected and which will enable the setting of a group of turnouts in one go. Having fully powered all my turnouts, I rapidly found that handheld controllers are not a great way of operating turnouts and that some form of touchscreen operation is likely to be far better. The idea of an old-style physical control panel with buttons/switches/lights does not appeal and neither am I hankering after reproducing the look and feel of a signalbox lever frame.

 

I'll seek out your tutorials and hope to learn a lot more about JMRI Panels.

 

Yours, Mike.

 

PS Any idea why JMRI does not implement 3-way turnouts as a first-class concept? This seemed odd to me given that JMRI has support for crossovers as a concept. I only have one 3-way on my layout, but it looks as if I'll have to write a script of some kind to control the two point motors involved.

[KingEdwardII]

One thing I discovered about DR5000 LAN (Ethernet) support in RocRail & JMRI is that these two control software packages have different default configurations of the DR5000 and as a result, it is not possible to use them together, nor to flip between them on the computer.

 

For some reason, RocRail requires the DR5000 LocoNet to be configured as 'LocoNet over TCP/IP Binary" while JMRI requires the DR5000 configured to use "LocoNet over TCP/IP LBServer". These are not compatible and switching between them implies reconfiguring the DR5000 - a real pain.

 

So far, I have got both RocRail and JMRI to work with my DR5000 over Ethernet, but only at the cost of reconfiguring the DR5000. I'm not happy with this and I'm puzzled as to why the configuration needs to be different. 

 

I found this page in the RocRail documentation relating to LocoNet:

 

https://wiki.rocrail.net/doku.php?id=lbserver-en

 

This implies that RocRail can support the "LocoNet over TCP/IP LBServer" configuration on the command station - ironically, that page seems to imply that the command station involved in the configuration shown in the menu is actually a DR5000! So, I shall give this alternative configuration of RocRail a trial and see if it works - if it works, then I shall use it going forward. Note also that this page implies that the LBServer configuration is supposed to be capable of handling multiple clients across the network - desirable from my perspective.

 

One thing I want is to have the main control of the layout from my Raspberry Pi400, which is permanently in the railway room, but to do development work on new versions of panels, etc, from my MacBook Pro which moves around with me. This will be much easier if I can run the control software on both at the same time...

[Nigelcliffe]

10 hours ago, KingEdwardII said:

Nigel,

 

Thanks for your comments about JMRI.

 

I have not yet got my head around the Panel Editor, although it may be more suitable for some of my purposes. However, the Panel Editor definitely has a steeper learning curve which is why I started with the Layout Editor.

 

.........

 

PS Any idea why JMRI does not implement 3-way turnouts as a first-class concept? This seemed odd to me given that JMRI has support for crossovers as a concept. I only have one 3-way on my layout, but it looks as if I'll have to write a script of some kind to control the two point motors involved.

 

I can't say why there isn't a 3-way, you could ask on the JMRI-Users mailing list on Groups.IO.   But many 3-ways don't have the mechanical constraints that you describe, so a pair of turnouts achieves the correct operation.   
The "rules" you'd need are not overly difficult.  If the turnouts are not clickable, then they can then be controlled by something else that you place on the interface.  That something else might be three "internal sensors" (one per path through the three-way) that can trigger a sequence of actions, the sequence would ensure that the turnouts move in the correct order, and that other two sensors are cleared. 

 

If you want to discuss Panel Editor, happy to have a short chat with you on Zoom (etc.) sharing a screen to get you going.  Its not hard, but need to get a few things straight in thinking first.   

 

 

- Nigel

 

 

 

[KingEdwardII]

OK, I finally got round to checking whether RocRail can connect to the DR5000 using the "LocoNet over TCP/IP LBServer" configuration as is used by JMRI. The answer is a resounding YES.

 

So count me one happy camper - it is possible use both RocRail and JMRI on the connected computers without needing to mess with the configuration of the DR5000 system.

 

I can further confirm that it is possible to run both RocRail and JMRI simultaneously connected to a single DR5000 using this configuration. It is possible to change a turnout using a RocRail panel and see the result reflected on the JMRI panel and vice-versa. Clearly, it is LocoNet response messages from the DR5000 that are being used to drive the changes in the panels, which is as it should be.

 

I have not yet tried out my goal of running the software simultaneously on multiple computers, but I have every expectation that this is going to work.

 

Mike.

Edited January 19, 2021 by KingEdwardII

[KingEdwardII]

20 hours ago, Nigelcliffe said:

If you want to discuss Panel Editor, happy to have a short chat with you on Zoom (etc.)

Nigel,

 

That is very generous of you. I am not quite ready yet to delve into the JMRI Panel Editor as there are a few other things I need to get done before I spend time on that. I hope that I shall be able to call on your assistance at a later date.

 

Many thanks,  Mike.

[KingEdwardII]

So I confirmed that it is possible to use both RocRail and JMRI on multiple computers simultaneously and to intermix using them both on any machine.

 

The panels of all instances of both programs update whenever a turnout is switched using just one of the instances, for example.

 

I am also pleased with the investment in the Iiyama touch screen attached to the Pi400 - I can change a turnout simply by pointing at the appropriate location on the screen. The longer term goal is to operate the layout just using the screen with no need for either the keyboard or the mouse. I note that the touchscreen is by far the most expensive item associated with the Pi400, which is otherwise a very cost effective way of getting computer control. At 22inches, it is perhaps comparable in size with conventional control panels, with the advantage of being flexible and reconfigurable.

 

One other thing to note is that the Pi400 actually supports 2 HDMI monitors so that I could envisage separate monitors for different parts of the layout - perhaps one for the main through station and another for the branch terminus.

 

I have the DR5000 controller connected to the house router via a wired Ethernet connection - this is required since the DR5000 WiFi is not configured to connect to a WiFi router. However, both the Pi400 and the MacBook are connected over 5MHz WiFi - which is great since it means that the computers are not constrained by Ethernet cables and can be placed anywhere convenient. 

 

The next stage is to investigate operating trains from a handheld - I have installed a couple of apps onto my smartphone and I'll try out a couple of alternative options - one with the app talking directly to the DR5000 via its WiFi, the other with the app talking to JMRI on the Pi400. I know that it is not possible to do these at the same time with one smartphone, since the DR5000 WiFi is completely separate from the house WiFi system and it is necessary to manually switch the phone between the two.

 

Mike.

[KingEdwardII]

So, moving from turnouts to trains - time to control locos via computer!

 

First, JMRI offers on-screen throttle windows. Each window can control 1 loco and it is possible to have multiple locos each controlled via a separate window:

The number of Function keys can be adjusted as needed. Forward/reverse and speed is controlled in the pane on the left. Simple and straightforward, but tied to the computer screen.

 

JMRI also provides a WiThrottle server which supports handheld devices as throttles. I am using an Android smartphone (Samsung Galaxy Note) and choose Engine Driver as a throttle app to run there. Engine Driver searches for WiThrottle servers automatically (I have 2 - one on Pi400, one on MacBook):

Connect to one server and select a loco:

Drive!

So - I can now control the layout (turnouts etc) and drive trains via computer - using wireless handheld to control the locos for maximum freedom. 

 

 

[Nigelcliffe]

I assume you've found that on most phones, with EngineDriver, the volume key is the speed control ?  

 

(Doesn't work on Apple phones because Apple prevent software writers using the volume key for anything other than volume). 

 

The function labels, and the latching nature of each function for each loco, on both the computer throttle and the phone throttle can be customised.  They are set in the roster-entries for the locos stored in JMRI.    My earlier point about panel development really comes into its own with control via phones.  

 

 

- Nigel

[KingEdwardII]

Nigel,

 

Thanks for the tip about the volume control for speed. I am still experimenting with speed - the default is for increments of 4, which is OK for 6023, but is actually too large for 7224 2-8-2T which has wonderfully low gearing.

 

As for Function keys - at present they are of no use to me. I have fitted decoders with plenty of functions available, but at the moment they are not used for anything - another "todo" for the future. I don't have sound fitted at all. I noted the capability to set up the F keys in the roster - a tool for the future, I think.

 

Mike.

[Nigelcliffe]

27 minutes ago, KingEdwardII said:

Nigel,

 

Thanks for the tip about the volume control for speed. I am still experimenting with speed - the default is for increments of 4, which is OK for 6023, but is actually too large for 7224 2-8-2T which has wonderfully low gearing.

 

 

Mike, 
its experimenting time - there are loads of ways to approach this:  
One is to leave the speed increments as you have them, and alter 7224 by programming its "speed table" (probably the 28 step form), and using that to alter how it responds to speed instructions.  

 

If you want to try a really small portable speed/direction control, then EngineDriver allows you to connect various small bluetooth game controllers, and set use those for loco control. 

 

 

- Nigel

 

[jamespetts]

I should be interested to know how you get on with this. I looked into JMRI for full automation a few years ago, but decided to go with TrainController in the end because JMRI does not have the built-in abstractions necessary for automation without a lot of work writing scripts (e.g., the concept of a schedule). One would effectively have to write from scratch a very substantial piece of software in a scripting language to get serious, complex automation in which data are separated from code so that one does not need to undertake substantial programming work to change a timetable on a layout, and this may well be more than is workable without fragility in a scripting language (I think that someone tried something like this a few years ago, but JMRI updates broke the script).

 

If you are an expert Java programmer, you might be able to add the necessary abstraction features directly into JMRI, which would be a happy thing for everyone.

[Ian Morgan]

Whilst you are still in trialing and experimentation mode, you should also try the DigiTrains App for Android phones, which also connects to the JMRI WiThrottle Server. Some of the more advanced features are pay-for, but the free version still offers a lot.

 

Myself, I have not decided which is better, DigiTrains or EngineDriver, but they are both free and both live on my phone.

 

 

 

 

[dave750t]

26 minutes ago, Ian Morgan said:

you should also try the DigiTrains App for Android phones, which also connects to the JMRI WiThrottle Server.

 

 

 

Digitrains actually contacts via the JMRI webserver rather than Withrottle. Similar but different. See https://www.jmri.org/help/en/package/jmri/jmrit/withrottle/UserInterface.shtml

[KingEdwardII]

On 31/01/2021 at 22:42, Ian Morgan said:

...you should also try the DigiTrains App for Android phones...

Ian,

 

Yes, I had a look at DigiTrains app and then came across this on its blog pages:

 

"Over the past year, the DigiTrains application has been completely rewritten. The new App's name is DigiTrainsPro."

 

So, the old DigiTrains app is no longer supported, which makes me less keen.

 

Moving on to the DigiTrainsPro app and its website here:

 

https://digitrainspro.hu/

 

I read the following:

 

"From the 1st of May, 2020., the use of the full functionality of the application will only be possible with a Premium subscription."

 

Following up on that subscription, it turns out that the cost is €15 for every 3 months.

 

I'm not against paying for software, but €60 per year for something where there is a good free alternative does not appeal to me. Especially in the case where the hard work is being done by JMRI.

 

With Engine Driver, the configuration of the layout, the description of the locos, etc, is all entered into JMRI. Engine Driver piggybacks on that, which I like since it means a single source of truth about the layout and only 1 place to go change things as needed.

 

Yours, Mike

[KingEdwardII]

James,

 

Thanks for your observations on full automation and JMRI. I shall investigate JMRI for automation over time. I'm still finishing off turnout control at the moment and signal control will be next up

 

My interest at the moment is more in partial automation, rather than operating a full automated timetable.  Such as the ability to select and execute a particular route for a given train. However, I certainly won't shrink from hacking together whatever Java code might be necessary to provide some features that I feel the need for.

 

One item already on my agenda relates to the editing capabilities of the JMRI Layout Panel tool - the lack of an "undo" capability there fails the UI 101 test for me.

 

Yours,  Mike.

[jamespetts]

I should anticipate that JMRI is much more suited to the sort of partial automation to which you refer; if you are not asking JMRI to handle timetables, then one of its major weaknesses in full automation is irrelevant.