Thoughts October 2014

My layout shall be PC controlled. That gives me the following options:
– Writing the software myself
– Buying commercial software
– Using software

If I am writing it all from scratch, I will have full control about all details. But the price will be that it will take several years before I know enough details about all protocols, such as the Uhlenbrock PC interface, DCC and Loconet and before I have utilized such knowledge to actually write the software for both implementing these communication protocols as well as the application code to visualize my layout and the control code to actually run trains., switches etc.

By buying commercial software, I would expect to get going very fast. And I would expect easy-to-use and well-working software. The down-side would be that there will be no chances to write additional modules myself and not even to tweak the existing functionality. Even the smallest bug in the program would be impossible. Do anything about. And it would make me even poorer than I am already. I have heard about a program called RR&Co. It costs between 100 and 500 Euro depending on version. And Windigipet seems to be another serious candidate.

Free software (Open Source Software, OSS) seems to be the way to go for me. There seems to be two serious candidates: JMRI that I have already been looking at and RocRail that I have also installed on my PC and has seen “hole through” in.

JMRI seems to be a big library of basic software (programmed in Java) with interface to a lot of different command-stations, a lot of decoder definitions, some decoder programming capabilities, built-in scripting capabilities as well as some more or less unfinished applications for layout visualization, automatic dispatching of trains etc.

There is also a thing as interesting as a sound generator for locomotive sounds, so that locomotives without their own sound decoder can ge sounds anyway.

JMRI has a free throttle app for Android. The iPad version has a free light edition, whereas the full version costs 65 DKK. I cannot see what the big difference between the two versions is, but I suspect I am going to find out, if I start using the light edition.

The big downside to JMRI seems to be that the IB-COM interface doesn’t seem to work. I have had to patch it to make feedback as well as switch control working.

And DCC decoder programming is not working at all via IB-COM. It isn’t even implemented. And that seems odd, since decoder programming is supposed to be one of the things that JMRI is really good at. How things are with Loconet programming is until further unknown to me. But there is supposed to be a LocoIO programmer in JMRI. I will have to deal with the rest using Uhlenbrocks somewhat basic software.

JMRI Is written in Java. That is in principle a good choice ensuring that it runs on many operating systems. (Windows, Linux etc.). It does hoever not make anything faster – especially not start-up of the software. And it means a lot of layers of library code, before getting down to the hardware, such as PC sound, USB ports, harddisk etc.

RocRail seems to be more of an effort to make a true competitor to the commercial model railroad control software products. It is being critisized for not supporting very many decoder types. I am assuming that is only while programming decoders. RocRail should however be better at LocoIO programming than JMRI.

RocRail also has apps for Android and IOS. The one for iPad costs 69 DKK, and there is no free version. The Android version is free, but will only run for 5 minutes, unless you donate a sum and obtain a key. So does that really mean free??

In addition, there seems to have been a WEB interface at some point in time. And there seems to be a Java version that is limited the same way as the Android app.

RocRail is written in C/C++. That makes things a bit simpler regarding direct access to operating systems and hardware. It has however been done in a ways so that RocRail is compiled for several operating systems. So in practice this does not make a big difference compared to JMRI.

RocRail consists of two different parts: A server (RocRail) and a client (RocView). The two parts does not need to run on the same PC. And several clients can connect simultaneously to the same server.

Until now, I have been trying JMRI. But it hasn’t been just a walk in the park to make it work. I thing my next experiments will be with RocRail.

That means goodbye to the virtual sound decoder. But if the rest works more stabile, I will just have to buy a sound decoder and let it change sounds and address according to which locomotive I am going to use it with.

Addition December 2014:

The first experiments with RocRail seemed to indicate that RocRail was easier to use than JMRI. IT is much more a finished program for the normal user that just wants to run trains.

In addition, there is a very active contributor, who seems to be very decisive (good and bad) and in control about which improvements are approved and which are not. There seems to be several improvements every day.

And at a first glance, the program is well-working.

My experiments with Automode are however not with 100% success.

I have to use equal amounts of patience and magic to make the locomotives stop at the same spot each time and to synchronize sounds (announcements etc.) with departing trains.

But even worse, the random-auto function that is built into the program does not work. I will not use any valuable locomotive with this function untill I see more stability. I am experiencing these problems:

1. Sometimes the locomotive doesn’t move, even though one can see in the throttle window that RocRail seems to thing that it has sent a command to the locomotive to run at march speed. There are two ways to actually get the locomotive moving: Either press some random function for the locomotive, such as turning on or offe light or by simply waiting several minutes. After some ime, RocRail seems to re-send the command to the locomotive.

2. Someimes the program goes bezerk and forgets to stop the locomotive. And then it is very difficult to get things working again. It does not help to restart RocRail. One has to select “soft reset” and “reset all” in some combination that I have not fully determined. And then RocRail has totally lost any knowledge about which locomotive that is in which block.

3. If a reset is unsuccessfull (or is this caused by something different??), trains will not stop in the block they are supposed to. And then when the locomotive goes beyond the block, everything again goes bezerk.

4. Decoder programming works. But one is not being informed about read or write errors. And that is dangerous. It means that one can not trust the information or the programming itself.

Besides, RocRail cannot track locomotives that you drive manually. It might be because I have misunderstood something, but is seems to be “works as defined”.

