[kafovofa]

In an attempt to use timetable mode with the Bala sub, I've adjusted all the signalnumclearahead values up from 6 (where they are by default) to 18 and I'm still ending up with my first northbound train stuck standing in front of the station at Washago as in the picture below. The opposing train is taking the passing path for it's siding correctly; however, as I adjusted the value up it took sidings farther and farther up the track (at first it was taking the siding at Sparrow Lake, just north of Washago).

https://imgur.com/XFOEJWP.png

Is there anything more I can do? What should I be looking for in the sigcfg file to attempt to troubleshoot this?

[rickloader]

I`m not familiar with North American signalling, or Bala, nor have I managed many single track meets.
The signal number clear ahead is not normally used to regulate trains in timetable mode. SNCA = 6 is high. I run on 3 or 4. The problem won`t be in the sigcfg if the signals are working.
Most likely the opposing train `s path has claimed the track needed by the Northbound.
There are several commands to prevent trains claiming too much track. Look in the manual for $hold, $wait, $noclaim
It would be helpful to post the dispatcher HUD (F5 then several shift F5)
also the dispatch viewer ctrl 9
These screens can give clues as to why a signal isn`t clearing. Signalling is good in ORTS , and it does take a while to learn managing trains in timetable mode.
rick
edit: you mentioned "passing path" - I don`t think timetable mode uses passing paths, but instead the commands like $wait.

[kafovofa]

Ok, I've created a much simpler timetable to test this. SB now has a wait command for NB, and the SNCA is set to 4 for now. I'm having trouble bringing up dispatcher view, but that might be because I'm running the timetable in singleplayer. When running trains on the single-tracked RMD West, I have no waits defined, only passing paths, and the signaling handles everything but train lengths flawlessly. I know passing paths sort-of work in timetable mode on some of my single-tracked routes, but that doesn't mean I should be doing things that way. I certainly have a lot to learn about the commands in timetable mode still to make use of the signalling. Here's the dispatcher HUD for just the two trains, and the player train I'm using to watch them. I noticed that hold affects signals at stations, which is where NB is getting stuck, so maybe I should fiddle with that.

Edit: Washago is in the middle of the longest stretch of single-track between sidings, which I suspect is why it's where I'm finding my train stopped there. There's definitely something that I'm not seeing just yet.

https://i.imgur.com/m5ATZdM.jpg

[kafovofa]

https://i.imgur.com/o7u26on.jpg

Changing which train waits for the other results in one of them getting stuck at Washago.

[rickloader]

Here is an extract from a post by Rob Roeterdink explaining the dispatcher screen. I hope he won`t mind me re-posting it. I have found it invaluable


train : Internal train number, with P=Passenger and F=Freight.

Travelled : distance travelled.
Gives a indication if all is well. If a train started an hour ago and 'travelled' is still 0.0, something's clearly wrong.

Speed : present speed.

Max : max. allowed speed.

AI Mode : gives an indication of what the train is 'doing'.
Possible states :
INI : train is initializing. Normally you would not see this.
STP : train is stopped other than in a station. The reason for the stop is shown in "Authority".
BRK : train is preparing to stop. Does not mean it is actually braking, but it 'knows' it has to stop, or at least reduce speed, soon.
Reason, and distance to the related position, are shown in "Authority" and "Distance".
ACC : train is accelerating, either away from a stop or because of a raise in allowed speed.
RUN : train is running at allowed speed.
FOL : train is following another train in the same signal section.
Its speed is now derived from the speed of the train ahead.
STA : train is stopped in station.
WTP : train is stopped at waiting point.
EOP : train is approaching end of path.


AI data : shows throttle and brake positions when train is running, but shows departure time (booked) when train is stopped at station or waiting point.

Mode : SIGN (signal) or NODE - same as for player train.
EDIT : when relevant, this field also shows delay (in minutes), e.g. S+05 mean Signal mode, 5 mins. delay.

Auth : End of "authorization" info - that is, the reason why the train is preparing to stop or slow down.
Possible reasons are :
SPDL : speed limit imposed by speedsign.
SIGL : speed limit imposed by signal.
STOP : signal set at state "STOP".
REST : signal set at state "RESTRICTED" (train is to reduce speed at approaching this signal).
EOA : end of authority - generally only occurs in non-signalled routes or area, where authority is based on NODE mode and not SIGNAL mode.
STAT : station or waiting point.
TRAH : train ahead.
EOR : end of train's route, or subroute in case the train approaches a reversal point.


Distance : distance to the authority location.

Signal : aspect of next signal (if any).

Distance : distance to this signal.
Note that if signal state is STOP, and it is the next authority limit, there is a difference of about 30m. between authority and signal distance. This is the 'safety margin' that AI trains keep to avoid accidently passing a singal at danger.

Consist : the first bit of the train's consist name.

Path : the state of the train's path.
The figure left of the "=" sign is the train's present subpath counter : a train's path is split into subpaths when its path contains reversal or waiting points.
The details between { and } are the actual path.
Following the final } can be x<N>, this indicates that at the end of this path the train will move on to the subpath as indicated.

