/
Digitrax.shtml
1364 lines (1177 loc) · 69.7 KB
/
Digitrax.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
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.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">
<title>JMRI Hardware Support - Digitrax LocoNet</title>
<meta name="keywords" content=
"Digitrax LocoNet LocoBuffer LocoBuffer-II LocoBuffer-USB MS100 PR2 PR3 PR4 DCS210 DCS240 DCS100 DCS240 DCS50 DCS51 DB150 JMRI">
<!-- 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>Support: Digitrax LocoNet®</h1>
<div class="toc">
<ul>
<li>
<a href="#LocoNetConnect">Supported Hardware</a>
<ul>
<li><a href="#Programmer">PR2, PR3, and PR4 acting as Decoder Programmers</a></li>
</ul>
</li>
<li><a href="#Limitation">Hardware Interface and Command Station Limitations</a></li>
<li>
<a href="#Setup">Connecting</a>
<ul>
<li><a href="#Using">Using JMRI with
LocoNet®</a>
<ul>
<li><a href="#LocoNetAddressing">LocoNet Device Addressing</a></li>
<li><a href="#LocoNetTools">LocoNet Tools</a></li>
</ul>
</li>
<li><a href="#Network">Networked Computers and
LocoNet®</a></li>
</ul>
</li>
<li>
<a href="#Debugging">Debugging</a>
<ul>
<li><a href="#ErraticReadback">Erratic or
Non-Functioning CV Readback</a></li>
<li>
<a href="#TurnoutCmdHandling">Command Station
Turnout Command Rejection and JMRI Turnout Command
Handling</a>
<ul>
<li><a href="#turncmdhandsettings">Turnout
Command Handling Settings</a></li>
<li><a href="#alternatives">Command Station Turnout Command
Rejection Avoidance Strategies</a></li>
<li><a href="#cmdStationTrkPwrOff">Turnout
command rejection when track power is
off</a></li>
<li><a href="#multConnTurnoutReject">Turnout
command rejection and multiple active LocoNet
connections</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#SeeAlso">JMRI information and tools for LocoNet-specific hardware and features</a>
<ul>
<li><a href="#devicetoolhelp">JMRI LocoNet-specific Help pages</a>
<li><a href="#loconetRoster">Configuring some LocoNet devices via "Roster" entries</a></li>
<li><a href="#deviceBoardId">Programming Board ID (Board Address) for some Digitrax devices</a></li>
<li><a href="#devicetoollimits">Some JMRI LocoNet-specific device and feature limitations</a></li>
</ul></li>
<li><a href="#Support">Support</a></li>
</ul>
</div><a name="LocoNetConnect" id=
"LocoNetConnect"></a><a name="hardware" id="hardware"></a>
<h2>Supported Hardware</h2>
<p>JMRI software, including DecoderPro and PanelPro, works
with your Digitrax command station to program decoders. To do
this, it communicates with the command station over the
LocoNet® using one of several types of <a href=
"#adapters">adapter</a>.</p>
<h3>Command Stations</h3>
<p>JMRI software supports the following LocoNet-based command
stations:</p>
<ul>
<li>Zephyr Starter Set</li>
<li>Zephyr Xtra Starter Set</li>
<li>Super Empire Builder Set</li>
<li>Chief Starter Set</li>
<li>Super Chief Set</li>
<li>Super Chief Xtra Set</li>
<li>DCS50 Command Station/Booster/Throttle</li>
<li>DCS51 Command Station/Booster/Throttle</li>
<li>DCS52 Command Station/Booster/Throttle</li>
<li>DB150 Command Station/Booster</li>
<li>DCS100 Command Station/Booster</li>
<li>DCS200 Command Station/Booster</li>
<li>DCS240 Advanced Command Station/Booster</li>
<li><a href="Uhlenbrock.shtml">Intellibox: The Uhlenbrock
Central Unit</a></li>
<li><a href="Uhlenbrock.shtml">Intellibox II or
IB-Com</a></li>
<li>DCC-Mux: DCC data combiner with built-in LocoNet
command station</li>
</ul>
<p>For systems which do not provide a real LocoNet Command
Station, two additional options are supported. When a layout
uses LocoNet peripheral devices but not a LocoNet-based
command station, a "<a href="StandaloneLocoNet.shtml">Standalone
LocoNet</a>" is used.<br>
In addition, JMRI software may be configured to use a simulated
LocoNet connection instead of a real LocoNet connection. This
is the "<a href="LocoNetSim.shtml">LocoNet® Simulator</a>".</p>
<a name="adapters" id="adapters"></a>
<h3>Computer Interfaces</h3>
<p>To connect your computer to the LocoNet, and hence to the
command station, you need one of the following adapters:</p>
<ul>
<li><a title="RR-CirKits USB interface" href=
"LocoBufferUSB.shtml">LocoBuffer-USB</a></li>
<li><a title="Digitrax PR3 and PR3 Xtra USB interface" href=
"PR3.shtml">PR3, PR3 Xtra</a></li>
<li><a title="Digitrax PR4 USB interface" href=
"PR4.shtml">PR4</a></li>
<li><a title="RR-CirKits Serial interface" href=
"LocoBufferII.shtml">LocoBuffer II</a></li>
<li><a title="Original Kit Version" href=
"LocoBuffer.shtml">LocoBuffer</a></li>
<li><a title="Digitrax Serial interface" href=
"MS100.shtml">MS-100</a></li>
<li><a title="BT LocoBridge" href=
"BTLocoBridge.shtml">Bluetooth LocoBridge</a></li>
</ul>
<p>(Note: The Digitrax DSC240 has a built-in adapter that's
similar to the Digitrax PR3; if you have a DCS240 and connect
the computer via the DCS240's integrated USB interface, see
<a href="DCS240.shtml">this DCS240 page</a>. Similarly, the Digitrax
DSC52 has a built-in adapter that's similar to the Digitrax PR3; if you
have a DCS52 and connect the computer via the DCS52's integrated USB
interface, see <a href="DCS52.shtml">this DCS52 page</a>.</p>
<p>Generally, any of these can be used with any type of
computer to communicate with any type of command station.
Currently, the LocoBuffer-USB , PR3, and PR4 are the recommended
computer interface solutions. The LocoBuffer II and original
LocoBuffer are no longer commercially available; their
primary advantage now is that they use a traditional serial
port, which may be the only suitable connection type
available on some older computers.</p>
<p>The MS100 is <em>not</em> recommended; it sometimes fails to
provide reliable communications, and it cannot be used with
JMRI if you are using Mac OS X or on most Windows Vista
machines. If you have problems with the MS100, you might not
be able to fix them, and nobody may be able to help you.</p>
<p>The Uhlenbrock Intellibox command stations can also be
controlled directly through it's serial port or USB
connection; there's a <a href="Uhlenbrock.shtml">separate
page</a> on how to do this.</p>
<h4><a name="Programmer" id="Programmer">PR2, PR3, and PR4 acting as Decoder
Programmers</a></h4>JMRI can also use a <a title=
"Digitrax programmer" href="PR2.shtml">Digitrax PR2</a>, the
<a title="Digitrax Programmer/USB interface" href=
"PR3.shtml">Digitrax PR3</a>, or the <a title="PR4.shtml">Digitrax PR4</a>
to program and test decoders. The PR2 is
a stand-alone decoder programming unit which does not connect
to the rest of the layout, the command station, nor to a
LocoNet. For more information on using a PR2 with DecoderPro,
please see the <a href="PR2.shtml">PR2 setup page</a>. The
PR3 and PR4 devices can be configured in JMRI to operate as either a stand-
alone programmer, or as an interface to to a LocoNet. There
is more information on the <a href="PR3.shtml">PR3 setup
page</a> and the <a href="PR4.shtml">PR4 setup page</a>.
<h2><a name="Limitation" id="Limitation">Hardware Interface and Command Station Limitations</a></h2>
<p><strong>Uhlenbrock Intellibox</strong> - The Intellibox has two
LocoNet connections, called LocoNet-T and LocoNet-B. The
LocoNet-T connection can drive more devices, but does not
provide the Rail-Synch signals that some LocoNet devices
(particularly boosters and the BDL16, BDL162 and BDL168)
require. A LocoBuffer should be connected to the LocoNet-T
connection.</p>
<p><strong>Uhlenbrock Intellibox II and IB-Com</strong> - The
Intellibox II and IB-Com have two LocoNet connections, called
LocoNet-T and LocoNet-B. The LocoNet-T connection can drive
more devices, but does not provide the Rail-Synch signals
that some LocoNet devices (particularly boosters and the
BDL16, BDL162 and BDL168) require. A LocoBuffer should be
connected to the LocoNet-T connection.</p>
<p><strong>PR-1 not supported</strong> - Note that DecoderPro
cannot directly program decoders via a PR1 programmer. JMRI
supports decoder programming either via the PR3 as a
stand-alone programmer or via a command station.</p>
<p><strong>Mac OS X and the MS100</strong> - Because Mac OS X can't
communicate at the special baud rate used by the MS100, the
MS100 won't work with Mac OS X. You should get a
LocoBuffer-USB instead.</p>
<p><strong>Microsoft Vista and the MS100</strong> - It has been
reported that Vista does not support the special baud rate
used by the MS100. If you find that your MS100 does not work
on your Vista machine you should get a LocoBuffer-USB, PR3, or PR4
instead.</p><a name="Setup" id="Setup"></a>
<h2><a name="ConnectingAdapter" id="ConnectingAdapter">Connecting</a></h2>
<p>To connect your computer to a Digitrax DCC system, you
need either a USB-equipped Command station (DCS240 or DCS52),
or a computer-to-LocoNet
adapter device such as a <a title="RR-CirKits USB interface" href=
"LocoBufferUSB.shtml">LocoBuffer-USB</a>, <a title=
"Digitrax PR3 USB interface" href="PR3.shtml">PR3</a>, <a title=
"Digitrax PR4 USB interface" href="PR4.shtml">PR4</a>, <a title=
"RR-CirKits Serial interface" href=
"LocoBufferII.shtml">LocoBuffer-II</a>, <a title=
"Original Kit Version" href="LocoBuffer.shtml">LocoBuffer</a>
or <a title="Digitrax Serial interface" href=
"MS100.shtml">MS100</a>. The LocoBuffer-USB is a highly
recommended computer-to-LocoNet adapter. See <a href="#adapters">below</a> for more on
adapters.</p>
<p>Note that except for the PR3 and PR4, these are only LocoNet
interfaces, not stand alone programmers like the Digitrax PR2.
The Digitrax PR3 and PR4 devices may act either as a standalone
programmer or as a LocoNet interface. Readback of decoder CVs
is possible when using a programming track controlled by a PR3 or PR4
(in stand-alone programming mode) or when using a programming track
controlled by a Chief, Zephyr, Advanced (DCS210) or Evolution (DCS240)
command station. The Empire Builder (DB150) command station does not allow
Readback of decoder CVs; users of the Empire Builder can add CV Readback
capability by using a programming track connected to a PR3 or PR4 when
operating in stand-alone programming mode.</p>
<h3>Basic steps to connect to LocoNet</h3>
<p>If connecting to a DCS240 command station via its integrated USB port,
see these instructions for configuring JMRI for <a href="DCS240.shtml#ConnectingDCS240">
the DCS240</a>.</p>
<p>If connecting to a DCS52 command station via its integrated USB port,
see these instructions for configuring JMRI for <a href="DCS52.shtml#ConnectingDCS52">
the DCS52</a>.</p>
<p>The steps below show how to add a connection to JMRI
(DecoderPro, PanelPro, etc.) for a LocoNet-based system.</p>
<ol>
<li>If using a LocoNet adapter, connect your adapter to the LocoNet, and connect your
computer to it with the appropriate serial or USB
cable.</li>
<li>If using a command station's USB connection, connect your computer to
your command station with the appropriate USB cable.</li>
<li>Mac and Windows users should install the proper USB
drivers if they are using USB devices.</li>
<li>Linux and Mac users should be sure that the correct
Java communications packages have been installed.</li>
<li>Open a JMRI program and go to the "Preferences" panel.
This normally opens automatically the first time each
program is run, or you can select it from the "Edit"
menu. Alternately, if you already have two or more connections
established and at start-up you get a selection box for the connection
profiles, you may choose to establish a new connection profile and the
"Connections" window will automatically open (so you may skip the next
step).</li>
<li>Select the "Connections" item in the window at the
left.</li>
<li>Select "Digitrax" in the "System Manufacturer" box.</li>
<li>Select the appropriate adapter type (or command station type, if using
a computer-to-command station USB port connection) in the "System
Connection" box.</li>
<li>You can then configure the proper settings in the
"Settings" box. The "Serial Port" must be properly selected
and the connection settings properly configured in order
for JMRI to talk to the adapter hardware. On some systems
with some system connection adapter types, the "Serial
Port" setting will be automatically selected. In other
cases the first possible "Serial Port" connection will be
selected by default. It may be necessary to use tools
provided with the computer operating system to determine
which "Serial Port" is appropriate for your particular
situation.</li>
<li>Select the appropriate "Command Station Type":
<p>When the "Connection Type" is set for the PR3 or PR4, the
"Command Station Type" can be set to "PRx in stand-alone
programming mode" or set to one of the command station
types. When set for stand-alone programming, the PR3/PR4 will
not communicate with LocoNet. When set for a specific
command station type, the PR3/PR4 programming track is not
used; instead, decoder programming is done through the
mechanisms provided by the selected command station, and its
programming track connections.</p>
<p>When "DB150 (Empire Builder)" is selected, JMRI
decoder programming is done via the DB150 programming
mechanisms. The DB150 is not capable of reading decoder
CV values, so JMRI will not be able to read decoder CV
values via the DB150 programming mechanisms. Empire
Builder users can use a PR3/PR4 in stand-alone programmer
mode, instead of the Empire Builder programming track, to
allow decoder CV readback. Some users configure
DecoderPro for programming decoders using the PR3/PR4 in
stand-alone programming mode, and then configure PanelPro
to use the PR3/PR4 in LocoNet interface mode (also called
"MS100 mode") to allow PanelPro to communicate with the
Empire Builder command station and LocoNet-connected
peripherals. More PR3 setup information can be found on
the <a href="PR3.shtml">PR3 setup page</a>. More PR4 setup
information can be found on the <a href="PR4.shtml">PR4
setup page</a>.</p>
</li>
<li>The "Connection Prefix" is used to help JMRI
communicate separately with multiple "connections" to
layout hardware. Each "connection" must have a unique
identifier, which is specified as the "Connection Prefix".
By default, the first LocoNet connection is given a prefix
of "L", and additional LocoNet are given prefixes like
"L1", "L2", ... Most users should be able to use the
default "Connection Prefix" value provided by the JMRI
tools.
<br>
It is recommended that all connections for LocoNet
hardware use a prefix that begins with "L", as other
characters are normally associated with other hardware
connection types.
</li>
<li>When a JMRI tool is configured for more than one
connection, each connection gets a menu item on the main
JMRI tool window. To help users differentiate between their
different connections, each connection has a "Connection
Name", which is used as the name of the associated menu
item on the main JMRI tool window. Users may change the
"Connection Name" for any connection to suit their
needs.</li>
<li>Some adapters may have addition configuration options,
which appear by checking the "Additional Connection
Settings". This may show additional settings applicable for
some adapter types. These include, but are not limited to,
the options listed here.
<br>
<img src="images/LoconetAdditionalSettings.png" alt="Connection Settings Additional settings"
width="515" height="219">
<ul>
<li>The "Baud rate" setting. When multiple settings are
available, this must be set to match the needs of the
particular hardware adapter specified in the "System
Connection" setting. This setting will be pre-set and
unchangeable you have selected a LocoBuffer-USB, PR3, PR4,
or MS100 "System Connection". There are two speed
choices for the LocoBuffer and LocoBuffer-II; select
the one that corresponds to the jumper settings on your
LocoBuffer unit. We recommend that you start with the
19,200 choice for the LocoBuffer or LocoBuffer-II; see
the <a href="LocoBufferII.shtml">LocoBuffer-II</a> and
<a href="LocoBuffer.shtml">LocoBuffer</a> pages for
more information.</li>
<li>The "(Serial) Connection Uses" selection determines how
"flow control" is implemented in software. This
selection should be configured for "hardware flow
control" unless you later consistently get a JMRI
console message about the LocoBuffer control leads
being improperly set up, in which case you might want
to try to bypass that by selecting "no flow control".<br>
This box will be blank if you've selected
LocoBuffer-USB, PR3, PR4 or MS100.</li>
<li>Packetizer Type lets you choose Normal (recommended) or Strict.</li>
<li>"Transponding Present" allows you indicate whether
certain special hardware is present and configured.
If you have LocoNet-attached boards that configure
in "ops mode", or if you have Digitrax Transponding
installed, set this to "Yes". Otherwise, set it to
"No". </li>
<li>The <a href="#TurnoutCmdHandling">"Command Station
Turnout Command Rejection and JMRI Turnout Command
Handling"</a> settings are described <a href="#TurnoutCmdHandling">below</a>.
</li>
<li>Output Interval sets a configurable (minimum) interval for all turnout outputs
that are part of a Route or Output Matrix Signal Mast on this same connection.<br>
Use the [Reset] button to restore the default of 250 ms.
No restart is required after a change.</li>
</ul>
</li>
<li>Click "Save". You'll be asked if it's OK for the
program to quit, click "Yes".</li>
<li style="text-align:left;">Restart JMRI. You should be up
and running.<br></li>
</ol>
<p>If you are going to control Turnouts, Signals or other
devices on your layout from JMRI or another program, we
recommend that you disable, where available, the command
station's "Meter route/switch output when not in trinary"
feature. When enabled, this option greatly reduces the number of
commands the LocoNet can handle each second, which can cause
significant delays when you're controlling signals, etc. To
disable it, you can use the "Configure Command Station" tool
in the <strong>LocoNet</strong> menu, or the Roster-based mechanism, or
the throttle-based programming mechanisms as described in the
manual for your command station. The command station may not
immediately accept OpSw setting changes, so it may be necessary
to "power-cycle" the command station, or to "put the command
station to sleep" via the command station front-panel switch.</p>
<p>Note that some command stations disable metering (i.e.
provide faster turnout command handling) when OpSw31="t" and
others when OpSw31="c". Here's a list of command stations
and the OpSw31 setting which will speed-up command station
turnout command handling:</p>
<ul>
<li>DCS100/DCS200 - OpSw31="t" for faster turnout command handling
(i.e. disables metering)</li>
<li>DCS240 - OpSw31="c" for faster turnout command handling (i.e. disables metering)</li>
<li>DCS210 - OpSw31="c" for faster turnout command handling(i.e. disables metering)</li>
<li>DB150 - does not provide a way to control "metering"</li>
<li>DCS50 - does not provide a way to control "metering"</li>
<li>DCS51 - does not provide a way to control "metering"</li>
<li>DCS52 - OpSw31="c" for faster turnout command handling (i.e. disables metering)</li>
<li>DT200 acting as command station with DB100 - does not provide a way to control "metering"</li>
</ul>
<p>If you will have multiple connections, the "Defaults" tab
in the "Preferences" panel may be used to direct certain
types of operations to different connections. A good example
of this is a system with two PR3 connections, one in
stand-alone programmer mode for programming decoder CVs, and
the other for communication with a layout LocoNet and command
station. In this case, use the "Defaults" settings to select
one LocoNet connection only for "Programmer" and the other
LocoNet connection for "Throttles", "Power Control", and
"Command Station".</p>
<h2><a name="Using" id="Using">Using JMRI with
LocoNet®</a></h2>JMRI provides a number of features which
allow it to interact with LocoNet. Some key things to know about
are included here.
<h3><a name="LocoNetAddressing" id="LocoNetAddressing">LocoNet Device Addressing</a></h3>
<p>Many LocoNet devices can be directly addressed by JMRI,
such as the individual turnout outputs on a DS54, or the
individual block detection inputs on a BDL16x. For more
information on how to find those addresses, see <a href=
"Addressing.shtml">this page</a>.</p>
<h3><a name="LocoNetTools" id="LocoNetTools">LocoNet Tools</a></h3>
<p>JMRI provides a variety of LocoNet-related tools. These
primarily allow configuration of LocoNet device
functionality, but also include some tools for status
monitoring. Information on these tools can be found at the
<a href="LocoNetTools.shtml">LocoNet® tools
page</a>.</p>
<h2><a name="Network" id="Network">Networked Computers and
LocoNet®</a></h2>There are several mechanisms available
to allow multiple computers to communicate with LocoNet.
These communicate via standard TCP/IP protocols, and can even
work remotely. At least one of the networked computers must
have a functioning LocoNet interface. See <a href=
"LocoNetworking.shtml">this page</a> for more information.
<h2><a name="Debugging" id="Debugging">Debugging</a></h2>
<ul>
<li>When using the LocoBuffer or LocoBuffer-II, be sure
that the JMRI preferences for the connection are set to use
the same Baud rate as the LocoBuffer or LocoBuffer-II.</li>
<li>On Windows O/S machines, be sure that the JMRI
connection is set to use the correct COM port. Use Windows
"Device Manager" to help determine which COM port your
interface hardware is using, then verify that JMRI is
configured to use that COM port.</li>
<li>On Windows platforms, the COM port assignment can
change if the interface hardware is moved from one USB port
on the computer to another USB port. Avoid changing how
your LocoNet-to-computer interface is connected to the
computer.</li>
<li>On Windows platforms, the COM port assignment can
change if the interface hardware is connected via a USB
hub. At Windows start-up, the computer can assign different
COM port numbers to devices downstream of USB hubs, even if
all of the USB hardware connected in the system has not
been changed. Avoid connecting your LocoNet-to-computer
hardware downstream of a hub. Note that a computer monitor
which has USB connectors, and which is connected to a PC
using a USB cable is considered to have a built-in USB
hub.</li>
<li>Some PR3 devices were shipped with poor quality USB
cables. These cables have been known to cause a computer to
fail to communicate with the PR3 or to have intermittent
communication. Users should consider replacing the original
USB cable from the PR3 with a known-good USB cable.</li>
</ul>
<h4><a name="ErraticReadback" id="ErraticReadback">Erratic or
Non-Functioning CV Readback</a></h4>
<ul>
<li>Some mobile decoders will only allow proper Readback of
CV values when there is a sufficient electrical load
connected to the F0F (front headlamp) output connections or
the motor connections. This means that an incandescent lamp
or LED is properly connected to the front headlamp
connection and functional. Other mobile decoders will only
provide proper CV Readback when a motor is connected to the
mobile decoder motor connections. Consult the documentation
for your mobile decoder to determine what connections are
required to allow proper CV readback.</li>
<li>Some Digitrax hardware is capable of successful CV read
and write operations on some mobile decoders but is unable
to reliably read and/or write CVs for other mobile
decoders. This problem is most obvious with sound decoders
from some manufacturers. Some suggestions are listed here.
<ul>
<li>When using a Zephyr (DCS50) or Zephyr Xtra (DCS51),
enable its "Blast Mode" programming feature. This will
often allow correct writing of mobile decoder CV
values.</li>
<li>"Programming on the main" can allow a Chief (DCS100
or DCS200) to properly write to difficult mobile
decoder's CV values.</li>
<li>A programming booster, such as the
<i>SoundTraxx</i> <strong>PTB-100</strong> or the <i>DCC
Specialties</i> <strong>Power Pax</strong> can often be used
between the command station programming track
connections and the programming track to allow
successful read and write access of CVs on mobile
decoders which do not allow Readback on a programming
track connected directly to the programming
hardware.</li>
<li>Some PR3 users report that the PR3 programming
track can successfully read and program sound decoders
when the PR3 is powered using an 18 Volts DC power
supply instead of a lower-voltage power supply such as
the PS12 or PS14. <strong>Do this at your own
risk!</strong> <em>Current Digitrax documentation for
the PR3 defines a maximum input voltage of 15 Volts DC,
where previously the maximum voltage was listed as 20
Volts DC. Use of input voltages higher than 15 Volts DC
could damage the PR3 hardware.</em></li>
</ul>
</li>
</ul>
<h4><a name="TurnoutCmdHandling" id=
"TurnoutCmdHandling">Command Station Turnout Command
Rejection and JMRI Turnout Command Handling</a></h4>
<p>Digitrax command stations pass LocoNet switch command
messages to the DCC track signal so that track-connected
accessory decoders can receive the switch commands. Digitrax
command stations seem to buffer the switch requests and
forward them to the DCC track signal in a way that does not
have a noticeable impact on mobile decoder response to
throttle control operations. This buffer is limited, and
under conditions of heavy LocoNet switch command traffic, can
overflow. When this happens, the command station will respond
with a message (a <code>\<LONG_ACK\></code> opcode)
saying that it rejected (did not accept) the switch command.
When the command station gives this response, the switch
command is not placed into the buffer and is forgotten.<br>
This can be problematic, depending on how the device which
sent the switch command responds to the rejection message on
LocoNet. Many LocoNet devices do not notice the rejection
message, so do not attempt to re-send the switch command.
Other LocoNet devices can pay attention to the rejection
message and can wait a while before re-sending the message.
Some LocoNet devices can be programmed either to resend the
switch command if the rejection message is seen, or to not
resend if the rejection message is seen.<br>
This wide variety of behaviors can cause inconsistent or
unreliable behavior of any device which relies on stationary
decoder messages on the DCC track signal. Note that this can
include devices which connect to LocoNet and which monitor
the DCC track signal which is available on the LocoNet cable
"RailSync" wires.</p>
<ul>
<li>
<a name="turncmdhandsettings" id=
"turncmdhandsettings">Turnout Command Handling
Settings</a>
<p>JMRI has various mechanisms to help handle these
temporary LocoNet switch command buffer overloads. These
mechanisms are controlled by the "Turnout Command
Handling" option for each LocoNet-based connection. The
four JMRI Turnout Command Handling options are described
below.</p>
<ul>
<li>Normal - the default setting, is recommended for
the vast majority of layouts. In this mode of
operation, JMRI will quickly retry the last LocoNet
switch command seen before the command station's switch
command rejection message, and will continue to repeat
the switch command until a switch command is accepted
by the command station. This quick retry can cause
extremely high levels of activity on LocoNet.</li>
<li>Spread - This mode is the same as "Normal",
described above, except that JMRI implements additional
delay between any switch commands which it sends to
LocoNet. This should reduce the likelihood that JMRI
commands would cause an overflow of the Digitrax
command station switch command buffer, but does not
have any effect on other LocoNet devices which generate
LocoNet switch commands. The retry mechanism described
above for the "Normal" mode is enabled.</li>
<li>One Only - This disables the JMRI retry mechanism
for rejected switch commands. JMRI will not retry any
LocoNet switch command messages. The amount of delay
between any two JMRI-generated switch commands sent to
LocoNet is the same as "Normal" mode.</li>
<li>Both - This option both disables the JMRI rejected
switch command retry mechanism and increases the delay
between any two switch commands sent by JMRI to
LocoNet.</li>
</ul>
<p>These options do not take effect until the preferences
are saved and JMRI is restarted.<br>
None of these options can <i>guarantee</i> that
<i>all</i> LocoNet switch messages <i>will</i> be passed
to the DCC track signal.</p>
</li>
<li>
<a name="alternatives" id="alternatives">Command Station Turnout Command
Rejection Avoidance Strategies</a>
<p>There are a number of strategies which can be used to avoid the
"turnout command retry storms" which can occur with JMRI.
<ul>
<li>Do not use "flashing" signal aspects when signal hardware does
not provide the flashing mechanism. When the hardware does not
provide an appropriate flashing mechanism, JMRI must manually
change the signal head aspect from "a lit color" to "dark" and
repeat for the duration that the signal head displays a flashing
aspect. This is a problem that occurs with JMRI when using SE8C
signal heads, and can occur with other signal head types.
<p>Alternatively, in some cases it may be possible to configure the
signaling hardware so that JMRI need not send frequent individual
turnout commands to implement flashing aspects. While this option
may be useful with some signaling hardware, this option does
not apply to JMRI when using SE8C signal heads.</li>
<li>Some users find it possible to take advantage of the JMRI
"automation" feature which uses a different mechanism to control
switches. With a LocoNet connection, this mechanism uses LocoNet
messages which are specifically sent to the DCC track signal. These
messages are neither the "normal" LocoNet turnout control messages
nor the "alternate" LocoNet turnout control messages used with the
command station "Bushby" feature, described below.
<p>See <a href="../../../package/jmri/jmrit/beantable/TurnoutTable.shtml#automation">
Turnout Table "automation"</a>help for more information on this
mechanism.
<p>When using this mechanism with LocoNet connections, the turnout
must not be configured for "MONITORING" feedback mode, as the
messaging used with this mechanism does not use the messages required
by "MONITORING" feedback mode.
This may be done in the JMRI <a href="../../../package/jmri/jmrit/beantable/TurnoutTable.shtml">
"Turnout Table"</a> by setting a turnout's "Feedback" mode to one
of "Direct", "OneSensor", "TwoSensor", "Indirect" or "Exact" (choose
one depending on the usable mode), and then configure the "Turnout
Automation" mode to "RAW".
<p>The image below shows one possible configuration which takes
advantage of this JMRI feature for a LocoNet turnout.
<p><a href="images/LnTurnoutFeedbackAutomationSettings.png">
<img width="50%" src="images/LnTurnoutFeedbackAutomationSettings.png"
alt="Image showing JMRI turnout entry with feecback and
automation settings visible"></a>
<p>(Click the image for a larger version of the image.)
<p>The effect of this setting is to (potentially) reduce the maximum
rate at which the command station must forward LocoNet turnout
control messages to the DCC track signal. This (potentially) reduces
the demands on the command station's buffering, thus potentially
reducing the likelihood of the command station's buffer filling.
<p>When this mode is used for a given turnout, JMRI does not make
any use of the "Bypass Bushby Bit" or the "Send ON and OFF"
configuration information.
<p>This type of JMRI configuration does not affect those LocoNet
turnout control messages generated by other LocoNet devices.
<p>There is some
question about how Digitrax command stations handle the messages
associated with this mechanism, which must be buffered by the
command station, and whether that command station buffering is any
different than the buffering used with "normal" and "alternate"
LocoNet turnout messages.
</li>
<li>JMRI normally sends an "ON" LocoNet message followed by an
"OFF" LocoNet message when controlling switches, just like Digitrax
throttles do. <span class="since">Since
<a href="https://jmri.org/releasenotes/jmri4.15.7.shtml" target="_blank">
JMRI 4.15.7</a></span>, it is possible to configure JMRI to send
only "ON" messages to turnouts, without sending "OFF" messages. Many
accessory decoders work well when only receiving "ON" messages.
<p>Using this JMRI feature reduces the number of LocoNet switch
control messages which need to be forwarded to the DCC track signal,
which reduces the probability that any given LocoNet switch command
will arrive at the command station when its buffer is already full.
<p>To configure this JMRI operating mode, it is necessary to
configure each individual JMRI turnout, via the JMRI
<a href="../../../package/jmri/jmrit/beantable/TurnoutTable.shtml">
"Turnout Table"</a>. The image below shows that turnouts
LT10 and LT12 are configured to send both "ON" and "OFF" messages -
each of these turnouts have the "Send ON and OFF" checkbox checked.
In the image, turnouts LT11 and LT13 have the checkbox unchecked, so
JMRI will only send "ON" messages when JMRI controls these turnouts.
<p><a href="images/LnTurnoutBushbySettings.png">
<img src="images/LnTurnoutBushbySettings.png" alt="sample display
of LocoNet turnouts configured for various JMRI Bushby modes" width="50%"></a>.
<p>(Click the image for a larger version of the image.)
<p>If the "Send ON and OFF" column is not visible, you may check the
"Show System-specific columns" checkbox at the bottom of the window, or
you may "right-click" while pointing to any visible header and then
check the "Send ON and OFF" checkbox.
<p>When a new JMRI turnout is created, the "Send ON and OFF" checkbox
is checked by default.
<p>Note that the "Send ON and OFF" checkbox settings have no effect LocoNet
switch control messages sent by other LocoNet agents.</li>
<li>It is possible to configure Digitrax command stations so that they
do not forward <i>"regular"</i> LocoNet turnout control messages to
the DCC track signal (and RailSync wires on the LocoNet cable). This
may be done by enabling the command station's "Bushby" feature, typically
done by configuring the command station's OpSw27 to "c"losed. JMRI
provides two methods for modifying Digitrax command station OpSw
settings. Both are described in this <a href="CommandStationConfig.shtml">
Command Station Configuration</a> help page.
<p>When the command station "Bushby" feature is enabled, only turnout
commands using a special LocoNet message type will be forwarded to
the DCC track signal. This can be used in a few different ways.
<ul>
<li>Some users simply enable the command station "Bushby" feature,
without re-configuring any LocoNet device or JMRI features. In
this case, no turnout control messages are forwarded to the DCC
track signal by the command station, and those devices which get
their control information from turnout commands on the DCC track
signal (or the low-power version on the RailSync wires on the
LocoNet cable) will not be controllable.
<p>This option is only suitable for layouts where there are no
devices which are controlled solely by the DCC track signal (or
its low-power equivalent on the LocoNet cable.
<p>Note that some devices get their control messages from the
low-power DCC track signal on the LocoNet RailSync wires <i>or</i>
from the LocoNet Data wires. If this type of device must be
controllable when the command station's Bushby feature is enabled,
the device must be configured to get control messages from the
LocoNet Data wires. An example is the SE8C, which defaults to
receive control messages from the low-power DCC track signal on
the LocoNet cable. To configure the SE8C to be controlled by
LocoNet messages, set the SE8C OpSw14 to "C"losed. Other device
types may require similar re-configuration to be controllable.
</li>
<li><span class="since">Since
<a href="https://jmri.org/releasenotes/jmri4.15.7.shtml" target="_blank">
JMRI 4.15.7</a></span>, JMRI provides a feature which "bypasses"
the command station's "Bushby" feature and therefore allows JMRI
to control those devices which are controlled by turnout control
information on the DCC track signal. This requires configuration
of individual JMRI Turnouts (via the
<a href="../../../package/jmri/jmrit/beantable/TurnoutTable.shtml">
"Turnout Table"</a>) to have their "Bypass Bushby Bit" checkbox
checked. This enables JMRI to send "alternate" LocoNet Turnout
control messages to the command station, and these "alternate"
messages will be buffered so that they may be passed to the DCC
track signal, regardless of the state of the command station's
"Bushby" feature.
<p>To configure this JMRI feature for a turnout, define the
turnout (if necessary) in the JMRI <a href="../../../package/jmri/jmrit/beantable/TurnoutTable.shtml">
"Turnout Table"</a>, and place a check in the turnout's "Bypass
Bushby Bit" checkbox. If the "Bypass Bushby Bit" column is not
visible in the table, you may right-click on the table column header
row and check "Bypass Bushby Bit", or check the "Show system-specific
settings" checkbox at the bottom of the window.
<p>In the image above, turnouts LT12 and LT13 show the "Bypass Bushby
Bit" checked. When JMRI attempts to control either of these two
turnouts, JMRI will send an alternate LocoNet turnout control message
("OPC_SW_ACK"), which will bypass the command station's "Bushby"
blocking of "regular" LocoNet turnout control messages ("OPC_SW_REQ").
<p>Note that the command station still buffers the "alternate"
LocoNet turnout control messages, and turnout message rejection
can occur. As such, it is important to configure the "Bypass Bushby
Bit" option only on those turnouts which require conrol via the
DCC track signal or the low-power version that is available on
the LocoNet cable's RailSync wires.
<p>Also note that setting the JMRI "Bushby Bit Bypass" feature
a given turnout does <em>not</em> affect how turnout control
messages from other LocoNet are encoded. Unless another LocoNet
device uses the "alternate" LocoNet turnout control message, that
LocoNet device will not be able to pass turnout control messages
to the DCC track signal when the command station "Bushby" feature
is enabled.
</li>
</ul>
</li>
<li>The best turnout command rejection avoidance strategy is one in
which the command station never even sees the LocoNet turnout control
messages. This can be done by using only devices which send and/or
receive switch control messages via the LocoNet data bus, and placing
all of those devices on a <i>"Standalone"</i> LocoNet for use by those
devices. This standalone LocoNet can be separately connected to JMRI
(on a second connection) so that JMRI can access the command station,
throttles, fast clock, and other resources via one LocoNet connection,
and access signals and turnouts via another LocoNet connection. This
requires a separate LocoNet interface device for each connection.
<p>See the JMRI <a href="StandaloneLocoNet.shtml">Standalone LocoNet®</a>
page for background, ideas, and suggestions for implementing a
Standalone LocoNet.</li>
</ul>
</li>
<li>
<a name="cmdStationTrkPwrOff" id=
"cmdStationTrkPwrOff">Turnout command rejection when
track power is off</a>
<p>Some more recent Digitrax command stations will refuse
to accept switch commands when track power is turned off.
This can result in a "storm" of repeated switch messages
on LocoNet if track power is off when switch messages are
sent. This problem can be avoided by ensuring that track
power is on when switch messages are to be sent.</p>
</li>
<li>
<a name="multConnTurnoutReject" id=
"multConnTurnoutReject">Turnout command rejection and
multiple active LocoNet connections</a>
<p>When JMRI has multiple active connections to a single
LocoNet, it may be necessary to configure all but one of
the active LocoNet connections for "Turnout Command
Handling" type of "Only One", with one active LocoNet
connection configured for one of the other "Turnout
Command Handling" types. Failure to do this could cause
the various JMRI LocoNet connection instances to
independently attempt to resolve any turnout messages
which have been rejected by the command station. This
could result in a storm of turnout command retries on
LocoNet.<br>
Similarly, when multiple JMRI instances are working with
the same LocoNet, only one JMRI connection to the LocoNet
should be configured for a "Turnout Command Handling"
type other than "Only One". Failure to do this could
cause the various JMRI LocoNet connection instances to
independently attempt to resolve any turnout messages
which have been rejected by the command station. This
could result in a storm of turnout command retries on
LocoNet.</p>
</li>
</ul>
<a name="SeeAlso" id="SeeAlso"></a>
<h2>JMRI information and tools for LocoNet-specific hardware and features</h2>
<p>JMRI supports a wide variety of LocoNet hardware and features. JMRI provides
a wide variety of hardware-specific tools to assist in configuring the devices.
And JMRI provides a number of tools to monitor the operation of LocoNet. Most
of these features are described in the JMRI "Help" pages linked below (also refer to the sidebar).</p>
<a name="devicetoolhelp" id="devicetoolhelp"></a><h3>JMRI LocoNet-specific Help pages</h3>
<ul>
<li>Computer-to-LocoNet® Interface Hardware
<ul>
<li><a href="LocoBufferUSB.shtml">RR-CirKits
LocoBuffer-USB</a></li>
<li><a href="LocoBufferII.shtml">RR-CirKits
LocoBuffer-II</a></li>
<li><a href="LocoBuffer.shtml">LocoBuffer</a></li>
<li><a href="PR4.shtml">Digitrax PR4</a></li>
<li><a href="PR3.shtml">Digitrax PR3</a></li>
<li><a href="PR2.shtml">Digitrax PR2</a></li>
<li><a href="BTLocoBridge.shtml">Bluetooth
LocoBridge</a></li>
<li><a href="MS100.shtml">Digitrax MS100</a> (Strongly
not recommended)</li>
<li><a href="DCS52.shtml">Digitrax DCS52 via its
integrated USB port</a></li>
<li><a href="DCS240.shtml">Digitrax DCS240 via its
integrated USB port</a></li>
</ul>
</li>
<li>
<a name="tools" id="tools"></a>LocoNet-related Tools
<ul>
<li><a href=
"../../../package/jmri/jmrix/loconet/locomon/LocoMonFrame.shtml">
Monitor LocoNet</a></li>
<li><a href=
"../../../package/jmri/jmrix/loconet/slotmon/SlotMonFrame.shtml">
Monitor Slots</a></li>