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 which train it is that is reaching the signal.
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.
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.
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?
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.
The Block table entries include a Value 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.
Block values are not stored with the rest of the layout data. The blockvalues.xml file is used to provide persistence of the block values between PanelPro sessions.
During the PanelPro shutdown, the current values of occupied blocks is written to the blockvalues.xml file.
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 Values menu.
There are two messages displayed on the JMRI system console when block tracking is paused.
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
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. Note: Block directions are compass directions.
Both blocks have the same general direction, ±45°. The new value comes from the following block. The messages are not displayed.
The new value comes from whichever neighbor block becomes unoccupied. This is treated as the train has finished arriving. Note: 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.