Path details :
The path shows all trackcircuit sections which build this train's path. Trackcircuit sections are bounded by nodes, signals or cross-overs, or end-of-track.
Each section is indicated by its type :
- is plain train section.
> is switch (no distinction is made for facing or trailing switch).
+ is crossover.
[ is end-of-track.

Following each section is the section state. Numbers in this state refer to the train numbers as shown at the start of each row.
Below, <n> indicates a such a number.
<n> section is occupied by train <n>.
(<n>) section is reserved for train <n>.
# (either with <n> or on its own) section is claimed by a train which is waiting for a signal.
& (always in combination with <n>) section is occupied by more than one train.
deadlock info (always linked to a switch node) :
* possible deadlock location - start of a single track section shared with a train running in opposite direction.
^ active deadlock - train from opposite direction is occupying or has reserved at least part of the common single track section.
Train will be stopped at this location - generally at the last signal ahead of this node.
~ active deadlock at that location for other train - can be significant as this other train can block this train's path.

[rickloader]

In each of the 2 dispatcher examples kafovofa posted above , under "path" the numbers in brackets (2) show the ID of the train causing the conflict,and that the section is reserved for the opposing train. ^ and* show that there is actually an active deadlock. So the signals are correctly at stop because the opposing train has claimed the path. It seems that the $wait command is not working either because the syntax is incorrect, or this command is inappropriate.
Not seeing the ctrl 9 screen the track layout isn`t clear to me - is there a station at the meet for the $wait?
If there is no station, the path will need to be ended at the train crossing point, in the #dispose field and a new continuation train and path $formed with the wait command.
Well, that`s my suggestion, but I`m happy to be corrected as I`m still learning about time tables. Also I don`t have much experience of single track meets.
If needed, I can try to replicate this scenario on my test route.
rick

[kafovofa]

Thank you! That's fantastic information, but it's going to take me a bit to understand it and fiddle with it. In the meantime here's an overview of one of the paths and the troubled sections in trackviewer. I never doubted they were somehow choosing the same path; however, upon close examination with the free-camera, the points are correctly set to route the train getting stuck at Washago around the train that is taking a siding.

https://i.imgur.com/RT1HG69.png
This is an overview of both of the passing sidings north and south of Washago.

https://i.imgur.com/TekNYC5.png
This is the protected siding north of Washago.

https://i.imgur.com/eX6lsU8.png
This is the protected siding south of Washago.

https://i.imgur.com/DJ3jOiL.png
This is an overview of Washago. The siding on the left is unprotected, and I have not directed trains to use it at all. The Newmarket Sub runs off to the left.

https://i.imgur.com/faQ5FTZ.png
This is a closeup of the two opposing signals at which trains get stopped at depending on which train I set the wait for. VIA Washago is a station and may be what's confusing me here.

[kafovofa]

Quick Update: I removed the passing paths at Smail. I set NB's path to the siding, set SB's path to the main, and told NB to wait for SB in the timetable. There are no changes in the deadlock, so I'm going to try to learn how to use forms to create a new NB out of the old NB at Smail next.

[rickloader]

Hi! I`ve been reading the manual - looks like I was wrong to say timetables don`t use passing paths:they do. sorry. But it seems you have to use a different loop track for each train for a wait to work. From your Trackviewer screens signals at Washago look awkward and almost invite deadlock, being outside of the loop on plain single track.
The loop at Smail looks better.
I will play with single track meets on my test route over the next couple of days. Maybe someone else will be able to advise us? Here is the relevant section from the Manual for timetables:

"Wait Commands and Passing Paths
From the location where the ‘wait’ or ‘follow’ is defined, a search is made for the first common section for
both trains, following on from a section where the paths are not common.
However, on single track routes with passing loops where ‘passing paths’ are defined for both trains, the
main path of the trains will run over the same tracks in the passing loops and therefore no not-common
sections will be found. As a result, the waiting point cannot find a location for the train to wait and therefore
the procedure will not work.
If waiting points are used on single track lines, the trains must have their paths running over different
tracks through the passing loop in order for the waiting points to work properly.
It is a matter of choice by the timetable creator to either pre-set passing locations using the wait commands,
or let the system work out the passing locations using the passing paths"

[roeter]

Yes, that last paragraph probably holds the key to this problem.
From what I have read above, it looks like a combination of $wait commands and passing paths have been used in this timetable. That can indeed lead to lock-ups like the one encountered.
My advice would be to repeat the test with either the $wait commands removed (and so let the deadlock processing work out where the trains meet), or with the passing paths removed and replaced by fixed paths and the use of $wait commands to preset meet locations.
What option to use depends on what kind of train control you want : random meets at any of the possible locations or preset fixed meets defined in the timetable. The first would perhaps be more appropriate for pure freight routes, but a passenger timetable should only use the latter option.

By the way, an SNCA value of 18 does seem a bit over the top, the F5 display does confirm this as the trains do clear their route quite a long way ahead. A value of 6 is more appropriate. If the problem is caused by a combination of passing path and $wait command, changing the SNCA value will not have any effect on this anyway.

Regards,
Rob Roeterdink