[Railcat]

I have read this part in manual but still don't know how to use it correctly. I've made a test but seem no effect. What's the difference between this command and $wait? Can anyone help me? An example would be appreciated. :sign_thanks:

[Gro.Bi]

I am also interested in using the $waitany command in timetables. I have read the documentation in the OR manual and implemented $waitany to my timetables. In test runs it seems to have no effect, or at least I did something wrong.
Is there eventually more documentation about that or even an example?

Regards,
Gro.Bi

[roeter]

A $wait command will make a train wait for one specific other train, with the other train explicitly defined in the command.
A $waitany command will, as the name suggest, make a train wait for any train which, at the time the waitany command is checked, occupies the path as defined in the command. The main condition for the $waitany command is that the path defined in the command must have an overlap with the train's own path, otherwise the program cannot determine the proper positition where to wait.

Three examples of how it may be used.
First, a branch without any loops or sidings and without signalling, where only one train at a time is allowed (known as "one train in steam" operation in the UK). In this situation, you want to stop a second train from accessing this branch if any other train is there already. The path for the $waitany command must run from the last switch where trains can pass, all the way to the end of the branch. Also, the qualifier /both must be set as the command needs to apply to any train on the branch regardless of its direction.
A train which has the $waitany set for this situation will wait until the branch is clear of any other train.

Another example is a single track section ahead of the train, where you want to ensure that priority is given to trains in a specific direction. In this situation, the path for the command should start somewhere beyond the single track section and lead all the way to switch where the single track section starts. The direction of the path must be opposite to the direction of the train. The path must be long enough to ensure clear passage of opposite trains. This should only be used for single track sections on an otherwise double track route, like a bridge or a tunnel. Using it for loops on an otherwise single track route could lead to problems between this command and the deadlock processing.

Third example is exit from a siding, where you want to ensure the train exiting the siding will not delay any train on the main line. In this situation, the path for the command must start back on the main line and must include the switch where the train gains access from the siding onto the main line. The path must be in the same direction as that of the train.

Basically, if all trains in the timetable are properly timed, there is no need to use the $waitany command. But if there are trains with limited timing, e.g. freight trains which only have a start time, the $waitany command can be used to regulate priorities.

Regards,
Rob Roeterdink

[Gro.Bi]

Hi Rob,

many thanks for the detailed explanations. An essential question came in my mind when I compared it to my previous procedure:

• I used the command $waitany=path in which 'path' is the path that is actually used by the trains that are intended to wait
  
• I now assume that the path that is referred by the $waitany command has to be a 'special' path that is not intended to be driven by trains? (i.e. not the path of the train that has to wait)

Regards
Gro.Bi

[roeter]

Gro.Bi, on 14 October 2019 - 11:25 AM, said:

I now assume that the path that is referred by the $waitany command has to be a 'special' path that is not intended to be driven by trains? (i.e. not the path of the train that has to wait)

That's right. The path referred to by the $waitany command is indeed not used as such by any train, but is part of path(s) for other trains. The exact extend of this path depends on the situation, e.g. in situations two and three it would depend on how far out you want to check for other trains. In situation one the path would lead up to the end of the branch.

Regards,
Rob Roeterdink

[Gro.Bi]

Hi Rob,

thanks again for explanations. I will try to modify my timetables accordingly and will see if the result is then acceptable.

However, one question won't get out of my mind:

Quote

I used the command $waitany=path in which 'path' is the path that is actually used by the trains that are intended to wait

One of the situations in that I tried to use $waitany is slightly different from the examples: On a double track line run passenger trains as well as freight trains each in both directions. One of the tracks is exclusively used for westbound trains, the other one for eastbound trains. Because freight trains run slowly, they have to wait on adequate locations to let passenger trains in the same direction pass.
Please see attached an example of a timetable for that situation.

Would it be somehow possible to realize this without the need for creating 'waiting' paths for every location?
Maybe the $waitany could be limited to be only effective in situations when there is actually a train on the path (as shown by the red proceeding lines in the dispatcher window)?

Regards,
Gro.Bi

Attached File(s)

•  waitany-timetable.txt (346bytes)
  Number of downloads: 337

[roeter]

Gro.Bi, on 15 October 2019 - 11:42 AM, said:

Because freight trains run slowly, they have to wait on adequate locations to let passenger trains in the same direction pass.

$waitany is not really an adequate function for this type of operation.
To use $waitany to check on trains which require to overtake the freight train means you have to run the freigh train into each and every loop where it might have to wait, as it can only check if it needs to wait when in the loop. But if it does not have to wait, you don't want to run it into the loop.
You cannot use $waitany to force the train into the loop if a wait is required, but to continue on the main line if there is no need to wait. That would require a completely new function, and a quite complicated one at that.
All you can do for now is to work out the timings and fully preset all required overtake actions, using normal $wait commands.
You will need different paths for different freight trains, depending on which loops they have to use to allow overtaking.

Regards,
Rob Roeterdink

[Gro.Bi]

Hi Rob,

roeter, on 15 October 2019 - 03:08 PM, said:

You cannot use $waitany to force the train into the loop if a wait is required, but to continue on the main line if there is no need to wait.

It's a pity that it is too complicated to realize that. Maybe the idea 'Priorities for trains' (#147 in the Open Rails Roadmap) would be a solution (someday in the future)?
Anyway, I'll try to come as close as possible to acceptable situations in my timetables, using the $waitany as you described above. Thank you for the explanations and furthermore for the timetable mode in general, which in my opinion is a real superior alternative to the activity mode.

Regards,
Gro.Bi

[roeter]

Gro.Bi, on 16 October 2019 - 11:51 AM, said:

Maybe the idea 'Priorities for trains' (#147 in the Open Rails Roadmap) would be a solution (someday in the future)?

Yes, it would - but that's the complicated new function I was referring to. I am occasionally thinking about how that could be done, but the more I think about it, the more complex it becomes. It's a long way down the road.

Regards,
Rob Roeterdink

[VicenteIR]

Hi!

Could the command be defined more than once for stop field? Something like $waitany=<path_A> $waitany = <path_B>?

Thanks
Oleg