Development Blog

Posted on

Managing Locos

To control locomotives on the layout they need to be added to the system, this is performed in the engine shed section.

To add a locomotive you should go to the engine shed page and click the “Add Loco” button, on clicking this button two fields will be displayed “Loco Number” and “Loco Name”.  The “Loco Number” is required the “Loco Name” is optional once filled in click the save button.  The loco will be added to the roster.

Entering Details for new Locomotive
New locomotive to the roster.

Once the new loco has been added to the roster it can be linked with a decoder by clicking the “configure” button and select the decoder and then click the “assign” button.

Assigning the decoder by selecting from the dropdown.

The locomotive can now be controlled using the “Drive” button on the left of the locomotive.

The locomotives name and number can be modified by clicking the “edit” button this shows the same section as used to add a new locomotive, update the values and click save to update.

Posted on

Settings

System Setup

Selecting the menu option brings up the settings page.  This page is used for configuring the system.

There are two system settings currently DCC System and Serial Port.

Screenshot of the system settings
System Settings

 

The DCC System is a drop down list of the DCC systems that are supported by this application (At time of writing this is currently only the NCE System and a Demo System.)  The default for this setting is a Demo System that is used for mimicking a real DCC System for demo purposes.

The Serial Port is used for setting the serial port that the application will use to communicate with the DCC System.  The default for this is /dev/ttyUSB0 for a windows installation this should be changed to COM1 etc depending on which port the DCC System is connected too.

Along with the system settings build information can also be found on this page.  This shows various bits of information about when the application currently running was built.

Screenshot of build information
Build Information
Posted on

Installation

System Requirements

DCC Web Application will run on the following systems Windows and Linux (Will also probably run on Macs too but this has not been confirmed.)

The current version requires Java 1.8 installed and the RXTX (Currently tested with 2.2pre2 version) libraries.

For the latest version of java from Java.com

Installing RXTX using instructions from RXTX Web Site

Linux Installation

The RxTx libraries should be installed this can be done simply on debian systems using the following command:

sudo apt-get install librxtx-java

Download the tar.gz file from here.

Untarring the tar.gz file will create the directory dccweb directory.

Within the new dccweb directory is a jar file this can be executed by using the following.

./dcc-webapp-VERSION.jar

or

java -jar dcc-webapp-VERSION.jar

Once started the application will create a default empty database and initialize log file directory.

The jar can also be set to run as a service by using the following command

sudo ln -s INSTALL_DIR/dcc-web/dcc-webapp-VERSION.jar /etc/init.d/dccweb

Windows Installation

Download the zip file from here.

Unzipping this file will create a dccweb directory.

Within the dccweb directory is the dcc-webapp-VERSION.jar file this can be executed by double clicking or by running using a command line.

java -jar dcc-webapp-VERSION.jar

On running the application will initialize itself by create a database and log directory.

Configuration

The dcc web application can be configured by editing the configuration config/application.properties

The http port used can be configured by editing server.port the default is port 8080.

The other settings control the database settings and should be left at the default settings.

The web application can be connected to using any browser using the ip address of the machine the service is running on and the port number configured in server.port.

For example to connect to the service running on the local machine can be connected to using the following url http://127.0.0.1:8080

 

Posted on

NCE Controller interface

As the NCE Controller interfaces via a serial device the RXTX library was used to create the connection.  This requires the binary runtimes to be installed this is quite a simple process on debian based operating systems like that of raspbian on the raspberry pi.  This is simply installed via the apt command as follows:

sudo apt-get install librxtx-java

The NCE interface is then created by creating an NCE message processor this processes the internal message types into NCE implementation runner versions of them, the NCE implementation when run converts the internal data to a packet of data to be sent across the serial interface to the NCE controller.  Once the NCE controller has processed the data packet sent it returns data back across the serial interface.  The NCE implementation then converts the NCE data back to an internal format and returns this back to the core services.

Further interfaces to controllers can be created in a similar fashion simply by adding a message processor implementation for the controller and then creating the controller specific message types to convert the internal types to send the data to the controller.

Posted on

Interfacing with controllers

The interface to the controllers is based on sending a message to be processed by a message processor of the controller type.

The messages passed to the message processor contain only the information in order to complete an action.  This information is in an internal data format.  Each message processor then processes the information into packets of data to be sent to the controller over the interface device of the controller.

If there is any data to be sent back from the controller the data is read by the processor, processed and returned in an internal format.

Using this process the implementation is contained only withing the controller implementation of the message processor.

For example the steps to read a CV from a decoder using program track mode would be completed using the following steps:

  1. Send the message processor a “Enter Program Mode” message.
  2. Send the message processor a “Read CV” message requesting the CV number.
  3. The “Read CV” message returns the value contain in the decoders CV.
  4. Repeating the steps for each CV to be read.
  5. Send the message processor a “Exit Program Mode” message.

In a similar manner messages are sent to the message processor to set the speed and direction of locos, set decoder functions on or off or setting accessories etc.

Posted on

Reading Decoders

In order to get decoders loaded into the application there CV values need to be read.  In order to do this navigate to the “Loco Decoders” page and click the “Read Values” button at the top of the right hand column.

Once the “Read Values” button is clicked the controller will be put into Program Mode and basic CV values are read from the decoder from the track that is in Program Mode.  Once all the basic CV values are read the track will be taken out of Program Mode and decoder information will be displayed on the screen.

The decoder will also be added to the list of decoders on the left hand side of the page.

Once loaded the decoder can be linked to a locomotive.

Posted on

Initial Design

The aim of the DCC web application was to create a web base application that could run on a raspberry pi and interface with a DCC controller and allow the controller of locos and accessories.

OK This does sound a lot like JMRI but I found that JMRI did not have some features that I wanted to include, I did try looking at the java code to see if I could implement the features that I wanted within JMRI but found the architecture that JMRI to be a little bit…  Lets just say I decided to start from scratch.

So first things first I decided on the frameworks that should be used to create the application.

Spring boot was an obvious choice for dependency injection and the Restful services.

For the web interface I choose AnguarJS and bootstrap for the css framework.  Not long after starting Angular 2 was released and so I quickly decided that interface should be moved to using the newer Angular 2 and write the interface code using typescript rather than javascript.

So for the database I decided on using a basic derby database with a spring JPA implementation.  The reason behind the basic derby database was to keep the installation to a bare minimum without the need to setup mysql or similar on the raspberry pi before installing the web application.

To build the application and run the unit tests I decided on the tried and trusted Maven.  As for the the unit tests these are written using JUnit4 and also utilise Mockito to mock objects that are not being tested in individual tests.

Finally Jenkins to automate builds and run the static analysis which I decided to use SonarQube to keep an eye on the code quality and the unit test coverage.

And that pretty much covers the initial design decisions.