JMRI: MERG CBUS Event Table
The MERG CBUS Event Table displays event information on your CBUS connection.
Both incoming to JMRI and outgoing messages are logged to the table.
While the window is open, it will maintain a list of short on / off events, long on / off events, extended OPC on / off events, on / off accessory response events.
Each event and node combination is unique, the maximum event number is 65,535.
The maximum node number is also 65,535.
The table will always start with no entries, data is not maintained between sessions.
You can open the table automatically by adding it to your JMRI startup action list.
PanelPro > Edit Preferences > Start Up > Add > Perform Action > Open CBUS Event Table.
Short event codes will be stripped of any node number contained within the event CAN message.
All numeric values decimal.
The filter will highlight any text entered, you can use and spaces in the search field.
The table will then only show events which contain the search phrase.
Text in the information panel at the bottom of the event table will also be highlighted.
New events added to the table created manually with the create event window at the right of the filter window default to an unknown status, and do not send an event message on creation.
The order can be rearranged by dragging the column header.
Right click in the header to select a list of columns to display.
Change the column sort order by left clicking on the column header.
Event or device number reported within an event CAN message.
Node number reported by an event CAN message.
On or Off
Last reported, current state of event, On or Off.
Send On / Send Off / Toggle
Send an on or off event. If the the event has a node number, this will be a long event otherwise short.
Toggle: If event last reported state is currently on, sends an off event and vice versa.
Event Name and Comment
Editable event name and comments.
Node name only active when using imported events.
The last CAN ID heard by the event.
On / Off / In / Out / Total Session
Running total on events.
Running total off events.
Running total events sent out by JMRI.
Running total events received in by JMRI.
Time + datestamp of the last time the event was heard.
Delete event from this table after confirmation, option to disable further confirmatiions.
The event will be re-added to the table if re-heard on the network.
On clicking Status, JMRI sends an event accessory status request message to the network, long if the event has a node, short if without.
This triggers a JMRI event listener which awaits a response from the event, either a request response or a normal event is accepted as a response.
If nothing is set in event feedback, the default timeout is 5 seconds from the same event and node combination.
Some users may want to create a new JMRI turnout, sensor or light
to represent the get status button and send the event request status message.
The hardware addresses for these request events would look something like:
|Hardware Address||Ops Code Hex||Ops Code Translated||Node Dec||Event Dec|
|X9A0000007B||9A||Accessory Request Short||0||123|
|X92007B01C8||92||Accessory Request Long||123||456|
There are a few methods within JMRI of sending this event to ping every few seconds, one being to create a jython script to ping 1 sensor every few seconds, and use logix on this 1 sensor to create other ping event status requests outputs.
When an event response request message is heard on the network, the event table will listen for event feedback.
When an event is sent by JMRI which has a number in the feedback response column, the event table will listen for its response and warn if this is not received.
The system will listen for a feedback event in the form of a response event, or a normal on off event. The response events do not have to status ( on or off ) match, and can be any of the data lengths.
JMRI core does not currently act on response events.
FB Status - Status of the very last feedback request.
FB reqiured - Number of response events required to prove.
Unavailable if FB Event or Node number is set.
FB Outstanding - How many feedback events are currently outstanding.
FB Timeout - ms before alerts set in.
Unavailable if FB Event or node numbers set.
FB Event - If this particular event is feedback for another event, include that other event number.
FB Node - If this particular event is feedback for another event, include that event node number.
From the File menu, choose Export to open file save dialog and save the contents of the table in a CSV (comma separated values) text file.
Choose the Print (Preview) menu to create a hard copy of the Event Table.
The events are not currently maintained between sessions.
It is not currently possible to load previous session data into the table from file.
You can import event and node numbers, names and their node names from a FCU config file.
Click on File > Import FCU events, then select an FCU congiguration xml file.
The FCU config file may well contain multiple copies of the event, ( for teaching to different nodes ), so only the 1st unique event and node number found in the file is added.
An event name within the file will be added to an existing table entry if it has no event name.
- ASON - Sent when user clicks send on / toggle button, node number 0
- ASOF - Sent when user clicks send off / toggle button, node number 0
- ACON - Sent when user clicks send on / toggle button, node number > 0
- ACOF - Sent when user clicks send off / toggle button, node number > 0
- ASRQ - Sent when user clicks status button, node number 0
- AREQ - Sent when user clicks status button, node number > 0
Received OPC's can be from other JMRI components, or from an external CBUS connection.
All opscodes defined as an accessory event ( with the exception of Fast Clock ) are constant listeners, ie
- ASRQ / AREQ - Autostarts feedback timer for the associated event.
- ACON / ACOF
- ARON / AROF
- ASON / ASOF
- ARSON / ARSOF
- ACON1 / ACOF1
- ARON1 / AROF1
- ASON1 / ASOF1
- ARSON1 / ARSOF1
- ACON2 / ACOF2
- ARON2 / AROF2
- ASON2 / ASOF2
- ARSON2 / ARSOF2
- ACON3 / ACOF3
- ARON3 / AROF3
- ASON3 / ASOF3
- ARSON3 / ARSOF3
Variance to MERG CBUS Developers Guide 6b
In this data model, it is assumed that event and node combinations are the unique factor.
Any event OPCs sent with extra data bytes will be logged according to its core event and node combination, irrelevant of extra data bytes.
The extra data is not currently displayed in the table, although likely to be added as a new column at some point.
You can view this help page within JMRI by selecting Help > Window Help in the top bar of the MERG Event Table window.
The CBUS Console can help you figure out what events are happening on your layout.