Serge NOEL
952 lines
34 KiB
Plaintext
952 lines
34 KiB
Plaintext
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy for HTML5 for Apple macOS version 5.8.0">
|
|
<meta name="keywords" content="JMRI help CBUS naming long short events event add sensor hex">
|
|
<title>JMRI Hardware Support - CBUS® - Events</title><!--#include virtual="/help/en/parts/Style.shtml" -->
|
|
</head>
|
|
<body>
|
|
<!--#include virtual="/help/en/parts/Header.shtml" -->
|
|
|
|
<div id="mBody">
|
|
<!--#include virtual="Sidebar.shtml" -->
|
|
|
|
<div id="mainContent">
|
|
<h1>JMRI Hardware Support: CBUS - Naming</h1>
|
|
|
|
<ul class="snav">
|
|
<li>
|
|
<a href="#events">Event Name and Numbering</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#turnout">Turnouts</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#reporters">Reporters</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#sysname">System Names</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#summary">Summary of CBUS Events</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#namingspec">Event Naming Specification</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#hex">Sending hex strings</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#opc">CBUS Operation Codes in JMRI</a>
|
|
</li>
|
|
</ul>
|
|
<!--
|
|
A big chunk of text discussing naming options + naming table
|
|
+ sensors moved here from /help/en/html/hardware/can/cbus/index.shtml
|
|
@icklesteve June 2018
|
|
-->
|
|
|
|
<p>This page describes how JMRI uses System Names to access CBUS-attached resources.</p>
|
|
|
|
<h2 id="events">Event Name and Numbering</h2>
|
|
|
|
<h3>Event Conventions</h3>
|
|
|
|
<div>
|
|
<h4>Short Event Suggestions</h4>
|
|
|
|
<p>Suggestion from Mike Bolton :</p>
|
|
|
|
<p>His club has adopted the convention of 1 to 9999 for turnouts and 10000 upwards for
|
|
sensors.<br>
|
|
This prevents the possibility of sending sensor events from their CANCABs (9999 max)<br>
|
|
but they tie any relevant sensors to the turnout numbers e.g.<br>
|
|
TO_1 is +1 and the feedback from this is +10001 for one way and +11001 for the other
|
|
way.<br>
|
|
Using short events (or device numbers) this way makes life very simple with JMRI.<br>
|
|
They control the turnouts from the CANCABs as well (also Smartphone throttles), this is
|
|
reflected in the JMRI panel and works a treat!<br>
|
|
Their layout control panel is on a touchscreen monitor connected to a RPi 3B running JMRI,
|
|
with additional control panels through <a href="../../../web/index.shtml">JMRI Web
|
|
Server</a>.</p>
|
|
|
|
<p>Another use of event segmentation could be for modular club layouts, where various club
|
|
members building a section at home, then bringing it together into 1 big super layout.<br>
|
|
Module 1 would have events 1,000 > 1,999 Module 2 would have 2,000 > 2,999 etc.</p>
|
|
|
|
<h4>Long Event Suggestions</h4>
|
|
|
|
<p>Suggestion from Pete Brownlow:</p>
|
|
|
|
<p>Pete uses pretty much exclusively long events.<br>
|
|
For events sent from JMRI, he segments by node number that JMRI generates (for example,
|
|
node 99 for turnouts, node 98 for signals and node 97 for control sensors).<br>
|
|
This makes it very easy to see what the events are for when looking at an event log.<br>
|
|
For all input sensors from CBUS, he leaves the long event as generated by the CBUS module,
|
|
so it will retain the node number of that module, (eg; Node 256 event 1) so there's no risk
|
|
of generating the same event as a cab.<br>
|
|
Because he doesn't use short events, there's no need to segment by the event/device number.
|
|
It also avoids the whole task of having to teach any producer events, just using what comes
|
|
from the modules by default.</p>
|
|
|
|
<h4>Event Polarity</h4>
|
|
|
|
<p>You can invert the polarity of ON and OFF events</p>
|
|
|
|
<ul>
|
|
<li>on the initial producer module</li>
|
|
|
|
<li>Hardware naming format when entered as a JMRI sensor, turnout or light</li>
|
|
|
|
<li>Sensor or turnout settings within JMRI</li>
|
|
</ul>
|
|
|
|
<h4>Start of Day Events</h4>
|
|
|
|
<p>When JMRI is started, it doesn't presume that all sensors, turnouts and lights are
|
|
active or inactive, they have an unknown status.</p>
|
|
|
|
<p>The vast majority of MERG module kits can send the current status of their inputs or
|
|
outputs in response to a SOD event taught to that module.</p>
|
|
|
|
<p>JMRI can store cross-session information such as Memory Variables and Block Values (
|
|
Train Describer value )</p>
|
|
|
|
<p>When JMRI loads a panel, and the Track Power is on, block values from the previous
|
|
session are loaded if the block is active.</p>
|
|
|
|
<p>It may make sense to set Track Power to Off on JMRI Startup and when a panel loads,
|
|
switching the track power on after the panel has fully loaded.</p>
|
|
|
|
<h4 id="automatic">Sensors - JMRI Automatic Creation</h4>
|
|
|
|
<p>JMRI DOES NOT attempt to create Sensor objects from the traffic that it hears on the
|
|
CBUS network, unlike some other hardware systems.</p>
|
|
|
|
<p>This is because CBUS is essentially a networking protocol, not a sensor generator.
|
|
Events are not intrinsically associated with specific hardware objects, people can use
|
|
events in many ways.</p>
|
|
|
|
<p>You can request the status of a sensor by clicking Query in the sensor table.</p>
|
|
|
|
<h4 id="turnout">Turnout Operation</h4>
|
|
|
|
<p>CBUS is setup in JMRI for 4 types of turnout ( output ) feedback.</p>
|
|
|
|
<p>Turnouts have 2 states, the commanded state, and the Feedback state which is used on
|
|
panel displays and elsewhere.</p>
|
|
|
|
<p>Turnouts are always in Monitoring mode hence reflect the commanded state from the
|
|
Layout.<br>
|
|
In addition, feedback can be enhanced with</p>
|
|
|
|
<ul>
|
|
<li>Direct - When the commanded state is changed, the feedback state will reflect the
|
|
commanded state. ( default )</li>
|
|
|
|
<li>Delayed - When the commanded state is changed, the feedback state will reflect the
|
|
commanded state following a brief delay.</li>
|
|
|
|
<li>1 Sensor - When the commanded state is changed, the feedback state will not
|
|
change.<br>
|
|
The feedback state will change when the sensor attached changes state ( eg. Single
|
|
microswitch events )</li>
|
|
|
|
<li>2 Sensor - When the commanded state is changed, the feedback state will not
|
|
change.<br>
|
|
Feedback state will change when the 2 sensors agree on state ( eg. servo end travel
|
|
events )</li>
|
|
</ul>
|
|
|
|
<p>You can request the status of a turnout by clicking Query in the turnout table.<br>
|
|
If a turnout uses 1 or 2 sensor feedback, these sensor statuses will also be requested.</p>
|
|
|
|
<p>See <a href="../../../doc/Technical/TurnoutFeedback.shtml">JMRI : Turnout Feedback</a>
|
|
for more info.</p>
|
|
|
|
<hr>
|
|
|
|
<p>As Turnouts are JMRI outputs, the Event can be queried as per other MERG CBUS query
|
|
events.<br>
|
|
If a Turnout has address "MT+4" and is closed, when JMRI hears an appropriate Event Status
|
|
Request ( eg. an ARSQ for Event 4 ), it will respond with an ARSOF 4 Can Frame.<br>
|
|
This is used in modules such as MERG CANCAB to enhance the Toggle Turnout button, ie, if
|
|
the query returns OFF, CANCAB sends ON and vice-versa.</p>
|
|
|
|
<h4 id="reporters">Reporter ( incl. RFID ) data from CBUS</h4>
|
|
|
|
<p><a href="../../../tools/Reporters.shtml">JMRI Reporters</a> do not have Off or On
|
|
events, they just use a device ( short event ) or node number.</p>
|
|
|
|
<p>Reporters are created by clicking the New button within the <a href=
|
|
"../../../../package/jmri/jmrit/beantable/ReporterTable.shtml">Reporter Table</a>.</p>
|
|
|
|
<p>You can create multiple reporters by checking the Add Sequential Range option.</p>
|
|
|
|
<p>Like Turnouts Sensors and Lights, these are not created automatically in CBUS.</p>
|
|
|
|
<p>A typical system name for a reporter would be <code>MR123</code> or <code>MR1234</code>
|
|
( no event On or Off ) .</p>
|
|
|
|
<p>The DDES and ACDAT OPC's are used for reporter data.</p>
|
|
|
|
<p>When an incoming DDES or ACDAT OPC is heard on the network, JMRI will look for a
|
|
reporter matching the device or node number in the Reporter Table.</p>
|
|
|
|
<p>If a reporter exists, the <a href="../../../tools/IdTags.shtml">ID tag</a> within the 5
|
|
data bytes will be looked up from the <a href=
|
|
"../../../../package/jmri/jmrit/beantable/IdTagTable.shtml">ID Tag table</a>.</p>
|
|
|
|
<p>If there's no matching ID Tag on the table, one will be created and updated.</p>
|
|
|
|
<p>If the ID tag was previously active for another reporter, the previous reporter will
|
|
have the tag removed from its report.</p>
|
|
|
|
<p>Valid reporter numbers are minimum 0, to maximum 65535.</p>
|
|
|
|
<p>The DDES ( device number data ) and ACDAT ( node data ) messages are currently handled
|
|
in exactly the same way, ie the first 2 bytes are used as the Reporter identifier.</p>
|
|
|
|
<p>This means that a reporter created via a number of 77 will respond to both DDES device
|
|
77 and ACDAT of node 77.</p>
|
|
|
|
<p>Reporters are saved in your main panel file, along with turnouts and sensors etc.</p>
|
|
|
|
<p>ID Tags cross-session automatically, no saving is necessary.</p>
|
|
</div>
|
|
|
|
<h2 id="sysname">System Names</h2>
|
|
|
|
<div>
|
|
<p>When adding an item to your JMRI <a href=
|
|
"../../../../package/jmri/jmrit/beantable/TurnoutTable.shtml">Turnout Table</a>, <a href=
|
|
"../../../../package/jmri/jmrit/beantable/SensorTable.shtml">Sensor Table</a>, <a href=
|
|
"../../../../package/jmri/jmrit/beantable/LightTable.shtml">Light Table</a> or <a href=
|
|
"../../../../package/jmri/jmrit/beantable/ReporterTable.shtml">Reporter Table</a>, a JMRI
|
|
system name is automatically created from the hardware address you input.</p>
|
|
|
|
<p><strong>This really is all you need to know to get started</strong>, the rest of the
|
|
information on this page is aimed at advanced use cases, debugging panel xml files, and
|
|
system development.</p>
|
|
|
|
<p>JMRI internally associates CBUS events with individual JMRI objects (Sensors, Turnouts,
|
|
Lights, etc.) via the <a href="../../../doc/Technical/Names.shtml">JMRI System
|
|
Names</a>.</p>
|
|
|
|
<p>Depending on which CBUS event IDs are used on a particular layout, these system names
|
|
can get very long, in which case the "user names" are much more useful.</p>
|
|
|
|
<p>The 1st letter of a sensor, turnout or light system name is the JMRI system letter,
|
|
generally "M" for MERG connections.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<a href="../../../tools/Sensors.shtml">JMRI sensors</a> use the type letter "S", e.g.
|
|
<code>MS+123;-345</code>" defines a Sensor that follows the "123 ON" and "345 OFF"
|
|
events to change state.
|
|
</li>
|
|
|
|
<li>
|
|
<a href="../../../tools/Turnouts.shtml">JMRI turnouts</a> use the type letter "T", e.g.
|
|
<code>MT+123;-345</code>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="../../../tools/Lights.shtml">JMRI Lights</a> use the type letter "L", e.g.
|
|
<code>ML+123;-345</code>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="../../../tools/Reporters.shtml">JMRI Reporters</a> use the type letter "R",
|
|
e.g. <code>MR123</code>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3 id="summary">Summary of CBUS events ( Sensors, Turnouts and Lights )</h3>
|
|
|
|
<table border="1">
|
|
<tbody>
|
|
<tr>
|
|
<th>In/Out</th>
|
|
<th>Entered as Hardware Address</th>
|
|
<th>Meaning</th>
|
|
<th>makes System Name</th>
|
|
<th>Mask</th>
|
|
<th>Equivalent</th>
|
|
<th>Min.</th>
|
|
<th>Max.</th>
|
|
<th>Notes</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>both</td>
|
|
<td>+18</td>
|
|
<td>event 18 On;<br>
|
|
event 18 Off</td>
|
|
<td>MT+18</td>
|
|
<td>integer</td>
|
|
<td>+18;-18</td>
|
|
<td>01</td>
|
|
<td>65535</td>
|
|
<td>SLiM Short Events ASON / ASOF</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>both</td>
|
|
<td>+N2E18</td>
|
|
<td>Node 2 Event 18; On Event = Active;<br>
|
|
Off Event = Inactive</td>
|
|
<td>MT+N2E18;-N2E18</td>
|
|
<td>
|
|
</td>
|
|
<td>
|
|
</td>
|
|
<td>N1E1;<br>
|
|
N1E1</td>
|
|
<td>N 65535 E 65535 ;<br>
|
|
N 65535 E 65535</td>
|
|
<td>FLiM Long Events ACON / ACOF</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>both</td>
|
|
<td>+18;+21</td>
|
|
<td>event 18 On;<br>
|
|
event 21 On</td>
|
|
<td>MT18;21</td>
|
|
<td>integer;integer</td>
|
|
<td>+18;+21</td>
|
|
<td>1 ; 1</td>
|
|
<td>65535; 65535</td>
|
|
<td>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>both</td>
|
|
<td>+18;-21</td>
|
|
<td>event 18 On;<br>
|
|
event21 Off</td>
|
|
<td>MT+18;-21</td>
|
|
<td>idem signed</td>
|
|
<td>+18;-21</td>
|
|
<td>
|
|
</td>
|
|
<td>
|
|
</td>
|
|
<td>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>both</td>
|
|
<td>X90002D002E;X91FFFFFFFE</td>
|
|
<td>hex CAN frame msg. Active;<br>
|
|
hex CAN frame msg. Inactive</td>
|
|
<td>MTX90002D002E;X91FFFFFFFE</td>
|
|
<td>hex;hex</td>
|
|
<td>N/A</td>
|
|
<td colspan="2">Depends on opcode</td>
|
|
<td>In eg. Thrown sends Long Event N 45 E 46<br>
|
|
Closed sends Long Event N 65535 E 65534</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>both</td>
|
|
<td>200018</td>
|
|
<td>Node 2 Event 18; On Event = Active;<br>
|
|
Off Event = Inactive</td>
|
|
<td>MS200018</td>
|
|
<td>node + (5 digits)</td>
|
|
<td>N2E18</td>
|
|
<td>100001</td>
|
|
<td>6553565535</td>
|
|
<td>Current max. that can be entered (JMRI 4.12) is 2147483647</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<!-- this table is an exceprt from the table in the help/en/html/doc/Technical/Names.shtml
|
|
based on information from the Hardware help pages
|
|
by Egbert Broerse @silverailscolo July 2017
|
|
|
|
|
|
Please also update this page when adding / improving names which will and won't work
|
|
|
|
|
|
-->
|
|
|
|
<p>65,536 nodes and 65,535 events gives approx 4,294,901,760 event combinations.</p>
|
|
|
|
<p>65,535 is unrealistic for events within a node but does allow for useful segmentation of
|
|
event ranges.</p>
|
|
|
|
<p>MERG module kits can use the whole CBUS range of event numbers, on a reset startup
|
|
operating in SLiM short event mode.<br>
|
|
A MERG CANLED kit can support up to 255 taught events</p>
|
|
</div>
|
|
|
|
<h2 id="namingspec">Event Naming Specification</h2>
|
|
|
|
<div>
|
|
<p>A Sensor is defined by two events: The one that sets it ACTIVE, and the one that sets it
|
|
INACTIVE.<br>
|
|
If these are mapped to ON and OFF frames with the same event ID number, respectively, only
|
|
the event ID number need be specified:<br>
|
|
<code>MS18</code> The number is decimal.</p>
|
|
|
|
<p>To increase versatility, it's possible to use different event ID numbers for the ACTIVE
|
|
transition (by default, an ON frame) and INACTIVE transition (by default, an OFF
|
|
frame):<br>
|
|
<code>MS18;21</code></p>
|
|
|
|
<p>The ON and OFF coding of CBUS is not entirely consistent with the event model,<br>
|
|
it may be useful to connect the ACTIVE or INACTIVE transition of a JMRI Sensor to an OFF or
|
|
ON CBUS frame respectively.<br>
|
|
Leading "+" and "-" characters can do this. For example,<br>
|
|
<code>MS-18;+21</code><br>
|
|
defines a sensor that goes ACTIVE when an OFF frame with ID number 18 is received,<br>
|
|
and goes INACTIVE when an ON frame with ID number 21 is received.</p>
|
|
|
|
<p>CBUS event numbers (usually) contain a node number in their most-significant bytes.<br>
|
|
You can specify the node number either by using a full 5 decimal digits for the event
|
|
number itself, preceded by the node number:<br>
|
|
<code>MS200018</code><br>
|
|
or by using the letters "N" and "E" to specify the separate parts:<br>
|
|
<code>MSN2E18</code><br></p>
|
|
|
|
<p>You can mask off part of the CBUS packet, so any values in the masked part will still
|
|
match, using the "M" format letter.<br>
|
|
<code>MS200018M07</code><br>
|
|
"M" indicates the start of a hexadecimal mask that will be applied, where 1 bits in the
|
|
mask will be zero bits in the resulting value.<br>
|
|
In the example above, "18" through "1F" will match.<br>
|
|
This is particularly useful for matching e.g. CBUS short events, where parts of the packet
|
|
include the node number which should (usually) be ignored.</p>
|
|
</div>
|
|
|
|
<h2 id="hex">Sending hex strings</h2>
|
|
|
|
<div>
|
|
<p>Hexadecimal numbering is based on the power of 16, using 0-9, then A-F.</p>
|
|
|
|
<p>CBUS modules communicate by messages with a fixed format: One byte of command and length
|
|
information, followed optionally by additional data bytes.</p>
|
|
|
|
<p>In it's most simple form, this is used to send identifiable "events". In turn, events
|
|
come in two types: "ON" and "OFF", with two forms, short ( SLiM ), and long ( FiLM ).</p>
|
|
|
|
<p>These are actually sent across a CBUS network in the form of an opcode, the command
|
|
information.</p>
|
|
|
|
<p>There are 255 opcodes, the length of the data string following the opcode changes
|
|
depending on which opcode is used.</p>
|
|
|
|
<p>There are multiple opcodes for events, Controlling and programming DCC devices, DCC
|
|
consisting, Programming nodes with Node Variables, Programming nodes with events, Fast
|
|
clock and temperature information, RfID reader data, and many more.</p>
|
|
|
|
<p>Four of these are the common opcodes for events :</p>
|
|
|
|
<table border="1">
|
|
<tr>
|
|
<th>Ops Code Name<br>
|
|
( MERG console log )</th>
|
|
<th>Decimal<br>
|
|
opcode</th>
|
|
<th>Hexadecimal<br>
|
|
opcode</th>
|
|
<th>
|
|
</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>ASON</td>
|
|
<td>152</td>
|
|
<td>98</td>
|
|
<td>Short Event On</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>ASOF</td>
|
|
<td>153</td>
|
|
<td>99</td>
|
|
<td>Short Event Off</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>ACON</td>
|
|
<td>144</td>
|
|
<td>90</td>
|
|
<td>Long Event On</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>ACOF</td>
|
|
<td>145</td>
|
|
<td>91</td>
|
|
<td>Long Event Off</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>It's possible to connect a Sensor to arbitrary CAN frames by specifying their data
|
|
content as a hex string, indicated by "X".</p>
|
|
|
|
<p>This allows a Sensor or Turnout to disregard any intrinsic meaning to "ON" and "OFF"
|
|
events, and allows it to respond to, or emit any frame on the layout.</p>
|
|
|
|
<p>These particular event opcodes use a Hex string 4 digits long, split into High then Low
|
|
:</p>
|
|
<img src="images/web/merg-add-turnout-hex-620x147.png" class="floatRight" alt=
|
|
"merg cbus add new turnout hexadecimal hex" width="620" height="147">
|
|
<table border="1">
|
|
<tr>
|
|
<th>Entered as Hex</th>
|
|
<th>Ops Code</th>
|
|
<th>Remaining Hex</th>
|
|
<th>Node Decimal</th>
|
|
<th>Event Decimal</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><code>X9900000013</code>
|
|
</td>
|
|
<td>ASOF</td>
|
|
<td><code>00 00 00 13</code>
|
|
</td>
|
|
<td>0</td>
|
|
<td>19</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><code>X980000002D</code>
|
|
</td>
|
|
<td>ASON</td>
|
|
<td><code>00 00 00 2D</code>
|
|
</td>
|
|
<td>0</td>
|
|
<td>45</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><code>X980000BD2A</code>
|
|
</td>
|
|
<td>ASON</td>
|
|
<td><code>00 00 BD 2A</code>
|
|
</td>
|
|
<td>0</td>
|
|
<td>48426</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><code>X990000FFFF</code>
|
|
</td>
|
|
<td>ASOF</td>
|
|
<td><code>00 00 FF FF</code>
|
|
</td>
|
|
<td>0</td>
|
|
<td>65535</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><code>X9100130013</code>
|
|
</td>
|
|
<td>ACOF</td>
|
|
<td><code>00 14 00 13</code>
|
|
</td>
|
|
<td>20</td>
|
|
<td>19</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><code>X90002D002E</code>
|
|
</td>
|
|
<td>ACON</td>
|
|
<td><code>00 2D 00 2E</code>
|
|
</td>
|
|
<td>45</td>
|
|
<td>46</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><code>X90BD2BBD2A</code>
|
|
</td>
|
|
<td>ACON</td>
|
|
<td><code>BD 2B BD 2A</code>
|
|
</td>
|
|
<td>48427</td>
|
|
<td>48426</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><code>X91FFFFFFFE</code>
|
|
</td>
|
|
<td>ACOF</td>
|
|
<td><code>FF FF FF FE</code>
|
|
</td>
|
|
<td>65535</td>
|
|
<td>65534</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>Ensure you use the right opscode, eg if you include Nodes for a FiLM address, use ACON
|
|
instead of ASON.</p>
|
|
|
|
<p>Sensors, Turnouts and Lights stored as Hex response events using the long and short
|
|
response OPCs will not be recognised as these are translated to standard on and off events
|
|
just before the ( sensor turnout or light ) internal message match check.<br>
|
|
Apart from these specific OPCs, Sensors Turnouts or Lights can store any hex combination,
|
|
they need both an on and off side seperated by a ";".</p>
|
|
|
|
<p>The CAN frames can send CBUS opcodes in the hex form of the code you require.<br>
|
|
eg, to set up a sensor to send ( DCC emergency stop / Track power on ) opcodes over
|
|
CBUS,<br>
|
|
you could use a hardware address of <code>X0A;X05</code></p>
|
|
|
|
<table border="1">
|
|
<tr>
|
|
<th>Entered as Hex</th>
|
|
<th>Viewed in JMRI MERG CONSOLE</th>
|
|
<th>Viewed in CBUS SERVER</th>
|
|
<th>Ops Code</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><code>X0A</code>
|
|
</td>
|
|
<td><code>[x[7f]0A]</code>
|
|
</td>
|
|
<td><code>S0FE0N0A;</code>
|
|
</td>
|
|
<td>(RESTP) Request Emergency Stop ALL trains<br>
|
|
A CBUS command station confirms request with an ESTOP 06 opcode.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><code>X05</code>
|
|
</td>
|
|
<td><code>[x[7f]05]</code>
|
|
</td>
|
|
<td><code>S0FE0N05;</code>
|
|
</td>
|
|
<td>(TON) Track Power On, normally broadcast from a command station</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>All of these opcode messages are sent with the Standard CAN event frame, however the
|
|
protocol also allows for access to extended CAN frames.<br>
|
|
These frames enable bootloading of modules ( firmware updates ), while future uses of this
|
|
may also be for local media streaming ( eg. transferring pictures of trains or sound files
|
|
between modules. )<br>
|
|
The extended frames do not interfere with the standard frames, hence modules can be
|
|
targetted for boatloading by module number, without affecting normal layout messaging.</p>
|
|
|
|
<p>Extended CAN frames ( which are not CBUS messages ) can be monitored in the <a href=
|
|
"../../../../package/jmri/jmrix/can/cbus/swing/console/CbusConsoleFrame.shtml">CBUS
|
|
console</a>, and are filtered from all other JMRI objects ( Sensors, Turnouts etc. ).</p>
|
|
|
|
<p>Module firmware updates are supported by the <a href=
|
|
"../../../../package/jmri/jmrix/can/cbus/swing/bootloader/CbusBootloaderPane.shtml">CBUS
|
|
bootloader</a> and by 3rd party software (FCU - FLiM Configuration Utility), available free
|
|
for MERG members to download.</p>
|
|
|
|
<p>For advanced system development and packet proving, you may prefer to view the full
|
|
packet across various applications, eg CBUS SERVER.</p>
|
|
<img src="images/web/merg-cbus-server-400x256.png" width="400" height="256" alt=
|
|
"merg cbus server" class="floatRight">
|
|
<p>The <a href=
|
|
"../../../../package/jmri/jmrix/can/cbus/swing/console/CbusConsoleFrame.shtml">JMRI CBUS
|
|
Console Tool</a> can be very useful in seeing what is being sent across the network by the
|
|
hardware addresses you create.<br>
|
|
The console is intended to be a tool to help users monitor packets using short and long
|
|
events, and may attempt to beautify the output.</p>
|
|
|
|
<p>Check the CBUS wiki and developers guide for more info and absolute specification.</p>
|
|
</div>
|
|
|
|
<h2 id="opc">JMRI Supported Operation Codes (Opcodes)</h2>
|
|
|
|
<div>
|
|
<p>The majority of opcodes according to the CBUS developers guide 6b are supported in some
|
|
sort of form.</p>
|
|
|
|
<p>All outgoing JMRI CBUS messages have their OPC priority added to the header section of
|
|
the message.</p>
|
|
|
|
<p>Many JMRI functions utilise the OPC support within :</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusOpCodes.java">
|
|
CbusOpCodes.java</a> <a href=
|
|
"https://www.jmri.org/JavaDoc/doc/jmri/jmrix/can/cbus/CbusOpCodes.html">JavaDoc</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusConstants.java">
|
|
CbusConstants.java</a> <a href=
|
|
"https://www.jmri.org/JavaDoc/doc/jmri/jmrix/can/cbus/CbusConstants.html">JavaDoc</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusMessage.java">
|
|
CbusMessage.java</a> <a href=
|
|
"https://www.jmri.org/JavaDoc/doc/jmri/jmrix/can/cbus/CbusMessage.html">JavaDoc</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusBundle.properties">
|
|
CbusBundle.properties</a> for English text translations of OPCs.
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
<h4>Opcodes used in JMRI CBUS Tools</h4>
|
|
|
|
<p>There's a list of supported OPCs for each JMRI CBUS tool support page.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<a href=
|
|
"../../../../package/jmri/jmrix/can/cbus/swing/eventtable/EventTablePane.shtml#opc">Event
|
|
Table</a> - Mainly event OPCs
|
|
</li>
|
|
|
|
<li>
|
|
<a href=
|
|
"../../../../package/jmri/jmrix/can/cbus/swing/nodeconfig/NodeConfigToolPane.shtml#opc">
|
|
Node Config</a> - Node Management OPCs
|
|
</li>
|
|
|
|
<li>
|
|
<a href=
|
|
"../../../../package/jmri/jmrix/can/cbus/swing/cbusslotmonitor/CbusSlotMonitorPane.shtml#opc">
|
|
Command Station Monitor</a> - Command Station Monitor OPCs
|
|
</li>
|
|
|
|
<li>
|
|
<a href=
|
|
"../../../../package/jmri/jmrix/can/cbus/swing/console/CbusConsoleFrame.shtml#opc">Console</a>
|
|
- All OPCs
|
|
</li>
|
|
|
|
<li>
|
|
<a href=
|
|
"../../../../package/jmri/jmrix/can/cbus/swing/simulator/SimulatorPane.shtml#opc">Simulator</a>
|
|
- Most OPCs
|
|
</li>
|
|
|
|
<li>
|
|
<a href=
|
|
"../../../../package/jmri/jmrix/can/cbus/swing/eventrequestmonitor/CbusEventRequestTablePane.shtml#opc">
|
|
Event Request Monitor</a> - Mainly event OPCs
|
|
</li>
|
|
</ul>
|
|
|
|
<h4>Sensor, Turnout and Light OPCs</h4>
|
|
|
|
<p><a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusSensor.java">CbusSensor.java</a>
|
|
<a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusSensorManager.java">
|
|
CbusSensorManager.java</a></p>
|
|
|
|
<p><a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusTurnout.java">CbusTurnout.java</a>
|
|
<a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusTurnoutManager.java">
|
|
CbusTurnoutManager.java</a></p>
|
|
|
|
<p><a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusLight.java">CbusLight.java</a>
|
|
<a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusLightManager.java">
|
|
CbusLightManager.java</a></p>
|
|
|
|
<p>The flexibility in the hex form of creating Sensors, Turnouts and Lights allows any OPC
|
|
to be sent, or received as an input.</p>
|
|
|
|
<p>When used as a short form address, eg "+N123E456" :</p>
|
|
|
|
<ul>
|
|
<li>ASON / ASOF Sent when status changed, node number = 0</li>
|
|
|
|
<li>ACON / ACOF Sent when status changed, node number > 0</li>
|
|
</ul>
|
|
|
|
<ul>
|
|
<li>ASON / ASOF Constant listener</li>
|
|
|
|
<li>ACON / ACOF Constant listener</li>
|
|
|
|
<li>ARON / AROF Constant listener</li>
|
|
|
|
<li>ARSON / ARSOF Constant listener</li>
|
|
</ul>
|
|
|
|
<p>This does not currently include the extended data event OPC's.</p>
|
|
|
|
<h4>Reporter OPCs</h4>
|
|
|
|
<p><a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusReporter.java">CbusReporter.java</a>
|
|
<a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusReporterManager.java">
|
|
CbusReporterManager.java</a></p>
|
|
|
|
<p>Messages sent from, and received by JMRI are handled the same by CBUS Reporters.</p>
|
|
|
|
<ul>
|
|
<li>DDES - Constant Listener</li>
|
|
|
|
<li>DDRS - Constant Listener</li>
|
|
|
|
<li>ACDAT - Constant Listener</li>
|
|
|
|
<li>ARDAT - Constant Listener</li>
|
|
</ul>
|
|
|
|
<h4>Command Station OPCs</h4>
|
|
|
|
<p><a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusCommandStation.java">
|
|
CbusCommandStation.java</a>
|
|
</p>
|
|
|
|
<ul>
|
|
<li>RDCC3 - Sent Message</li>
|
|
|
|
<li>KLOC - Sent Message</li>
|
|
|
|
<li>DKEEP - Sent Message</li>
|
|
|
|
<li>DSPD - Sent Message</li>
|
|
|
|
<li>DFUN - Sent Message</li>
|
|
|
|
<li>STMOD - Sent Message</li>
|
|
</ul>
|
|
|
|
<p><a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusDccOpsModeProgrammer.java">
|
|
CbusDccOpsModeProgrammer.java</a>
|
|
</p>
|
|
|
|
<ul>
|
|
<li>WCVOA - Sent Message</li>
|
|
</ul>
|
|
|
|
<p><a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusDccProgrammer.java">
|
|
CbusDccProgrammer.java</a>
|
|
</p>
|
|
|
|
<ul>
|
|
<li>WCVS - Sent Message</li>
|
|
|
|
<li>QCVS - Sent Message</li>
|
|
</ul>
|
|
|
|
<p>Received by JMRI when in internal programming state</p>
|
|
|
|
<ul>
|
|
<li>SSTAT</li>
|
|
|
|
<li>PCVS</li>
|
|
</ul>
|
|
|
|
<p><a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusPowerManager.java">
|
|
CbusPowerManager.java</a>
|
|
</p>
|
|
|
|
<ul>
|
|
<li>RTON - Sent Message</li>
|
|
|
|
<li>RTOF - Sent Message</li>
|
|
</ul>
|
|
|
|
<p>Received by JMRI</p>
|
|
|
|
<ul>
|
|
<li>TON - Constant Listener</li>
|
|
|
|
<li>TOF - Constant Listener</li>
|
|
|
|
<li>ARST - Constant Listener</li>
|
|
</ul>
|
|
|
|
<p><a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusThrottle.java">CbusThrottle.java</a>
|
|
<a href=
|
|
"https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusThrottleManager.java">
|
|
CbusThrottleManager.java</a></p>
|
|
|
|
<p>Messages sent by JMRI</p>
|
|
|
|
<ul>
|
|
<li>RLOC - Sent by JMRI</li>
|
|
</ul>
|
|
|
|
<p>Listeners for messages sent by JMRI</p>
|
|
|
|
<ul>
|
|
<li>ESTOP - Constant Listener</li>
|
|
|
|
<li>RESTP - Constant Listener</li>
|
|
|
|
<li>KLOC - Constant Listener</li>
|
|
</ul>
|
|
|
|
<p>Listeners for messages received by JMRI</p>
|
|
|
|
<ul>
|
|
<li>PLOC - Constant Listener</li>
|
|
|
|
<li>ERR - Constant Listener + Errors translated from error codes</li>
|
|
|
|
<li>DSPD - Constant Listener</li>
|
|
|
|
<li>DFUN - Constant Listener</li>
|
|
|
|
<li>DFNON - Constant Listener</li>
|
|
|
|
<li>DFNOF - Constant Listener</li>
|
|
|
|
<li>ESTOP - Constant Listener</li>
|
|
|
|
<li>RESTP - Constant Listener</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<h2>JMRI Help</h2>
|
|
|
|
<div>
|
|
<p><a href="index.shtml">Main JMRI CBUS Support page</a>.</p>
|
|
|
|
<p><a href="../scripting.shtml">JMRI Scripting</a> for CAN frames with CanExample.py</p>
|
|
|
|
<p><a href="index.shtml#thirdparty">CBUS 3rd Party Links</a> See link for the CBUS
|
|
Developers Guide</p>
|
|
</div>
|
|
|
|
<p>CBUS® is a registered trade mark of Dr Michael Bolton</p>
|
|
<!--#include virtual="/help/en/parts/Footer.shtml" -->
|
|
</div>
|
|
<!-- closes #mainContent-->
|
|
</div>
|
|
<!-- closes #mBody-->
|
|
<script src="/js/help.js"></script>
|
|
</body>
|
|
</html>
|