easylinux/JIMRI
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
e7a7593712ebf619e6fdc2d0676c9fd73f1de66c
JIMRI/help/en/html/hardware/can/cbus/Names.shtml
T
Serge NOEL efdf1683af Initialisation depot
2026-06-17 14:00:51 +02:00

952 lines
34 KiB
Plaintext
Raw Blame History

<!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&reg; - 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 &gt; 1,999 Module 2 would have 2,000 &gt; 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 &gt; 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&reg; 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>
Reference in New Issue View Git Blame Copy Permalink