Using Raspberry PI to control Märklin model railway – Part 2

At this point, the CAN interface has to be initialized manually after every reboot. Therefore, if the Pi is used as a permanent controller, it might be preferable to have these initialization steps been carried out during startup.

In order to achieve that, can2upd is going to be registered as a service and started right after the can0 interface has been initialized. Raspbian is using systemd as service manager, so this post will describe how to create systemd units for the tasks described above. Information about how systemd works and how to create unit configuration files can be found in the systemd(1) Linux manual page or in Justin Ellingwood’s excellent article on DigitalOcean .

The CAN interface initialization service

Create a new unit configuration file using sudo vim /lib/systemd/system/socketcan-interface.service with the following contents.

The can0 interface should be initialized as soon as networking is available, which should be the case on runlevel 3 that translates to multi-user.target for systemd. Since all commands used in this unit will exit after completion, the type has to be set to oneshot along with the RemainAfterExit= option set to yes. Multiple commands have to be separated with ;. Executing

will set permissions and enable the unit.

The can2udp service

After the can0 interface has been setup, can2udp has to be started. Since it is desirable to collect as much information as possible about the system’s state, can2udp will be run in foreground mode, allowing the verbose option to be activated. The output can be retrieved later using journalctl, see the troubleshooting section for more information. Create a new unit configuration file using sudo vim /lib/systemd/system/can2udp.service with the following contents.

Putting socketcan-interface.service in both the After= and Requires= section will make this service run after socketcan-interface.service has been started and will attempt to start it in case it’s not running. Executing

will set permissions and enable the unit.

Conclusion

After both systemd units have been created and enabled, the Raspberry PI has to be rebooted. From this point, whenever the PI starts, the can0 interface will be up and running with a proper baudrate and can2udp will be started waiting for incoming UDP connections on its default port.

Troubleshooting

An overview of all running systemd units can be found using sudo systemctl list-units. Both the socketcan-interface.service and the can2udp.service unit should be listed as loaded and active. Since the socketcan-interface is of type oneshot, it will be marked as exited while can2udp should be indicated as running.

Log output of the respective units can be viewed using sudo journalctl -u can2udp or sudo journalctl -u socketcan-interface. Linux will buffer the output written by can2udp and not write it to /var/log/ per line. Because of that, no output of can2udp might appear in the logs at first. Sending a few commands will cause the logging buffer to flush and the logs to appear in the journalctl output.

References

Using Raspberry PI to control Märklin model railway – Part 1

For my latest project, the Mariannenbahn, I needed to find a way to control a Märklin model railway from different rooms. While this is obviously possible using multiple Märklin Central or Mobile Stations, it was not an option at the time as the project already hit its budgetary ceiling.

This solution is intended as a temporary replacement for an additional Märklin control device and research was done out of curiosity. Go and buy their stuff.

Thanks to an outstanding blog post on http://www.ifoedit.com as well as Stefan Krauß’ homepage , a solid groundwork was already present.

Overview

The Märklin Digital Connector Box is a device containing a signal processor that generates the digital signal on the rails. It communicates with controllers, such as the Mobile Station , via CAN bus using a protocol defined and thankfully published by Märklin. It is therefore possible to use any device capable of transmitting data over CAN to control the model railway. Using a Raspberry PI together with a ready-made CAN extension module seemed like a good and safe solution, as various people already proved that this setup usually works.
Since it is usually common to use the Raspberry PI via SSH instead of a display connected, a piece of software taking commands via Ethernet and hand them over to the CAN bus is required. That way, it is possible to install the PI somewhere close to the Märklin Digital Connector Box and the railway layout. Connected to the LAN, it will take commands from any Ethernet-capable device such as personal computers or even smartphones. Gerhard Bertelsmann has written a wonderful C program called can2udp for exactly that purpose. It will hand over commands between Ethernet/UDP and the CAN bus.
As a final step, software to produce the actual commands to be transmitted to the Digital Connector Box is required. The most obvious solution available for this task is Rocrail.

CAN controller

After some research, I decided to get a PiCAN2 board form SK Pang Electronics . Getting it running is quite straightforward. On the downside, I found it inevitable to solder a 2-way header pin as jumper bridge to the board myself to be able to use the 120Ω terminator already present on the board.

Hardware installation

Activating the terminator resistance is described in the manual. Mounting the board is easy, it only fits one direction. It is possible to either use the DB9 Connector or the screw terminal on the PiCAN2 to connect it to the Märklin Connector Box. The pin assignment on the Märklin Connector Box is described by Stefan Krauß.

Software installation

I was using a Raspberry PI 2 running the latest Raspbian. I wasn’t able to get the PiCAN2 running with the latest (4.4.16) firmware though. I used rpi-update to go back to 4.1.21 which worked for me some time ago. I did not do any investigation on which exact version introduces the breaking changes. If you find out, please let me know. To install a working firmware, rpi-update can be used with the version’s commit hash:

