Enhanced Interlocking Tower paths not resetting

davidbird

ex-Chilwellian
I'm using pguy's TRC Enhanced Interlocking Tower and associated driver commands. All are the latest versions. I'm also using the built-in IT SetPath and IT Cancel Path rules.
This is in the latest version of TRS2019, build 104261

I have found that whilst everything works perfectly with trains passing through the paths, when a path is cancelled without a train - ie by using the IT Path Cancel driver command or IT Path Cancel rule - the junctions do not reset direction. This is not a problem, as they would be reset on the next "set path" command.

But any signals that are set as objects "external to path" also do not reset, they stay on a "proceed" setting. This does cause problems, as any train approaching this signal can just proceed without a path actually set.

Any ideas?
 
This might be windows again as it has done an update. My trains that need to reverse to an industry go forward first and then reverse through the industry without loading, they load in forward direction ok. Also have the same situation as you and when exit driver the levers are in the wrong position when back in surveyor. ?This is in build 100464.
 
Just a suggestion : if you encounter any difficulty with one of the pguy's assets, consider writting him a PM ; he always answers.
 
Hi Davidbird.

I clearly do not understand what you mean by "... when a path is cancelled without a train …" as I don't see how this can happen. If you are using the IT Path cancel driver command, the driver command is executed inside a train schedule and the cancel path operation always reference the current train as the train for which the path must be cancelled. I have also looked at the script code for IT Path cancel rule (Interlocking tower setpath rule with cancel option) and the rule request a valid train reference to execute the cancel path request. Further more, both command and rule will internally call a specific common CancelPath routine inside the tower object, and this routine receives two arguments : the path name and the reference to the train. If either the train reference is omitted (has a null value) or references a train currently not owning the path, the request will be rejected.
So there are at least two valid reasons why you cannot cancel a path without a train reference …

The only situation where you can cancel a path without any train reference is by using the interlocking tower manager, that accepts a cancel request without a train reference for a path currently set with no train owner (which is an abnormal situation) and the IT manager enables to fix at run time such problem. This is internally done by calling a very specific script code that bypass the train reference normal checks and calls directly some other internal path cancellation routine, but these internal routine is the same one that is called during normal cancel operation, and I do not see any reason why it should forget either reseting junctions or reseting external signals.

So thanks for explaining in more details how you get some active paths without any train and how you cancel such paths in order to understand your problem.

Regards.
Pierre.
 
Hi Pierre
I have also seen the same problem. Build 100464 all was working and then windows did an update and that is when weird things started to happen on my route.
 
Hi Davidbird.

I clearly do not understand what you mean by "... when a path is cancelled without a train …" as I don't see how this can happen.

Apologies, I've obviously not been clear enough. I should have said "when a path, allocated to a train, is cancelled without the train completing the path"

Does this help?
 
Hi.

Now I understand the problem, and after verification I confirm that there is a problem for paths cancelled before train completing path where junctions and external objects are not reset to their return state. Problem has been identified and should be fixed in a soon to come new version v65 of EITs.
 
Back
Top