-
Notifications
You must be signed in to change notification settings - Fork 331
/
Names.shtml
839 lines (697 loc) · 32.9 KB
/
Names.shtml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<meta name="generator" content=
"HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 15.17), see www.w3.org">
<meta name="keywords" content="JMRI help MERG CBUS naming long short events event add sensor hex">
<title>JMRI Hardware Support - MERG CBUS - Naming</title>
<!-- Style -->
<meta http-equiv="Content-Type" content=
"text/html; charset=us-ascii">
<link rel="stylesheet" type="text/css" href="/css/default.css"
media="screen">
<link rel="stylesheet" type="text/css" href="/css/print.css"
media="print">
<link rel="icon" href="/images/jmri.ico" type="image/png">
<link rel="home" title="Home" href="/">
<!-- /Style -->
</head>
<body>
<!--#include virtual="/Header.shtml" -->
<div id="mBody">
<!--#include virtual="Sidebar.shtml" -->
<div id="mainContent">
<h1>JMRI Hardware Support: MERG CBUS - Naming</h1>
<ul class="snav">
<li><a href="#events">Event Name and Numbering</a></li>
<li><a href="#reporters">Reporters</a></li>
<li><a href="#sysname">System Names</a></li>
<li><a href="#summary">Summary of MERG 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">MERG 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
MERG CBUS-attached resources.</p>
<h2><a name="events" id="events">Event Name and Numbering</a></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><a name="automatic" id="automatic">Sensors - JMRI Automatic Creation</a></h4>
<p>JMRI DOES NOT attempt to create Sensor objects from
the traffic that it hears on the MERG CBUS network,
unlike some other hardware systems.</p>
<p>This is because MERG 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><a name="turnout" id="turnout">Turnout Operation</a></h4>
<p>MERG 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>
<ul>
<li>Direct - When the commanded state is changed,
the feedback state will reflect the commanded state.</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. </p>
<p>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>
<h4><a name="reporters" id="reporters">Reporter ( incl. RFID ) data from CBUS</a></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><a name="sysname" id="sysname">System Names</a></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 MERG 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 MERG 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><a name="summary" id="summary">Summary of MERG CBUS events ( Sensors, Turnouts and Lights )</a></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 Opscode</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><a name="namingspec" id="namingspec">Event Naming Specification</a></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 MERG 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 MERG 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>MERG 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 MERG 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. MERG CBUS
short events, where parts of the packet include the node
number which should (usually) be ignored.</p>
</div>
<h2><a name="hex" id="hex">Sending hex strings</a></h2>
<div>
<p>Hexadcimal numbering is based on the power of 16, using 0-9, then A-F.</p>
<p>MERG 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 MERG CBUS network in the form of an Opscode, the command information.</p>
<p>There are 255 ops codes, the length of the data string following the Opscode changes depending on which Opscode is used.</p>
<p>There are multiple Opscodes 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 Opscodes for events :</p>
<table border="1">
<tr>
<th>Ops Code Name
<br>( MERG console log ) </th>
<th>Decimal
<br>Opscode</th>
<th>Hexadecimal
<br>Opscode</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 Opscodes use a Hex string 4 digits long, split into High then Low :</p>
<img src="images/web/merg-add-turnout-hex-620x147.png" align="right"
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 MERG CBUS opscodes in the hex form of the code you require.
<br>
eg, to set up a sensor to send ( DCC emergency stop / Track power on ) opscodes over MERG 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 MERG CANCMD confirms request with an ESTOP 06 Opscode.</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 Opscode 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>Although module firmware updates are not currently available within JMRI,
full support for this is available via 3rd party software ( FCU - FLiM Configuration Utility ),
available free for MERG members to download.
</p>
<img src="images/web/merg-cbus-server-400x256.png"
width="400" height="256" alt="merg cbus server" align="right">
<p>For advanced system development and packet proving, you may prefer to view the
full packet across various applications, eg MERG CBUS SERVER.</p>
<p>The <a href="../../../../package/jmri/jmrix/can/cbus/swing/console/CbusConsoleFrame.shtml"
>JMRI MERG 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 MERG CBUS wiki and developers guide for more info and absolute specification.</p>
</div>
<h2><a name="opc" id="opc">JMRI Supported Operation Codes</a></h2>
<div>
<p>The majority of Opscodes according to the MERG CBUS developers guide 6b are supported in some sort of form.</p>
<p>All outgoing JMRI MERG 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://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://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://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>
<li><a href="https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrix/can/cbus/CbusProgrammer.java"
>CbusProgrammer.java</a>
<a href="https://jmri.org/JavaDoc/doc/jmri/jmrix/can/cbus/CbusProgrammer.html"
>JavaDoc</a>
Functions for dealing with Node programming ( Node Config Tool functions to be moved here )
</li>
</ul>
<h4>Opscodes used in JMRI MERG CBUS Tools</h4>
<p>There's a list of supported OPCs for each JMRI MERG 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 MERG 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 MERG 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">MERG CBUS 3rd Party Links</a> See link for the MERG CBUS Developers Guide</p>
</div>
<!--#include virtual="/Footer.shtml" -->
</div><!-- closes #mainContent-->
</div><!-- closes #mBody-->
</body>
</html>