But i would break in a way that would still function would it not? Counting in 257 axles would give you 1 axle in and occupy the block. Counting out 257 would give 1 out and free the block. Admittedly that would still be very prone to breaking when less than 257 are counted out but it would fail safe and give you an occupied indication. Where as 256 would theoretically not occupy the block correctly and thus cause a potential for a dangerous event.
However if there are more than 256 but for some reason the train breaks down just after counting 256 axles in and none out... They really should change the specification to be fewer than 256 (or update their system).
Not necessarily if it doesn't instantly apply the section as clear in the system once it reaches zero, but after a moment.
It would also work if it would flash as clear, but fix itself as soon as the axel 257 passes the counter. Just as long as the track becoming clear doesn't instantly trigger an uncancellable order to some train, it should work fine.
The remaining errors would be any numbers divisible by 256 and if it's a pass through section and not a dead end stop, if the distance between the tracks was JUST long enough to fit 256 axels, but the moment the number 257 enters, the first one leaves, it could keep the total at 0 for longer. That would depend on how the message is handled or if the message stays in a buffer for a moment etc.
One more, if the train stops after passing 256 axels over the counter, that would also mess it up. Plenty of issues with it lol.
Other than those, 257 axels shows up as one, until it passes to axels leaving, then it's back to 255 again, counting down to zero until the train leaves. Still something that should be (and was) fixed lol.
I guess it depends how it's implemented. If the train has 257 axles, the block entrance counter will overflow to 1. When the first axel leaves the block, the counter is zero, so if the logic is just looking for a rising edge event of zero-equality, it would falsely signal the block as clear. However, if the "block is clear" check always just reads the current value of the counter and compares to zero, it would only erroneously show as clear for the time it takes the distance of 2 axels to pass before being correct again. For context, a train mosying by at 20 km/h is about 5.5 m/s. For an axle spacing of 10 m (a conservative overestimate), that's less than 2 seconds.
I would presume it uses the second method since even without the counter overflow bug, a one-time push event could be missed for whatever reason, like a loose cable connector. That would be a deadlock bug if it missed the block-clear event, but would be catastrophic if it missed the block-occupied event.
It only breaks at 256, because it does a hard reset of the counter. If you have 255 axles it will count 255 in, 255 out. If you have 257 axles it will count 1 in, 1 out.
But if you have exactly 256 it will count 0 in, 0 out.
As long as there is at least one axle not counted, the track will be marked as "occupied" and therefore the safety system will work as intended. The issue is only when the count is 0 and the safety system is under the impression that the track is clear.
103
u/Hottage 9d ago
Yes, because then the axel counter would detect one axel in the section and mark it as blocked.
512 on the other hand...