Serge NOEL
150 lines
7.0 KiB
Plaintext
150 lines
7.0 KiB
Plaintext
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy for HTML5 for Apple macOS version 5.8.0">
|
|
<title>JMRI: Block Tracking</title>
|
|
<meta name="Author" content="Bob Jacobsen">
|
|
<meta name="keywords" content="java model railroad JMRI Block tracking">
|
|
<!--#include virtual="/help/en/parts/Style.shtml" -->
|
|
</head>
|
|
<body>
|
|
<!--#include virtual="/help/en/parts/Header.shtml" -->
|
|
|
|
<div id="mBody">
|
|
<!--#include virtual="Sidebar.shtml" -->
|
|
|
|
<div id="mainContent">
|
|
<h2>JMRI: Block Tracking</h2>
|
|
|
|
<h3>Background Information</h3>
|
|
Model railroad control systems generally can't tell you which train occupies a particular
|
|
piece of track at any given time.
|
|
<p>This is unfortunate, because there are lots of reasons you might want to know. For
|
|
example, you might want to command any train that reaches a particular red signal to stop.
|
|
But you can't do that unless you know <em>which</em> train it is that is reaching the
|
|
signal.</p>
|
|
|
|
<h2>Basic Concepts</h2>
|
|
Imagine a simple loop of track that's been wired with occupancy sensors on individual
|
|
segments of track, which we'll call "Blocks". Imagine the train is in Block A, and will
|
|
shortly move to Block B, then C.
|
|
<p>At first the sensor for Block A is showing active. As the train moves into Block B, the
|
|
Sensor for B will go active. When the train has completely left A, it's sensor will go
|
|
inactive etc.</p>
|
|
|
|
<p>Although a particular Block only knows whether it's active or not (occupied or not), by
|
|
also looking at the occupancy of the adjacent Blocks it can tell more. In the example above,
|
|
if the code knew that train 321 was in Block A, when Block B goes active, the program can
|
|
infer that 321 is now also in Block B.</p>
|
|
|
|
<p>This doesn't always work, unfortunately. Imagine the case above, where there is both a
|
|
train in Block A and also a train in Block C. When Block B goes from inactive to active
|
|
(unoccupied to occupied), which train moved in? The one from A, or the one from C?</p>
|
|
|
|
<p>Some of this ambiguity can be removed by careful arrangement of the detection Blocks, by
|
|
accepting limitations on how trains can run (or how short Blocks have to be), and by using
|
|
more intelligent logic that thinks about the direction and priority of trains. But it's clear
|
|
that even straight track poses some problems.</p>
|
|
|
|
<h2>JMRI Block Tools</h2>
|
|
|
|
<p>The Block table entries include a <strong>Value</strong> field. The contents of the field will be copied
|
|
to the next block using block tracking. The content of the value field can come from several
|
|
sources.</p>
|
|
|
|
<ul>
|
|
<li>Text is entered directly in the Block table.</li>
|
|
<li>Double clicking on a Block Contents icon on a Panel Editor or Layout Editor panel and
|
|
entering text.</li>
|
|
<li>Using a script or LogixNG to set a value.
|
|
<li>Use the Dispatcher options to place names or roster entries in the starting block.
|
|
<li>If a <strong>Reporter</strong> is assigned to the block, it can provide a value.</li>
|
|
<li>Use the <strong>SetBlockValues.py</strong> script to request block values as needed.
|
|
<strong>Note</strong>: There is setup work needed to enable this feature. The details are
|
|
in the script comments.</li>
|
|
</ul>
|
|
|
|
<h3>blockvalues.xml</h3>
|
|
|
|
<p>Block values are <strong>not</strong> stored with the rest of the layout data. The
|
|
<em>blockvalues.xml</em> file is used to provide persistence of the block values between
|
|
PanelPro sessions.</p>
|
|
|
|
<p>During the PanelPro shutdown, the current values of occupied blocks is written to the
|
|
blockvalues.xml file.</p>
|
|
|
|
<p>After PanelPro startup and layout data loading is complete, the values are read from the
|
|
blockvalues.xml file and applied to the blocks based on a set of rules. The rules are based
|
|
on the Block Table
|
|
<a href="../../../package/jmri/jmrit/beantable/BlockTable.shtml#block_values_menu">Values</a>
|
|
menu.</p>
|
|
|
|
<h3>Block Tracking Messages</h3>
|
|
|
|
<p>There are two messages displayed on the JMRI system console when block tracking is paused.</p>
|
|
|
|
<pre>
|
|
WARN - count of 2 ACTIVE neighbors with proper direction can't be handled for block B-Alpha-Main but maybe it can be determined when another block becomes free
|
|
INFO - Block B-Alpha-Main gets LATE new value from B-Alpha-Left, direction= East
|
|
</pre>
|
|
|
|
|
|
<p>As described above, a block becoming occupied between two occupied blocks can be a problem.
|
|
Which block should provide the block value? There are two scenarios based on the current
|
|
direction for each block. <strong>Note</strong>: Block directions are compass directions.</p>
|
|
|
|
<dl>
|
|
<dt>Same Direction</dt>
|
|
<dd>
|
|
<p>Both blocks have the same general direction, ±45°. The new value comes from
|
|
the following block. The messages are not displayed.</p>
|
|
</dd>
|
|
|
|
<dt>Different Direction</dt>
|
|
<dd>
|
|
<p>The new value comes from whichever neighbor block becomes unoccupied. This is treated
|
|
as the train has finished arriving. <strong>Note</strong>: This does not work when two
|
|
trains are chasing each other in a circle with a limited number of blocks. At least eight
|
|
blocks are required with no more than 45° per block.</p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<h2>Issues</h2>
|
|
|
|
<ul>
|
|
<li>Doesn't handle a train pulling in behind another well:
|
|
<ul>
|
|
<li>When the 2nd train arrives, the Sensor is already active, so the value is unchanged
|
|
(but the value can only be a single object anyway)</li>
|
|
|
|
<li>When the 1st train leaves, the Sensor stays active, so the value remains that of
|
|
the 1st train</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li>The assumption is that a train will only go through a set turnout. For example, a train
|
|
could come into the turnout Block from the main even if the turnout is set to the siding.
|
|
(Ignoring those layouts where this would cause a short; it doesn't do so on all
|
|
layouts)</li>
|
|
|
|
<li>Does not handle closely-following trains where there is only one electrical Block per
|
|
Signal. To do this, it probably needs some type of "assume a train doesn't back up" logic.
|
|
A better solution is to have multiple sensors and Block objects between each signal
|
|
head.</li>
|
|
|
|
<li>If a train reverses in a Block and goes back the way it came (e.g. b1 to b2 to b1), the
|
|
Block that's re-entered will get an updated direction, but the direction of this Block (b2
|
|
in the example) is not updated. In other words, we're not noticing that the train must have
|
|
reversed to go back out.</li>
|
|
</ul>
|
|
|
|
|
|
<!--#include virtual="/help/en/parts/Footer.shtml" -->
|
|
</div>
|
|
<!-- closes #mainContent-->
|
|
</div>
|
|
<!-- closes #mBody-->
|
|
<script src="/js/help.js"></script>
|
|
</body>
|
|
</html>
|