JMRI Hardware Support: MERGCBUS Main Support Page
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 Support This Page
- Naming events in JMRI
- Connection Details - MERG CAN connection options in the main JMRI preferences.
- JMRI CAN Support
- JMRI Scripting for CAN frames ( jython )
JMRI MERGCBUS Tools Support Pages
- Console - Tool for viewing and sending CAN frames / events.
- Send Frame - Send CAN frames or MERGCBUS events repeatedly in a loop
- Event Capture Tool - Capture MERGCBUS events
- Event Table - Logs MERGCBUS events and presents them in a table
- Node Config Tool - For MERGCBUS node configuration and editing Node Variables.
Typical first-time Connection Steps
- Many Modern Operating Systems do not require device drivers to be installed when connecting a MERG CANUSB4 to a computer.
Plug in, and check that no major error messages appear.
- Install JMRI
- Connection Preferences - Select MERG connection,
use "CAN via MERG CAN-RS or CAN-USB" for a CANUSB4 with default settings.
You could also choose CAN Simulation if you have no physical connection to a MERGCBUS network.
- Save / Restart JMRI
- If you are using DCC over the MERG connection, check that JMRI Preferences > Defaults
are set correctly, see DCC over MERGCBUS.
Restart JMRI a few times, checking that the default connection preferences have stuck.
- A new menu item MERG appears in the PanelPro or DecoderPro window, containing the MERG tools.
Help > Window Help will show relevant info in the tools and any JMRI window.
- Test events can be sent from the MERG Send CAN Frame tool.
Set the test event, eg Frame packets "+1" and / or "-2" ( without the quotation marks ), waiting 500 msec and click Start Sending to generate steady MERGCBUS network traffic.
Check that these events are actually being sent over the MERGCBUS network by using a module such as a CANACT.
- Use an external producer module to test connectivity receiving events, confirming they appear in the MERG CBUS console.
- The JMRI System Console is a good tool for diagnosing issues during setup and operation.
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 :
- A physical turnout ( UK - point ) microswitch sensor is wired to a
MERGCBUS producer module .
The module has been taught to send a particular event when the switch is closed.
- This event is received by a relay driver ( consumer ), which changes the frog polarity.
- The event is also received by an LED module which has not been taught the event, so does nothing.
- The event is also received by an LED module ( consumer ), lighting a LED on a mimic panel.
- The event is also received by JMRI ( consumer )
- A JMRI sensor has been created with the event number, causing the sensor status to change
A JMRI turnout ( point ) has its turnout feedback set by this sensor.
JMRI panel(s) update to reflect the new point position.
- JMRI Signalling Logic recalculates, and on the JMRI panel, a signal protecting the point changes from Red to Green.
- The JMRI Signal Mast mapping is checked and the relevant MERGCBUS event is sent to change that on the layout ( producer )
- This event is received by a LED ( or servo ) module which changes a physical on-layout signal ( consumer )
- This event is also received by a LED module which changes a signal on a mimic panel ( consumer )
- A train, controlled by ( JMRI DispatcherPro for a JMRI Layout Editor Panel ) or (
JMRI Warrants for a JMRI Control Panel Editor panel ),
sees that the signal ahead has cleared and can increase its speed.
DCC commands are generated from JMRI and sent over MERGCBUS using special events ( producer )
- These MERGCBUS events are received by a MERG CANCMD ( consumer ),
which then sends the actual DCC command out to the track or boosters.
This train had requested the section ahead of it, JMRI Dispactcher/Warrants had allocated it ( after checking occupancy and other rules ), then sent the turnout event ( producer ) to change the points.
The event was received by a Servo or solenoid module ( consumer ) which had triggered correctly, changing the point sensor right at the top of this example.
- You can start small and think big,
adding more modules as your time and experience allows.
Many people use MERGCBUS and JMRI purely for displaying turnout positions, adding things like track occupancy, on-layout signals, mimic panels etc. at a later date.
If you anticipate adding track occupancy, especially track circuit electrical block ( Train On Track Indicators ), ideally plan the electrical scheme for this on your layout at any early stage.
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
MERGCBUS events are stored as
For most short events, you just need to enter the number. Here's a few examples :
|Hardware Address||Meaning||Event Consumed
as Light turned
||Event 18 On
Event 18 Off
|Sets sensor Active
Sets sensor Inactive
||Event 18 On
Event 21 On
|Sets sensor Active
Sets sensor Inactive
||Event 18 On
Event 21 Off
|Sets sensor Active
Sets sensor Inactive
||Node 2 Event 18 On
Node 2 Event 18 Off
|Sets sensor Active
Sets sensor Inactive
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 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.
: 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.
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.
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
There are multiple ways of sending cbus events from JMRI out to LED or servo signal control modules, this is just one approach.
- Add all aspects to the signal in question to the Turnout Table, eg
Signal1Red : Hardware address :
+N126E412( Set Node to whatever your JMRI node is, only uses the ON event )
Signal1Flashing Precautionary : Hardware address :
Signals which can only display 2 aspects ( eg a Servo controlling a semaphore signal ) can be setup with 1 MERGCBUS event, using the ON and OFF status, eg Signal5RedGreen :
- It's also worth creating an internal turnout named something like DummySignalOutput.
You can use this output for signals which have not yet been installed with CAN events but may have in future.
- Add the Signal Mast via the Signal Mast Table
- Specify type : Turnout Controlled
- Specify which turnout ( aka JMRI message output ) you wish to show to show for each aspect, eg. Signal1Red Thrown.
- For virtual signal masts which are not yet physically installed on your layout, use the DummySignalOutput internal turnout created earlier.
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.
- Create a virtual Signal Mast, named something like SignalMast7
- Create incoming MERGCBUS event(s) as sensor(s), eg "SignalMast7Red".
- For each signal state ( eg. Stop or Proceed ),
create a new JMRI Logix
in the JMRI Logix Table to set the signal head or mast as appropriate, similar to
If SignalMast7Red is active, set SignalMast7 to Stop
- Repeat for each signal state
- https://www.merg.org.uk/merg_resources/cbus.php The Model Electronic Ralway Group MERGCBUS introduction page.
- https://www.merg.org.uk/merg_wiki/doku.php?id=public:cbuspublic:start The Model Electronic Ralway Group MERGCBUS Wiki with full protocol specification.
- https://www.merg.org.uk/merg_resources/cbus-dcc.php The Model Electronic Railway Group MERG-DCC help page.
MERGCBUS kits. Constructing kits may not be an easy task for all, it requires a certain amount of technical ability, and foremost the willingness to learn.
Classic refers to a 15v AC kit power supply ( most easily adaptable for 12v DC ), 2G are all 12v DC kits.
Classic and 2G modules can both be on the same network with an element of care, seek further advice if in any doubt, do not guess!
Reliabiliy soldering MERG kits together may not be the best cbus route for all. If you are in the least bit impatient, you may be better suited to a commercial offering.
If you wish to learn about electronics and their application in a model railway environment however, the member resources available are many and varied!
- Please ask for help by other JMRI Users at Groups.io, or if a MERG member on the very active MERG members forum.
Current known ( open ) issues relating to MERG by the JMRI developers on Github.
Github is not a support tool.
- https://github.com/MERG-DEV MERG CBUS Development on Github - Much of it is licensed under the GNU General Public License v3.0.
- https://github.com/phillipsnj/mergCbusServer MERGCBUS Server - enables multiple network connections to a MERG CANUSB4 using Node.js , MIT License.
- https://github.com/amaurial/mergCanBus MERGCBUS implementation for Arduino. ( + have a look at Amauria's other MERGCBUS Github projects )
- http://www.oscale.net/?q=en/cbus MERGCBUS on an Arduino using CAN BUS shields - See download links at bottom ( in English + German )
- https://www.npmjs.com/search?q=keywords:MERG node.js modules to create a MERG CBUS module + Class to create a MERG CBUS module conneted via ethernet.
- http://www.rickdavis.co.uk/rail/control-cbus.php Middle Earth Model Railway has over 70 MERGCBUS modules installed on it and uses JMRI.
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