The issue is that the block system does not know about any trains or their expected direction of travel. It is only looking at how blocks become occupied and unoccupied. Based on the sequence, it determines the direction and uses that to transfer the block values.
"WARN - count of 2 ACTIVE neightbors with proper direction can't be handled for block Right curve but maybe it can be determined when another block becomes free"
If ¡°Right curve¡± was split into two blocks, such as Right Curve Back and Right Curve Front, then the direction of travel is not ambiguous. At least not until one train catches the other train.
When the front train leaves, its block becomes inactive which means the direction for the rear train can now be determined which generates the ¡°LATE¡± value message.
Dave Sand
toggle quoted message
Show quoted text
On Jul 29, 2018, at 4:47 PM, jamespetts via Groups.Io <jamespetts@...> wrote:
Thank you for your reply. I am aware of the issue with separate blocks for turnouts, which is why I am testing with a simple loop representation of the layout at present. I can add the Logix simulation for turnout blocks once I have consistent behaviour with just the basic loop, and that is the principal concern at present.
In relation to the number of blocks, I am not entirely clear why the behaviour should be inconsistent in the way reported above as a result of the number of blocks - can you elaborate? You do correctly surmise the block description of the layout. To answer your other question, in this setup at present, all trains go only clockwise and there are only clockwise transits set up.
As to the corrected BR-2003 signal aspects, I have already downloaded the fix for this from the MERG forum, but it is good to note that this will be included in the next official release so that I do not have to remember to patch this manually in future.