Naturally, commercial software should not be disregarded all together. It is probably more stable and easier to use. And it may not be that expensive. I know of these programs so far:
– Win-Digipet
– iTrain
– Train Controller http://www.gotthardmodell.ch/digitales/software/traincontroller/
– Railware

I may be testing trial versions of these products at some point. But so far, I have not yet given up on RocRail.

I suppose that I could get help on the RocRail forum. But then I would probably have to register and pay €10 per year. See http://wiki.rocrail.net/doku.php?id=donate-en&DokuWiki=4ad465ee2e5ec1e3b662d9a9c6abf18f

That price is not much compared to the commercial programs. The price of those is easily €300. And updates is additional cost. So that means RocRail including daily updates for an eternity for the same price. But nevertheless, if I am going to pay anyway, the commercial programs are probably better.

Next thing must be to “adjust” the multitude of configuration possibilities in RocRail. I have already downloadet the source code and got a development environment up and running. (Which by the way had to be done in a different way than the totally outdated description in the RocRail homepage indicated). So I can manage things myself. But it is not what I want. I would rather be driving trains.

Besides, I only have one sensor per block, i.e. An occupancy sensor in terms of a current sensor that senses the entire block. It ought to work, even though it seems that at least two or (for Win-Digipet) three sensors per block seems to be recommended.

After more thinking, a little Youtube investigations after “JMRI automation” and “JMRI scripting”, as well as a visit to this page http://www.kayhernan.com/jmri-scripts/sensor-shuttle/ I have reached the following conclusions:

1. Commercial software is for the user who just wants to play trains. I assume they all work stable and keep their promises. That is (generally) that one would define ones layout and rolling stock and then the program would either run the trains automatically or let one self run them manually.

There are different variants of automation. Either trains are just running randomly on the layout, or one defines routes for each train – maybe even a schedule. The software will in any event make sure that trains do not collide, since the program will never drive a train into an occupied block.

2. Rocrail tries to do the same. However, my experience tells me that it is not stabile or at least very hard to configure.

In addition, I do not trust 100% that it is really an open source project. IT is way too much dominated by one single person. No matter how much this one person can be admired for his contribution, he decides too much – both regarding functionality and regarding which faults shall be corrected and which not. Finally, there is an example on the forum, where the iPad throttle is the centre for an argument between this person and some user. That argument ends with the source code for the iPad throttle being hidden and thereby no longer open source. When will the same thing happen with the entire RocRail program?

Another issue is that the very same person has decided that there is no longer any stable versions / releases, i.e. Versions that have been tested and errors corrected. Instead there are new versions each day with additions and error corrections.

Anybody with the slightest knowledge about software development knows that with each change in a program, there is a risk of introducing errors. And that is happening in RocRail as well.

I am not claiming that RocRail is especially error-prone. But I do see in the forum that the instability I experience is also experienced by others. And in those posings on the forum, the typical pattern is that this or that used to work, but after a particular update has ceased to do so.

3. JMRI is a totally different beast. It is basically a library of code that one can use to build software for ones own layout. And it seems that Jython, i.e. The Java implementation of Python is the way to do so.

I don’t know Python. But I do know that it is an obect-oriented programming language, i.e. a real programming language. It seems safe for a programmer such as myself, but may seem scaring to many others.

I think that JMRI is real open source, i.e. controlled by a community and not a single person. Stable releases exists. On the other hand, the IB-COM interface does not work optimally. But I am pretty sure that I can debug my way through that problem and thus contribute to the community.

4. Based on 1 – 3 there seems to be one unlogic and two logic choices for me:

RocRail is not logic, since I may only save 2500 DKK compared to buying a commercial program.

Whether a commercial program or JMRI is the best choice must depend upon what one wants. Just put in the plug and watch ones trains driving or programming ones own schedyles in Python?

Right now, I am in doubt. A year ago, I would have said JMRI and Python.

The way towards JMRI could be:
1. To really understand Logix and make it control signals.
2. Find or make a Jython program to measure speed through a block.
3. Find or make a Jython program (unless Logix is already capable of doing this) to keep track of all trains locations – no matter if they are being moved manually or if they are running automatically.
4. Find or make a Jython program that can run trains via a schedule.
5. DCC programming via IB-COM. Rocrail can do it. So by looking at the RocRail code or via simple traces, it must be possible to implement in JMRI too.

Update December 22, 2014:

I have just postet a patch to JMRI. Now JMRI can be used for decoder programming via IB-COM. And it works better than RocRail, since the error-handling in JMRI is way better than that in RocRail. With JMRI one can trust that all values are read from the decoder, if JMRI says so.

And now that I have had a deep look into the the JMRI interface to Uhlenbrock IB-COM, I am confident that I will be able to solve other problems that I may find in that interface. And the more general parts of JMRI probably works better. There are many users that probably uses other types of command-stations, but who all uses the general parts of JMRI.

I have experienced very good response on the Yahoo user group. There are plenty of postings every day, and when I had a problem with comiling the Java code, I got help from several parties within a couple of hours.

Besides, time has shown that you don’t need to program anything to get your trains to run automatically – apart from the errors that I have already corrected for all IB-COM og (see later) ECOS users.

So from now on, it is JMRI. And if at some point in time, I am making a different descision, it is going to be commercial software. I don’t want to waste more time on RocRail.