/
CTC.shtml
990 lines (891 loc) · 48.4 KB
/
CTC.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
<!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">
<!-- Copyright ($Author$) 2016 -->
<title>JMRI: CTC</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" -->
<div class="nomenu" id="mBody">
<div id="mainContent">
<h1>JMRI: CTC</h1>
<p>
CTC is a very complex system. An understanding of the goals of CTC and
how it functions is very helpful. While this tool will describe various
CTC features, it is not a CTC course. There are many books written on
the subject, for example Dr. Bruce Chubb's CTC manuals. Other materials
(too numerous to list) exist on the Internet as well, such as Mike
Burgett's web site (since shut down, but may be active in the future again).
</p>
<p>
<strong>Important</strong>: A requirement of CTC is that a fully functional
ABS (Automatic Block Signaling) signaling system exist already in your system.
As you may already know, CTC is just a layer on top of ABS.
</p>
<h2>Overview</h2>
<p>
The CTC system consists of three main components. The first one is the
<strong>CTCEditor</strong> which is used to define the CTC system. The
second component is <strong>CTCMain</strong>, which is a run time
component which executes the rules created by the editor. These
components are started by using the PanelPro <strong>Tools</strong> menu
and/or including them as actions defined in <strong>Preferences >> Start
Up</strong>.
</p>
<p>
The last component is the layout configuration in JMRI. This includes
turnout definitions, occupancy sensors, blocks and signals. The signals
can be defined as signal heads with SSL or signal masts using signal mast
logic. The signaling implementation needs to properly implement ABS
signaling before adding CTC. This includes proper block boundaries.
</p>
<h3>CTCEditor</h3>
<p>
The CTCEditor is used to define the CTC components and the rules that will
be used by the run time component. The resulting data is stored in an XML
file: <strong>CTCSystem.xml</strong>. This file is located at the
<em>user files location</em> in the <strong>ctc</strong> directory.
</p>
<p>
As an option to support creation of the GUI portion of the CTC machine,
an external Panel Editor panel file can be created by pressing a single button. This
facilitates the design of the full GUI CTC panel. This feature also
creates a 2nd minimal panel xml file that contains all of the CTC specific
internal sensors.
</p>
<h3>CTCMain</h3>
<p>
CTCMain is the run time component that provides all of the logic to
implement a CTC machine. It responds to layout and panel inputs and
takes appropriate actions based on the definitions provided by the
CTCEditor. It eliminates the need to create Logix or scripts.
</p>
<h2>Defining a CTC System</h2>
<p>
Use the following table of contents to jump to various topics. For new
CTC implementations, the topics should be reviewed/done in order.
</p>
<ol>
<li><a href="#editor">CTCEditor</a>
<ol>
<li>Menus
<ol>
<li>File menu
<ol>
<li><a href="#menuFile">New</a></li>
<li><a href="#menuFile">Save</a></li>
<li><a href="#menuFile">Exit without saving</a></li>
</ol>
</li>
<li>Edit menu
<ol>
<li><a href="#menuEditFind">Find and Replace...</a></li>
<li><a href="#menuEditFix">Fix Error(s)...</a></li>
</ol>
</li>
<li>Configure menu
<ol>
<li><a href="#menuCfgDeb">Debugging</a></li>
<li><a href="#menuCfgDef">Defaults</a></li>
<li><a href="#menuCfgFlt">Fleeting</a></li>
<li><a href="#menuCfgPat">Patterns</a></li>
<li><a href="#menuCfgGui">GUI Design</a></li>
</ol>
</li>
</ol>
</li>
<li><a href="#osList">O.S. Sections List</a>
<!-- <ol>
</ol> -->
</li>
<li>Edit Buttons
<ol>
<li><a href="#frmCB">Code button</a></li>
<li><a href="#frmSIDI">Signal direction indicators</a></li>
<li><a href="#frmSIDL">Signal direction lever</a></li>
<li><a href="#frmSWDI">Switch direction indicators</a></li>
<li><a href="#frmSWDL">Switch direction lever</a></li>
<li><a href="#frmCO">Call On</a></li>
<li><a href="#frmTRL">Traffic locking</a></li>
<li><a href="#frmTol">Turnout locking</a></li>
<li><a href="#frmIL">Indication locking</a></li>
</ol>
</li>
</ol>
</li>
<li><a href="#ctcFiles">Files</a></li>
<li><a href="#ctcMain">CTCMain</a></li>
<li><a href="#ctcDefinitions">Definitions</a></li>
</ol>
<a name="editor" id="editor"></a>
<h2>CTCEditor</h2>
<p>
The CTCEditor consists of a menu bar, a section containing a list of the
defined OS sections with related buttons and a group of 9 buttons at the
bottom. With the exception of the <strong>Code</strong> button, the
remaining buttons can be enabled to activate the selected CTC feature.
</p>
<p>
When the editor is started, it loads the current CTCSystem.xml file. When
the editor is stopped by using the window close button, the CTCSystem.xml
file is updated. See the <a href="#menuFile">file menu</a> for other options.
</p>
<h3>Editor Menus</h3>
<a name="menuFile" id="menuFile"></a>
<h4>File menu</h4>
<p>
The <strong>New</strong> menu item deletes the current configuration in
the editor. If the editor is then closed (which does an automatic save),
the CTCSystem.xml file will be empty.
</p>
<p>
The <strong>Save</strong> menu item writes the current editor configuration
to the CTCSystem.xml
file. The CTCEditor program is not closed.
</p>
<p>
The <strong>Exit without saving</strong> menu item after asking for confirmation
that you really want to do this, discards any changes and closes the CTCEditor.
</p>
<a name="menuEditFind" id="menuEditFind"></a>
<h4>Edit menu</h4>
<h5>Find and Replace...</h5>
<p>
This invokes a powerful editor. It doesn't have many features, but the
important point is that it will search everything in the system for
references to things that may be changing. For example, when changing
"IS8:LDGL" -> "IS8:XYZZY", the program will list all of these references,
and if approved will change all of them, so that there are no
"dangling references" to something that no longer exists. In this
manner, it is a "refactor / replace" function (for programmers who
understand these terms).
</p>
<p>
Only data "destined" for JMRI is scanned. None of the data maintained
by this program for its own internal use (such as Patterns, Defaults,
etc.), is scanned.
</p>
<h6>Searching</h6>
<p>
Enter in the text to search for, along with "Case sensitive" checkbox
and Exact / Contains radio buttons.
</p>
<p>
Once the <strong>Search</strong> button is pressed, the results are
shown on the right. This shows where the search string was found in
the system, and the context it is used in. No items are selected.
Press <strong>Select all</strong> to select all rows. That button
now says <strong>Deselect all</strong> (it flip/flops from one to the
other). The standard single selection, multiple selection and range
selection options are available. A count of the items selected appears
next to the <strong>Replace</strong> button. Only the selected items
will be replaced.
</p>
<h6>Replacing</h6>
<p>
At least one item has to be selected before the <strong>Replace</strong>
button will be enabled. The radio buttons above it allows the replace
process to be modified.
</p>
<p>
<strong>Replace completely</strong>: The entire line no matter where
the search string is found is replaced by the "<strong>Replace with:
</strong>" text. This is not a common choice.
</p>
<p>
<strong>Replace searched for value only</strong>: This is the
typical choice and the default. The search text is replaced with the
replacement text.
</p>
<p>
<strong>Rescan with below and substitute with above</strong>: The
purpose of this is to use the first search function to locate lines
with other data in them, then re-scan each of the lines selected with
the new search pattern, and substitute the "Replace with:" value there.
This sub-search is case sensitive.
</p>
<p><strong>Note</strong>: Depending on the nature of the change,
it is possible that new sensors are required. For example, changing
IS2:CB to IS2:CodeBtn results in a new code button sensor. If the
panel xml file already refers to the old sensor name, it will have to
be modified.</p>
<p><strong><em>Warning: At present, there is no "Undo".</em></strong></p>
<a name="menuEditFix" id="menuEditFix"></a>
<h5>Fix Error(s)...</h5>
<p>If an attempt is made to save the editor data and the
<strong>***ERROR***</strong> indicator appears anywhere in the Columns
listing, the save, including the automatic save during program exit,
will not occur. A dialog will suggest doing this menu item. Please
read carefully the information in this menu item.</p>
<a name="menuCfgDeb" id="menuCfgDeb"></a>
<h4>Configure menu</h4>
<h5>Debugging</h5>
<p>The defaults here are good enough, but may modified if desired.</p>
<p>
<strong>CTC system reload sensor</strong>: This sensor, when triggered
(set to active) will cause the entire CTC system to reload. This makes
it possible to make CTCEditor changes and then test them immediately
without having to restart JMRI each time. See "Running the CTC system
under JMRI" for more information on this.
</p>
<p>
<strong>CTC debug traffic locking rules triggered display sensor</strong>:
When active, the number of the Traffic Locking rule that was true is
logged when a code button is pressed. It is logged as an INFO message
to the System Console. In order to see the System Console within JMRI
select Help >> System console... It's the "Green Screen".
</p>
<a name="menuCfgDef" id="menuCfgDef"></a>
<h5>Defaults</h5>
<p><strong>Signal System Type</strong>: Select either Signal Heads or Signal Masts.</p>
<p><strong>Turnout locks enabled at startup</strong> and <strong>Seconds
until all lockable turnouts locked</strong>: The default is
checked and the CTC system will lock all of the turnouts automatically
at startup. Some layouts require locks to be unlocked at CTC system
startup for other external (to CTC) initialization requirements. You can then
have your dispatcher manually lock all of the locked turnouts before
the layout starts operation. Or, you can set the "Seconds until all lockable
turnouts locked" to a value >0 (in seconds), and the CTC system will do
this automatically after that time period. <strong>Note</strong>: each time JMRI
is started, it takes a variable amount of time to complete, so this value
may have to be set a bit higher than the quickest time, in order to give
the system a chance to stabilize before locking the turnouts.
Or you can invoke the following lines
(however you want) in a Jython script file in order to have this done
automatically by your script(s) after your special external
initialization requirements are done:</p>
<div style="margin-left: 2em;"><pre>
import jmri.jmrit.ctc
CTCMain = jmri.jmrit.ctc.CTCJythonAccessInstanceManager._mCTCMain
CTCMain.externalLockTurnout()
</pre></div>
<p><strong>Time values</strong> (for Signal and Switch
directions): These are values that are given to
each CTC O.S. section as default values when the CTC O.S. section is
created. The timing values edit boxes are standard CTC values, refer to
Definitions for more information on each.</p>
<p><strong>No code button delay in milliseconds</strong>: This is the
default for newly created O.S. Sections. Individual O.S. sections can be
changed if needed. Background: Normal CTC panels always had a code
button for every O.S. section which means a value of zero is appropriate.
Certain tower situations did not have a code button(s) present when some
or all or the O.S. Section(s) were local to the tower. In this case,
the tower operator changing either the switch direction and/or signal
direction levers was enough to transmit the request to the field. On
the prototype, there was a built in delay so that the tower operator
could change both the switch and signal levers before the code was
transmitted to the local O.S. section. That delay is simulated with
this value. Having a larger value will increase this delay, and a
large enough value will allow the tower operator to change both the
switch and signal lever before the codes are transmitted to the field.
A reasonable value in this case might be 5000 (5 seconds). Some towers
had virtually no delay, so enter a value such as 10 milliseconds.</p>
<a name="menuCfgFlt" id="menuCfgFlt"></a>
<h5>Fleeting</h5>
<p><strong>Fleeting toggle sensor</strong>: The sensor used to
enable/disable fleeting.</p>
<p><strong>Fleeting enabled at start</strong>: Default is to not enable
fleeting during startup.</p>
<a name="menuCfgPat" id="menuCfgPat"></a>
<h5>Patterns</h5>
<p>
Since there will probably be 100's if not 1,000's of JMRI internal
sensor objects (Prefix "IS:") that need to be created to support all
of the on-screen objects of a typical CTC installation, it is important
that you realize how this program works with these "patterns"". By
using them, you do not have to spend dozens of hours to enter all of
this in manually, or make a mistake and have
the JMRI runtime system complain of problem(s) - back and forth, make a
change, run JMRI, find another problem, etc. Using patterns prevents
this.
</p>
<p>
Patterns are used for all of the internal sensors created by this
system. When an O.S. section is created, there are two numbers that
are associated with that O.S. section: a switch number (always odd)
and the corresponding signal number (always even and always one more
than the switch number).
</p>
<p>
The pattern format is IS#:XXX. The "#" character in the edit boxes are
substituted automatically when the CTC O.S. section is first created.
The respective switch / signal areas use the respective switch # /
signal # given for the O.S. Section. If more than one "#" appears, every "#"
will get the corresponding substituted number.
In this way you do not have to do all of the manual typing or selecting
associated with creating all of these sensor strings.
</p>
<p>
<strong>Patterns usage by this program and its advantages over other methods</strong>
</p>
<p>
Every time an O.S. section is created, the program will apply a set
of patterns provided by the user: a default set of patterns is
automatically generated by the program at startup which the user can
override at will. This will be explained in more detail later.
In order to see these default patterns, start the program and choose
"Configure / Patterns"".
</p>
<p>
Changing anything on this screen has no effect on existing information
in the system. It is only used when a <strong>new</strong> O.S. section (via Add button) is
created. However, you may selectively re-apply this pattern to the
whole system or individual pieces of the system. Here's how:
</p>
<p>
<strong>Reapplying patterns to existing information:</strong>
Once you've changed this screen, you may want the new pattern to be selectively applied. There are two choices:
1.) Reapply pattern to selected item (a single O.S. section) or 2.)
Reapply pattern to selected item (a single O.S. section) specific sub-system.
To do 1, get to the main screen, and select a single O.S. section. The "Reapply patterns to selected item"
button will be enabled. When you press this button, a confirmation dialog will appear. Pressing "Yes" will
then take the new pattern specified and completely apply it to all of the O.S. Sections sub-systems.
To do 2, get to the main screen, and select a single O.S. section. Then at the bottom of the screen, press
the "Edit" button for the sub-system you want to modify. NOTE: Some sub-systems are not affected by this,
so what follows may not appear. You will then see a button at the bottom of the sub-system selected with
"Reapply patterns - this form ONLY!". Pressing that will immediately show you the results of the new
pattern in the edit boxes of that screen.
</p>
<a name="menuCfgGui" id="menuCfgGui"></a>
<h5>GUI Design</h5>
<p>
<strong>GUI Design - automatic creation of the JMRI GUI screen</strong>:
An additional feature of this program is to be able to automatically create a "standard" USS CTC panel
from the parameters specified elsewhere in this program. This screen configures those available options.
See "Files created for support...." for more information and procedures for loading them into the JMRI system.
Everything is put in pre-determined locations on the screen. It is an easy procedure in JMRI's Panel Editor
(or other) to reposition those items.
<strong>Caveat emptor:</strong>
If you do change the locations of these items, JMRI does not modify the files created by this program.
It is not designed to keep track of which file contains which modifications. Only if you save the panel to
completely different panel name will those changes be saved. You should completely design the CTC panel using
this program before saving to another name in JMRI, and then begin the final changes to that panel from within JMRI.
</p>
<p>
<strong>Extra blank columns after last defined column to create:</strong>
Normally, if this is 0, this program creates after the last CTC O.S. Section column specified a "right
edge of CTC machine panel". If you want additional blank column(s) between your last CTC O.S. Sections
column # and the right edge, enter that number here.
</p>
<p>
<strong>Type of CTC panel</strong>:
Presently only USS is available at this time (10/31/2018). More may be available in the future.
</p>
<p>
<strong>Vertical size:</strong>
JMRI provides blank panel items in each of the sizes listed. Choose one.
</p>
<p>
<strong>Signals on panel</strong>
All O.S. Section signals - All of the signals specified in the Signal Direction Indicators sub-system are
created on the screen for you. This is not a prototype practice, but will help in your development of
SSL (Simple Signal Logic) and CTC design. You can see the state of the signals in the field with this. Signal
heads or Signal masts will be created per your specification.
Green/off only (Future feature) - Not available at this time. The prototype in certain installations have
a single green indicator indicating all signal(s) at that location are displaying stop (red) (green indicator
off) or permissive of some form (one or more signals at that location non-stop (non-red)).
</p>
<p>
<strong>Builder Plate</strong>
Check this if you want the builder plate on the machine face.
</p>
<p>
<strong>Turnouts on panel</strong>
Normally you want to generate turnouts on the CTC track board, which is the default "Generate checked". If
you don"t want this feature, uncheck this.
</p>
<p>
<strong>Fleeting toggle switch (only if fleeting configured)</strong>
Create the toggle switch on the panel if checked.
</p>
<p>
<strong>Analog clock and clock on toggle</strong>
Create an analog clock on the panel, along with above it a toggle switch to turn it on / off.
</p>
<p>
<strong>Reload CTC system button</strong>
Create a button on the screen to perform this.
</p>
<p>
<strong>CTC Debug on toggle</strong>
Ditto.
</p>
<p>
<strong>Create variety of track pieces</strong> (future feature):
A variety of track pieces are created on the screen, so that it is easier to "copy / paste" all of these objects as the designer desires.
</p>
<p>
<strong>O.S. Occupancy sensor blinks red when unknown or inconsistent</strong>
Normally, JMRI will display an "X" or "?" on a sensor when its state is unknown or inconsistent. By checking
this checkbox, the program will substitute a blinking indicator for these to draw better attention to them.
I personally use these for optical sensors on my layout because of the number of sensors on my layout causes
LocoNet to loose messages at system startup.
</p>
<a name="osList" id="osList"></a>
<h3>OS Section List</h3>
<h4>The Prototype CTC machine and this program</h4>
A prototype CTC machine is organized by columns (my term). A single CTC machine column can be blank, or contain an O.S.
section and all of the associated controls. I begin the numbering of my CTC machine columns with 1. This column number
has no relation or correlation at all to the Switch or Signal numbers of a normal O.S. section. You can create as many columns
as you like on the computer screen(s).
<h4>OS Sections</h4>
A non-blank column always has an O.S. section with a code button associated with it. An O.S. section always has an odd
switch number and an even signal number, where the signal number is always one more than the switch number.
Each O.S. section as it is created does not have to be 2 more than the prior switch number entry. Example: 1, 3, 7, 15, 17....
They do not have to be in ascending sequence, their order has no impact on the program. However, it is strongly suggested per
prototype practice that they are in ascending sequence. You may re-order them on the main screen using up/down buttons in case
you entered them out of order, which is described in another section.
<h4>"JMRI Validation" and "Check everything with JMRI" (grayed out at start)</h4>
<p>
<strong>Prerequisite</strong>: A new system displays "JMRI Validation: Disabled", and also
the button "Check everything with JMRI" is grayed out (disabled). This is normal for a new system.
</p>
<p>
Once both of the sensors defined in Configure/Debugging are contained in the panel file
and that panel file is loaded, then "JMRI Validation: Enabled" will be displayed and the
button "Check everything with JMRI" is available for pressing.
</p>
<h5>The purpose of pressing "Check everything with JMRI":</h5>
<p>
Pressing this will then present you with a dialog asking if you want to see all of the errors listed on a separate
screen. It will then go thru <strong>every</strong> JMRI object that is backed by a real device (sensor, signals, etc) defined
in the CTC system and verify that a definition exists for it within JMRI already.
This is just a sanity check, and normally you should not encounter any errors. If you
do, then define the missing object(s) in JMRI.
</p>
<p>===The basic process is set the configuration options, do the file export process, load
sensors, save JMRI and restart with the updated panel xml file. Now setting up OS sections and related Edit buttons
can be validated. ===
</p>
<h3>Action buttons (to the right of the "Presently defined CTC O.S. sections:")</h3>
<p>
These buttons are dynamically enabled or disabled based upon the selected item. Button "Add" is always available.
</p>
<h4>Add</h4>
<p>
Allows you to add another column.
</p>
<p>
After pressing, configure the two values as needed.
</p>
<p>
<strong>Regarding the check box "GUI Generated before":</strong>
If checked, then this column has already been generated once before. In case you want it to be generated
again when you press "Write .xml files for JMRI GUI support", clear the check box.
</p>
<h4>Delete</h4>
<p>
Allows you to delete a column <strong>if</strong> there are no references to it.
</p>
<p>
If you notice in the column that you are deleting that there are items in parenthesis's, you will be prevented
from deleting that column with an error message. Only when the parenthesis's disappear will you be allowed
to delete the column.
</p>
<p>
The general format is #/# indicating which switch and signal column entry is referencing this entry,
followed by the following letter possibilities:
"TrL:" Traffic Locking rule references this. If there is an 'L' appended, it indicates left traffic rules, otherwise right traffic rules.
"Sw:" Switch Slaved references this.
<h3>Edit Buttons (at the bottom of the screen)</h3>
<a name="frmCB" id="frmCB"></a>
<h4>Code button</h4>
<p>
This provides the major information for a single O.S. section.
</p>
<p>
<strong>Code button sensor</strong>: Required. Enter the sensor associated with this code button. This name
is automatically generated by the patterns system.
</p>
<p>
<strong>Primary O.S. section occupied sensor</strong>: Required. So long as this sensor is active (indicating
that the O.S. section is occupied), then the following cannot be changed: signals, turnout change,
lock/unlock turnout and call on. This should be the main occupancy sensor.
</p>
<p>
<strong>Secondary O.S. section occupied sensor</strong>: Optional. Typically this is entered when a crossover
is in an O.S. section and you have two sensors, one for each parallel track. This is the non-primary route, for
instance the other side's track sensor. When active, it prevents turnout change and lock/unlock turnout only.
</p>
<p>
<strong>Switch slaved to O.S. section #</strong>: Optional. Use this to slave another O.S. section
with <strong> just </strong> a turnout in it to this O.S. section. Used primarily when one track goes
to 3 or more other tracks via multiple turnouts.
</p>
<p>
<strong>No code button delay in milliseconds</strong>: Required. If there is no code button (i.e. a tower
operation), then put in the delay between when either the turnout or traffic direction switches are changed
and when the action actually occurs.
</p>
<a name="frmSIDI" id="frmSIDI"></a>
<h4>Signal direction indicators</h4>
<p>
Defines all of the information required for displaying the signal direction indicators on the CTC panel, and which
signal(s) in the field control them.
</p>
<p>
<strong>Left, Normal and Right indicator sensors</strong>: Normal and one or both of Left and Right
required. The three indicators on the panel. These names are automatically generated by the patterns
system. If this is a unidirectional O.S. section, then leave either the Left or Right sensor blank (not both!).
</p>
<p>
<strong>Coding and response time milliseconds: and Time locking interval milliseconds</strong>: Required. Values
are defaulted from the defaults screen. Change as you see fit to make each section unique if you want.
</p>
<p>
<strong>Left to right and Right to left traffic signal lists</strong>: Here you specify each of the
signal masts or individual signal heads associated in each direction with this O.S. section.
There must be at least one entry in each, <strong>unless</strong> it is a uni-directional O.S. section.
</p>
<a name="frmSIDL" id="frmSIDL"></a>
<h4>Signal direction lever</h4>
<p>
Defines all of the sensors required for the JMRI object MultiSensor in order to select a signal direction.
</p>
<p>
<strong>Left, Normal and Right lever sensors</strong>: Normal and one or both of Left and Right
required. This defines the three sensors associated with the 3 corresponding positions of the
MultiSensor. These names are automatically generated by the patterns system. If this is a
unidirectional O.S. section, then leave either the Left or Right sensor blank (not both!). The
missing entry should match the corresponding missing entry in the Signal Direction Indicators
for this O.S. section.
</p>
<a name="frmSWDI" id="frmSWDI"></a>
<h4>Switch direction indicators</h4>
<p>
Defines all of the information for displaying the switch direction indicators on the CTC panel, and
which switch in the field controls them.
</p>
<p>
<strong>Normal and Reverse indicator sensors</strong>: Required. The two indicators on the
panel. These names are automatically generated by the patterns system.
</p>
<p>
<strong>Actual turnout</strong>: Required. The turnout who's information is being displayed.
</p>
<p>
<strong>Coding and response time milliseconds</strong>: Required. Values are defaulted from
the defaults screen. Change as you see fit to make each section unique if you want.
</p>
<p>
<strong>Feedback different</strong>: JMRI does not support backwards feedback values, i.e. turnout
is commanded to CLOSED, turnout reports THROWN. Check this if your device's feedback is opposite
from the commanded value.
</p>
<p>
<strong>Optional GUI parameters</strong>: Ignore this if you are not generating GUI information. Otherwise
select the type of turnout from the 3 radio buttons, Check "Left hand turnout" if so, and
if "Crossover" is selected, then check "Other turnout also left handed" if so.
</p>
<a name="frmSWDL" id="frmSWDL"></a>
<h4>Switch direction lever</h4>
<p>
Defines the one sensor associated with the Sensor icon lever.
</p>
<p>
<strong>Lever sensor</strong>: Required. This name is automatically generated by the patterns system.
</p>
<a name="frmCO" id="frmCO"></a>
<h4>Call On</h4>
<p>
Defines all of the information for controlling (allowing) call on aspect(s) to be displayed in the
field.
</p>
<p>
<strong>Toggle sensor</strong>: Required. This name is automatically generated by the patterns system. This
associates the toggle switch on the panel with this Call On.
</p>
<p>
When you first enter this screen, there is nothing in
the "Grouping list" area. Once you have entered new entries, you may individually select an entry by
clicking on it, and then the "Edit Below" and "Delete" buttons become available, along with
various field(s) below being enabled for changing. In order to get
started, press "Add New" the first time here, and various fields below will be enabled
based upon how you have configured you system for Signal Heads or Signal Masts in "Configure / Defaults".
All fields will be described below, but may not be available based upon Signal Heads or Signal Masts selected:
</p>
<p>
<strong>Signal</strong>: Required. Choose from the signals defined in your system already. Then
select in the drop down to the right of this field whether the signal faces Left or Right.
</p>
<p>
<strong>Aspect</strong>: Required. Choose from the available aspects in the drop down list. <strong>Do not</strong>
choose flashing aspects for semaphores! The semaphore will act weird as it tries and fails to keep up with
the stream of movements.
</p>
<p>
<strong>Called on sensor</strong>: Required. Choose from the sensors defined in your system already.
</p>
<p>
<strong>Block</strong>: Required. Choose from the blocks defined in your system already. You <strong>must</strong> manually
check in JMRI the "Permissive" checkbox for this block in order for call on to work for this block, which is outside
the scope of this editor.
</p>
<p>
<strong>--- Route ---</strong> Choose up to 6 switch direction indicators that when lit specify the
route from the O.S. section to the called on block (Signal Masts) or sensor associated with the block (Signal Heads).
</p>
<a name="frmTRL" id="frmTRL"></a>
<h4>Traffic Locking</h4>
<p>
Defines all of the allowed non conflicting routes from the selected O.S. section in either direction from it.
This is the beating heart of the CTC system. As such, it is the most complex part of CTC you will encounter.
However, if you are methodical and after some experience, you should find that this section is fairly straight
forward.
</p>
<p>
When you initially select Traffic Locking, the first screen that comes up will allow you to edit one of the
directions from this O.S. section to other O.S. section(s). <strong>Note:</strong> Having no rules <strong>always</strong> allows
that direction of travel no matter any other condition, and may be valid in certain situations such as traveling
to staging where there is no O.S. section.
</p>
<p>
Select either Left or Right to proceed. On the next screen that appears, you will notice that the "Rules:"
area is blank, and that "Add New" is only button enabled. Press "Add New" now, and notice how the bottom half of the
screen is enabled for editing of this new rule.
</p>
<p>
Before we proceed to details on this rule, you will notice that "This rule ENABLED" is checked by default. You
may enable / disable individual rules at your whim, you mostly disable ones so that the information is not lost,
and you may in the future want to re-enable it.
</p>
<p>
Part of the design of your CTC system (which has nothing to do with this program) is determining where
the interlocking limits are in complex trackwork situations, such as parallel (or 3 or more) tracks with
multiple switches and crossovers. It is beyond the scope of this help in guiding you in designing
interlocking plants. For instance, it depends on how you want simultaneous moves to occur within
interlocking limits that may need to be considered.
</p>
<p>
<strong>Specifying a rule:</strong>
</p>
<p>
Under "--- ROUTE ---", you specify the O.S. section(s) traversed, and the switch alignment associated with the
O.S. section for that route. Order of specified O.S. section(s) is irrelevant. Include <strong>both</strong> switch alignments for this
O.S. section here, along with (at least) all alignments of the "terminating" O.S. section too. Therefore, for a passing
siding (for instance), there should be 4 rules in the direction of the other O.S. section associated with the passing siding.
</p>
<p>
Under "Occupancy sensors ... allowed." you specify other sensor(s) that also will be locked long that route. Mostly
none are needed, except in complex interlocking situations which is supported by this feature.
</p>
<p>
Under "--- Optional sensors... valid ---", specify any sensors that must be VALID to allow this rule to be valid.
You may (for instance) use JMRI Logix to create such a sensor for specific unusual situations.
<strong>Important:</strong> These optional sensors are <strong>not</strong> allocated as part of the rule.
They are just checked at the moment the dispatcher codes the O.S. section.
</p>
<p>
<strong>Final result: </strong> When the dispatcher codes this O.S. section, and a rule is selected as valid, the whole "path"
of that rule specified is fully <strong>allocated</strong>. The path consists of all of the O.S. occupancy sensors
specified in the individual O.S. sections, along with all of the occupancy sensors specified on this screen at the bottom for
this rule. <strong>Only</strong> as each of these occupancy sensors <strong>transition</strong> from occupied
to unoccupied is that corresponding occupancy sensor removed from the allocated list. This prevents other conflicting paths
in any rule anywhere from allocating any of these occupancy sensor(s).
</p>
<p>
In complex interlocking situations: as a train traverses the rule's occupancy sensor(s) and transited occupancy sensor(s) are released,
other rules that don't conflict with the remaining allocated occupancy sensors may be allowed before this train
has fully transited this whole rule, and the dispatcher may select these routes (rules) safely.
</p>
<a name="frmTUL" id="frmTUL"></a>
<h4>Turnout locking</h4>
<p>
<strong>Background:</strong>
On my layout for main line turnouts, I have a local push button for each DS-54 and DS-64 that locally requests
the turnout to "flip" the other way. By locally, I mean no computer involvement. I originally designed it
this way so that if the computer failed for any reason, the layout could still be operated without any
computer system involvement. This is fail safe: No computer, "Mother may I" via phones to the Dispatcher
with a magnet (or some such) board of the track plan for collision avoidance.
</p>
<p>
All of the main line turnouts on my layout use the other bit available of 2 available inputs for each turnout
on the DS-54 or DS-64 for feedback. JMRI's parlance for this is "Mode = INDIRECT" in the Turnouts table.
</p>
<p>
<strong>How "Lock implementation: Greg's" works in this situation (the ONLY supported possibility at this time):</strong>
</p>
<p>
If the JMRI software monitored the LocoNet network for turnout commands, the switch could not
be locked properly, because the local button generates no messages to LocoNet. However, with the
feedback available (INDIRECT), what my software does is when it sees a feedback message that disagrees
with the locked state of the turnout, it immediately send a countermand command to restore the turnout
to its proper locked state that the dispatcher wants/controls. As a consequence, an operator when
pushing the local push button while the dispatcher has the switch locked notices that the switch goes
about 1/2 way, and then returns to its locked position. Repeated pushing of the switch just repeats
this. The dispatcher will see the Switch indicators blink back and forth without input from the
dispatcher, so they know someone is trying to wrongly change the switch. One could say that by
the switch going 1/2 way, a train going over the switch would derail, and you'd be correct. But
since my layout has the push buttons right next to the switch it controls, hopefully an operator
won't attempt to purposely derail a train.
</p>
<p>
There are two main situations that need to be considered separately:
</p>
<p>
Turnout locks in an O.S. section:
</p>
<p>
This is the typical case, and requires nothing special be done. In the prototype, the O.S. section <strong>must be</strong> unoccupied
in order for a turnout to be unlocked. Locking a turnout can always occur at any time. There are two situations to be considered:
</p>
<ol>
<li>The turnout has local control but that is never granted by the dispatcher.</li>
<li>The turnout has local control that can be granted to the crews in the field by the dispatcher.</li>
</ol>
<p>
1. is for all main line turnouts typically, that do not go to a siding that is switched by the crews. In this way the turnout
is locked permanently, and the dispatcher cannot grant local control. In this case, press "Just" a locked turnout, and fields
are cleared that are not needed, which are fields Dispatcher sensor lock toggle, Dispatcher sensor unlocked
indicator. The field Actual turnout is required.
</p>
<p>
2. is for those turnouts that are normally locked by the dispatcher, but the local crews can ask
for local control to do switching.
</p>
<p>
Configure the rest of the screen as needed.
</p>
<p>
Turnout locks in a non O.S. section (and how to create them):
</p>
<p>
Just create the section that contains the turnout <strong>as if</strong> it was an O.S. section. Use a switch number
that is higher than the highest value you will use on the CTC machine, or for safety, use values starting with
1001. For the GUI column #, use the proper number to create both the code button and the lock/unlock toggle
switch in the proper place.
</p>
<p>
However, <strong>do not</strong> check and features except the Turnout Locking check box for this fake O.S.
section. This is how this is differentiated from the above true O.S. section lock.
</p>
<p>
When configuring the Code Button, you will be required to enter an occupancy sensor. Enter the occupancy sensor <Strong>containing</Strong> the turnout to be locked.
</p>
<p>
For this situation, the prototype <strong>required</strong> occupancy of that section to exist when unlock(s) of the turnout(s) are to occur. The
purpose of this on the prototype is safety: so that the Dispatcher does not accidentally unlock an unoccupied block and leave
it that way, thereby possibly causing a derailment sometime in the future, or for signals to not clear into this block
</p>
<p>
Feedbacks different check boxes:
</p>
<p>
Normally, the feedback value matches the commanded value. JMRI allows for both being backwards, and in order to
fix that, you put a check the "Inverted" column in the Turnouts Table in JMRI. However, in case the feedback value
is different than the commanded value, then you put a check in that column. The following table lists the possibilities:
</p>
<table>
<tr>
<th>Command:</th>
<th>Feedback:</th>
<th>JMRI Turnout inverted checked:</th>
<th>CTCEditor feedbacks different checked:</th>
</tr>
<tr>
<td>Normal</td>
<td>Normal</td>
<td>No</td>
<td>No</td>
</tr>
<tr>
<td>Reversed</td>
<td>Reversed</td>
<td>Yes</td>
<td>No</td>
</tr>
<tr>
<td>Normal</td>
<td>Reversed</td>
<td>No</td>
<td>Yes</td>
</tr>
<tr>
<td>Reversed</td>
<td>Normal</td>
<td>Yes</td>
<td>Yes</td>
</tr>
</table>
<a name="frmIL" id="frmIL"></a>
<h4>Indication locking</h4>
<p>
Defines any additional locking of an O.S. section above and beyond what is normally expected
by this system.
</p>
<p>
As indicated on the screen, specify the signal head(s) / signal mast(s) that when any are
non-red, the O.S. section is considered indication locked. When an O.S. section is locked
this way, the turnout and turnout lock/unlock functions are disabled so long as any of these are non-red.
</p>
<a name="ctcFiles" id="ctcFiles"></a>
<h2>Files</h2>
<p>
=== Discuss file storage located at user files location, ctc directory. ===
Say that it's in the user files location . See "Help/Locations..."
That within Help/Locations you have a "ctc" directory which is under "user files location"
The 3 files are there.
</p>
<p>
=== Describe the 3 Editor files, especially CTCSystem.xml ===
DON'T DESCRIBE 3rd file of virtual signals, its deprecated.
</p>
<p>
=== Describe the CTC integration of sensors and a populated PE panel. Warn
about the "GUI Generated before" feature and its side effects. Namely, a different panel
object. ===
GUi file (don't load more than once), sensors(no danger here, can merge at will).
Get your O.S. section list DONE to the BEST of your knowledge, then load GUIObjects.xml panel
in, and review the results. If you are not happy, then DELETE the panel, save the panel
file, and re-iterate the process (i.e. CTCEditor, write files, etc.).
</p>
<p>
=== The virtual signal file may no longer be needed. The recommendation of
a functional ABS implementation means that the required signals already exist. ===
</p>
<a name="ctcMain" id="ctcMain"></a>
<h2>CTCMain</h2>
<p>
=== Needs to cover starting CTCMain from either the Tools menu or using
a startup action, which can be either real time or delayed by adding a
button to the PP main panel. ===
(See my 3 captured images in xfer!)
REMEMBER: Before you start CTC runtime, you NEED to load the panel.
IDEALLY: Before you start CTC Editor, you ALSO load the panel to get
reference checking of your JMRI objects (turnouts, sensors, etc.).
Also, explain how to put up the "two buttons" on the main JMRI screen
for convienence during development.
</p>
<p>
=== Include the three global icons: Debug, Reload and Fleeting. Mention
using the system console to look for errors, especially during CTCMain
startup.===
Explain purpose of buttons, and whether or not they want them at all?
Reload and debug are a convience and can be removed once development is complete.
Fleeting is a concept within "normal" CTC, and may or not be useful. Why?
Most MODEL (not prototype) dispatchers don't use it even if available.
</p>
<a name="ctcDefinitions" id="ctcDefinitions"></a>
<h2>Definitions</h2>
<dl>
<dt>Interlocking</dt>
<dd>ddd</dd>
<dt>Running time</dt>
<dd>ddd</dd>
</dl>
<!--#include virtual="/Footer" -->
</div><!-- closes #mainContent-->
</div><!-- closes #mBody-->
</body>
</html>