Following the manual, the following three lines have to be appended to /boot/config.txt:

After a reboot, the CAN interface can be brought up.

See the troubleshooting section on information about how to verify the interface is up and running properly.

can2udp

can2udp is a beautiful C program that hands over messages from Ethernet/UDP to CAN and back. The usage is:

Given the default setup, it is sufficient to call ./can2udp -f -v, which will bring up can2udp in foreground with verbose output. It will send a certain initialization package to the Märklin Digital Connector Box on startup.

Client software

Almost any literature on the topic is using Rocrail as client software. Due to the lack of any real alternative, it is what I am using too at the moment.

I do not really like Rocrail. It was supposed to be open source software licensed under GNUv2 until the owner apparently stared spamming ®s all over http://www.rocrail.net and shutting down their public GitHub repository, even admonishing others to remove their forks of the GNUv2 licensed code. To make matters worse, an annoying pop up dialog tries to lure users into buying a support key.

The setup described in this post simulates the use of a Märklin Mobile Station 2, so the setup for Rocrail is identically to that scenario and can be found on their webpage or on http://www.ifoedit.com.

Where to buy

I was able to get a Märklin Digital Connector Box (60113) together with the required Märklin 36VA Switched Mode Power Pack (66361) from a local retailer. Märklin appears not to be selling the Digital Connector Box anymore, but still its quite easy to get one on eBay or Amazon.

Troubleshooting

If the CAN interface is set up correctly, it will be listed in the output of ifconfig as can0. Both the bcm2835 and the mcp251x controllers must be listed in the output of lsmod. Errors in the initialization process will also show up in the output of dmesg. It might be wise to grep for bcm2835 there.

References

Cloud-hosted continuous integration solutions 2015

For a new project at work, we needed to setup a continuous integration routine. As we don’t really have the capacity to host it on our own, I decided to make a brief market analysis of the available solutions in late 2015.

While my research was done with a certain project configuration in mind (a web platform running Node.js with Angular), I’m sure it can be useful for other types of projects as well.

Travis CI

Extremely popular as a lot of open-source projects hosted on Github use their free plan. The documentation is comprehensive and clean [1] plus there are tons of related posts on stackoverflow. I also found a dedicated section on browser testing. They even offer to run your script on Mac hardware [2] allowing to test on the most recent versions of Safari. The downside however is the price. Their plans start from 129$ excl. VAT per month for 2 concurrent build jobs. [3] Also, your sources must be hosted on GitHub as there is no support for any other type of repository.

Codeship

Codeship is definitely worth a look for small companies as they offer a free plan with 100 builds per month, as well as an unlimited personal plan for 49$ per month. However, this does not allow to reflect organizational hierarchies in terms of account management. The organizational plan is 99$ per month. [4] Codeship supports both Github and Bitbucket, however there is no way to use any other type of repository. [5] They also do not offer builds on Mac hardware. I skimmed over their documentation and it looked clearly arranged and pretty extensive. [6]

Circle CI

Circle CI offers the most generous free plan of all solutions. You get unlimited builds for one repository for free. Any additional container is 50$ [7]. Their documentation looks good with lots of real-world examples and technology-specific tutorials. I discovered a section on iOS builds on Mac hardware. [8] While this feature seems to be experimental at the moment, it might indicate that Circle CI is planning to offer Mac hardware for regular build jobs in the near future. As for SCM, only Github is supported. [9]

Jenkins CI on AWS

This section is hard to evaluate since I don’t have any experience how much resources Jenkins will actually use. However it is possible to answer a few obvious questions. You will have to spend a lot of time setting up and configuring Jenkins, even more so if you plan to use its EC2 features allowing it to scale by launching additional instances on demand. There is clearly no way to use Mac hardware and although there is no actual limit on build jobs, make sure you have set AWS billing alerts.

Conclusion

Since pricing policy differs from company to company, I decided to compare the first plans that offer unlimited builds on 2 concurrent jobs.

Price and feature comparison
Travis CI Codeship Circle CI Jenkins CI on EC2
Github yes yes yes yes
Bitbucket no yes no yes
Private SCM no no no yes
Mac Hardware yes no iOS no
Concurrent Jobs 2 1(2)* 2 ultd.
Ultd. Plans from 129$ 49$(99$**) 50$ ?
Setup easy easy easy hard
SSH Debugging no*** yes yes yes

* Only one concurrent job but 2 parallel test pipelines
** Organization plans including account management from 99$
*** Various blog posts indicate that they will launch a VM for you to debug your scripts

References

[1] http://docs.travis-ci.com
[2] http://docs.travis-ci.com/user/workers/os-x-infrastructure
[3] https://travis-ci.com/plans
[4] https://codeship.com/pricing
[5] https://codeship.com/documentation/faq/other-scm
[6] https://codeship.com/documentation
[7] https://codeship.com/pricing
[8] https://circleci.com/docs/ios
[9] https://circleci.com/docs/faq#do-you-support-bitbucket-or-gitlab-