JMRI Hardware Support: MERGCBUS Main Support Page

MERGCBUS logo MERG logo

JMRI Documentation

As support for MERGCBUS continues to evolve, this is not a definitive MERGCBUS network guide.

These JMRI user guides contain considerable simplification of the MERGCBUS scheme, and are aimed at helping new users to JMRI or MERGCBUS, not systems developers.

The latest developers guide and full specification is held on the MERGCBUS wiki hosted by MERG.

JMRI MERGCBUS Support Pages

JMRI MERGCBUS Tools Support Pages

MERG menu

Connecting

Typical first-time Connection Steps

MERGCBUS Events

MERGCBUS events are transmitted as a one-to-many network, connected modules receive all network data then choose whether or not to act on them.
This enables multiple modules to act on a single event, eg :

MERGCBUS events generally come in two types: "ON" and "OFF".

Events can be short ( SLiM ) events, eg +11 for event 11 on.

Events can be long ( FLiM ) events, eg -N2E7 for node 2 event 7 off.

JMRI, being both a consumer and producer of events, can send and receive on any node number and any event.

Adding events to JMRI

merg cbus add light

MERGCBUS events are stored as

These are accessed via JMRI Tables, ie PanelPro > Tools > Tables > ( Sensors, Turnouts or Lights ) .
When the table loads, click on " Add... " button at bottom left to create an item.

merg cbus add sensor

For most short events, you just need to enter the number. Here's a few examples :

merg cbus add turnout
Hardware Address Meaning Event Consumed
as Sensor
Event Produced
as Turnout
Event Produced
as Light turned
18 Event 18 On
Event 18 Off
Sets sensor Active
Sets sensor Inactive
Thrown
Closed
On
Off
18;21 Event 18 On
Event 21 On
Sets sensor Active
Sets sensor Inactive
Thrown
Closed
On
Off
+18;-21 Event 18 On
Event 21 Off
Sets sensor Active
Sets sensor Inactive
Thrown
Closed
On
Off
+N2E18;-N2E18 Node 2 Event 18 On
Node 2 Event 18 Off
Sets sensor Active
Sets sensor Inactive
Thrown
Closed
On
Off
merg cbus add new invalid name

You will need to enter the Hardware Address in a JMRI recognised format to create the event.
If the create button is grayed out, check your hardware naming format.

Short events 1-9 may need to be entered with a leading zero, eg 03 for event 3.
This could also be entered as a hardware address of +3 .

Adding a User Name ( using any characters ) when creating a table item may make accessing it easier in JMRI.

Remember to save your tables!

For more on events, see JMRI system naming with MERGCBUS.

DCC over MERGCBUS

JMRI MERG CONNECTION DCC DEFAULT PREFERENCES

DCC is not a requirement for MERGCBUS or JMRI. Many DC layouts use MERGCBUS + JMRI for route setting, signalling and track occupancy purposes.

JMRI will send the DCC events over the MERGCBUS network and can be monitored within the MERG CBUS console

The MERG system allows for advanced consisting to be set using CANCMD and CANCABs.

JMRI Consisting : Advanced Decoder Consisting is currently unsupported in JMRI MERGCBUS connections, ensure set to internal.
Double-heading or consisting is not as common in the UK, with generally much shorter trains than continental prototypes.

Primary Address Consists are supported however.

Connecting a MERG DCC Command Station CANCMD

Make sure that main JMRI Preferences Defaults are set to your MERG connection for Throttles, Power Control, Command Station, Service Programmer and Ops Mode Programmer.

Although the CANCMD supports Advanced Consisting, this has not been implemented within JMRI at present.

You can use an existing DCC command station, or have a separate DCC command station for a programming track ( eg. a Sprog ) by setting these options.

Events do not need to be set up to connect a MERG DCC Command Station CANCMD.

DCC Accessory Decoders can be controlled over MERGCBUS and a CANCMD by creating turnouts with explicit RDCCx Opscode commands, see MERGCBUS hex event naming.
This is also discussed within the MERGCBUS WIKI documentation.

Programming Train CV's

Program train CV's using DecoderPro

CANCMD fully supports DCC CV programming.

Signalling

There are multiple ways to interface JMRI signalling with MERGCBUS modules.

You are strongly advised to let JMRI control your signal logic, however it's also possible to link JMRI with 3rd party signalling over MERGCBUS.

JMRI includes various UK signalling definitions, a popular choice being BR2003, however for some layouts LMS 1932 or GWR 1931 may be more appropriate.

Once you've got basic signalling setup, you can customise your layout with things like the UK East Coast Main Line flashing green aspects.
Add JMRI Logix to listen for the correct conditions to display the aspect and send events to the layout.

Sending JMRI Controlled Signal Logic to your layout

JMRI signal mast turnout controlled

There are multiple ways of sending cbus events from JMRI out to LED or servo signal control modules, this is just one approach.

With this approach, you can easily add and edit which MERGCBUS events are sent from a JMRI controlled signal without editing or re-creating the underlying signal logic.

It also ensures that only 1 MERGCBUS message is sent for flashing aspects, specify this flashing in the module board, not JMRI! Some Signal Mast types send 1 MERGCBUS message for each flash.
A layout with 20 quad aspect signals could send 40 odd cbus events every 0.5seconds, 4,800 events per minute. This could make network diagnosis awkward, although very unlikely to swamp a MERGCBUS network.

As stated previously, this is just one approach. There are may ways of interfacing JMRI with MERGCBUS signalling systems.

Receiving Module supplied or existing Signal Logic into JMRI

This is normally done the other way round, however people may have existing systems in place which they do not want to change.

Third Party / Support

Originally named CBUS by co-founder Gil Fuchs, MERGCBUS isn't a MERG project and is "open source" or public domain.
In 2007, when the scheme was being developed, MERG had a website willing to host the project and organised the kits ( many designed by the other MERGCBUS co-founder Mike Bolton ).
The scheme is now called MERGCBUS to avoid conflict with a home automation system which has trademark on a similar name.

MERGCBUS co-founders : Gil Fuchs, Mike Bolton

Mike Bolton designed hardware and coded firmware for many of the initial modules, lead for CAN-RS module and code

The standalone MERG DCC programmer was the inspiration behind the popular SPROG DCC programmer, which is fully supported in JMRI.

Andrew Crosland has been heavily involved with JMRI through both SPROG and MERGCBUS, writing much code to enable JMRI to support MERGCBUS.
Anything to do with CANUSB, CANUSB4 and Gridconnect etc, he's an expert!
Andrew also he wrote the MERG CANCMD code and designed the MERG CANUSB4

Kevin Dickerson was instrumental in writing the original JMRI to MERGCBUS interfaces, supported by Andrew.

Pete Brownlow has updated the CANCMD firmware, also lead for the CANEther module, and the MERG JMRI go-to person!

Amauri Albuquerque has been the main SW writer for the CANPiWi ( based on the RPi Zero W and is an interface between ED/ WiThrottle and CBUS ), and CANPi.
CANPi is a version of this for a RPi 3B ( with Ian Hart's CAP.)

Ian Hart designed the Pi CAP, also the popular CANMIO range of modules.

Roger Healey is also key to the MERGCBUS success story being lead developer on the FCU, a Windows configuration utility for setting up FLiM modules ( independent of JMRI )

N J Philips established the mergCbusServer and keeps it up to date.

The MERG kit elves who package the kit parts are amazing, having enabled thousands of MERGCBUS module kits to be sent out to members.

The JMRI developers do a fantastic job of keeping updates flowing, making JMRI easier to use on each release :-)

Apologies to anyone missed out or inaccuracies, let us know and I'll gladly edit the page! - SY