Block tracking neither knows about nor cares about trains. ?Its responsibly is to transfer the block value from the source block to the next block using direction of travel based on occupancy changes. ?It provides occupancy information including the current block value, direction of travel and block relationship information to higher processes such as layout blocks and dispatcher.
Unidirectional blocks are a logical concept and have no impact. ?Block tracking is based on physical inputs: ?block occupancy and turnout position.
I don¡¯t have any insight yet for the dispatcher issues.
Dave Sand
On Jul 30, 2018, at 8:04 AM, jamespetts via Groups.Io <jamespetts@...> wrote:
Thank you both for your replies.
I am unclear as to the nature, consequences and significance of the directional ambiguity issue. Is the issue that JMRI does not understand which way?that a train is?facing?so that, when it begins to move, it might move in either direction so far as JMRI is concerned? If so, is there any way of using the?RailCom feedback that is designed to be able to broadcast this information to resolve this ambiguity? If not, is there any other way of providing this?information to JMRI? What would be the significance of unidirectional blocks and this kind of ambiguity in that situation??
In relation to the consequences of this issue, presumably the ambiguity is resolved as soon as a train moves from one block to another (in this case,?from front to left curve and from rear to right curve), so I am not sure how splitting the curves into multiple blocks could assist here; can anyone?elaborate? Likewise, given that the failures to stop/sudden stops occur that I reported above occur?after?the train has run through all of its blocks, by?which point JMRI has had plenty of data from which to infer the direction of travel, do you really think that this inconsistent behaviour is caused by there?being some direction variable set to an unknown state?
I should note that the failure to stop and the sudden stop occurred when there was only one train on the layout. With two trains on the layout, the?behaviour was as expected: the trains did change speed in response to (virtual) signals, but this was the correct behaviour. I am not sure that I?understand what about the block/transit logic would require six sections for smooth running: it is very difficult for me to understand what is really?happening (and what I need to do to make things work as desired) without being able to understand the actual underlying logic used, which does not?appear to be described completely by the documentation on transits, nor can I readily infer this from the user interface (noting in the documentation or?user interface, for example, describes a reason for having to have no fewer than six sections in a circuit layout). Does anybody know what part(s) of the?code in the Github repository deal with this specific aspect of things so that I can try to read the code and piece together the underlying logic myself?
In relation to two throttles being open, does anyone have any idea how this error could have arisen by doing nothing other than starting and then?restarting an Active Train? Is this a known bug, or is there something specific that I might have done wrong in order to cause this?
In relation to warrant preferences, I should clarify that I am not using warrants, as I understand the warrant system to be mutually exclusive with the?dispatcher. However, I have taken care to set the scale (1:148) correctly in the preferences.?
Can I ask why a fast stop (rather than a controlled, profiled stop) would result from a train catching up with another train? This is not the behaviour that I?have actually experienced: signal stops were smooth and correct: it was stops at the end of the transit that were sudden - but only when there was no?other train on the layout. When there were two trains on the layout, each train would stop gradually at the end of its transit, and stop far further into the?final block (but never beyond the end of it) than with only one train on the layout, which really makes no sense to me at all and is certainly not behaviour?that can be inferred from anything in any of the documentation that I have seen regarding the dispatcher or anything apparent in the user interface.
