Timetable Mode Coupling in Signalled Routes Enabling Coupling operations for beginners
#1
Posted 31 July 2020 - 04:36 AM
My understanding is this. (Am I correct?)
In coupling operations $attach $detach $pickup $transfer Runround (ADT for short) a train will not pass a normal stop signal to complete an ADT when it is in auto signal mode ie in a signalled route.
A signalled route needs the Sigscr.dat modifying to enable callon for ADT as in the manual 10.15.3 TrainHasCallon for open line and TrainHasCallon_Restricted for platforms.
From the website query, it seems that ordinary users face difficulties in modifying signal scripts, and even worse may be baffled why their train is blocked by a red signal.
Timetable mode is a magnificent part of OR. What can we do to make coupling operations accessible to ordinary users?
Rick
#2
Posted 31 July 2020 - 03:21 PM

At "platform 1 left"(very bottom track in diagram), another train is waiting for activation, at that time, for moving to the left.
#3
Posted 01 August 2020 - 01:50 AM
There are 2 modes in timetables Auto signal - trains are under signal control and won`t clear for ADT. Auto node trains are not under signal control. (see manual 10.3.1)
You can move from auto signal to auto node by reversing through a switch. A new sub path starts, and ADT can be completed. So if you can`t complete ADT under signals shunt the train to an area with no signals e.g. a yard.
Note however that commands like $wait $hold $activate do not work on subsequent sub paths. If you need these you witll have to $form a new train in the #dispose, so that they are on the first sub path. You can see a sub path counter in the Shift F5 dispatcher window like this [2]
Rick
#4
Posted 01 August 2020 - 02:42 AM
Here is my own callon script. This is for shunt type signals guarding routes into platforms. (use trainhascallon for open line situations).
My script can be substituted in the sigscr.dat for a normal stop signal to enable callon. But you can get side effects so beware of modifying all signals in a route. e.g My script does not work as it is with 2 head junction signals - both aspects clear.
Attached File(s)
-
rick_callon_script.txt (1.03K)
Number of downloads: 378
#5
Posted 01 August 2020 - 03:01 AM
Quote
Track Viewer can show the signal's type:
You have to tell him to "show all signals" and their *.s-file names(Track items/interactives/show also other signals and Statusbar/show signal info menus), then hilight the signal, You are interesting, with a mouse pointer.
The information about signal, then, can be seen at status string at the bottom of trackviewer's window.

I've just forgot to note, that at "platform 1 left"(very bottom track in diagram) at that time, another train waited for activation for moving to the left.
#6
Posted 01 August 2020 - 03:58 AM
#7
Posted 01 August 2020 - 04:09 AM
I can only see the signal file name in trackviewer. Taking the file name I look in the sigcfg.dat and find the signal shape (attached). There are 20 subobjects in this signal. We need to find the right SigSubSType to modify the script in the sigscr.dat to enable callon. But which?
Ignoring the decor items i`ve extracted the SigSubSType s from the sigcfg.dat (attached)
In most cases it will be the script with a normal stop function to modify for callon. But I`m afraid that the complexity of this signal defeats me, and with 234 others to consider too!
So the questions remain, can we help Jan., and how can an ordinary user compile a timetable in a signalled route?
Rick
Attached File(s)
-
Jan_sicfg.txt (3.07K)
Number of downloads: 356 -
Jan_sigscr.txt (8.25K)
Number of downloads: 395
#8
Posted 01 August 2020 - 04:26 AM
Can you post the Shift F5 dispatcher viewer of your player train in the run round please? This may give the reason why the train is stopped. Very likely there is a conflict with another train that has claimed the route beyond the signal. In the path section look for things indicating deadlock like #&*^~ and get the train number that is in conflict.
#9
Posted 01 August 2020 - 04:29 AM
Quote
Quote
Quote
https://www.youtube....h?v=EOk0kpTkRys
Correction: that trains are BOTH AI
Green one stays there for 40 minutes (inactive) and the 1st track's exit signal is belived to hold on close state till 2 minutes before that train's arrive time.
The discussed train (red) has to reach its platform, change "head" during RR-action and depart immidiately, well before the first train.
Quote
Maybe, later :(
It's possible, You're somewhere right:
I already corrected sigscr.dat for such signal type, as it didn't open for incoming trains, when was used as entrance signal.
Quote
Can You explane this a little more verboose, please?
#10
Posted 02 August 2020 - 04:18 AM
We are talking about signalled routes so mode will be auto signal. ( see below for player actions)
You can put a train (player or AI) into auto node by moving to an area with no signals and reversing it through a switch. This starts a new sub path in auto node. Fortunately in many real life situations a train will do the same. Shunt away from running lines into a yard, and carry out operations without signals.
In auto node it is easier to complete an ADT operation, free from signals. It is a useful check that your syntax and paths are correct . I think that paths are not critical for ADT : they must overlap and have a common section.
If you can`t complete the ADT it is likely that another train has claimed the path.
It could be that you have too many sub paths in your train .Split the train into 2 using $forms in the #dispose and make a new train column. You can see the current sub path counter in the dispatcher viewer Shift F5 like this [3] 1 reversal = 1 subpath
It is best to have only 1 ADT operation in each train column. Or a single ADT in a station field, followed by another ADT associated with $forms in the #dispose. Like this
$forms=newtrain /Runround=oldtrainRR where oldtrainRR is the runround path name.
Player actions. You can pass a signal using tab.The control mode becomes auto node - train ahead, and if you can couple to a stationary train, then the signal script or the signal links need to change. If the tab request is denied, very likely the path is claimed by another train or the train ahead is active towards you.
If after tab, your train passes through the other train (no coupling) then the ADT hasn`t registered.
Signal links. Test signals by making the path through the signal without other trains. Maybe the route builder has not set the signal links to clear on the path you have selected.
Please be sure that other trains nearby really are inactive. The most reliable way is to set them as static in the #dispose or #start , or a later time in #start
Rick
#11
Posted 02 August 2020 - 05:33 AM
Quote
Both actions together, or one of them is enough?
At described case, there ARE signals at both ends of platform tracks, so, this condition is inacceptable, right?
Quote
What Do You mean?
Quote
the red one is "traffic" train: it
1.starts outside the station (somewhere at pool park's track in real life)
2.arrives to platform with engine at the head for boarding (~10 minutes)
3.performing runaround, as soon as possible, during that time (without success)
4.departs to the branch line, at opposite direction, rather have arrived.
So, it has main path, runaround path and than, forms outbound train.
I should to choose that train and drive its engine manually, trying to perform all of predefined actions.
#12
Posted 02 August 2020 - 03:14 PM
I don`t know all of the conditions to move from auto signal to auto node. Certainly you must pass a switch (enter a new track vector??), and perhaps reverse to start a new sub path.
The reason I suggested auto node mode is because it is outside of the influence of signals and hopefully other trains. If your ADT works in auto node, then you know you are using the corect syntax ( commands and qualifiers, spaces etc)
As you describe it, you don`t have too many sub paths, so this isn`t the problem.
Your red signal isn`t protecting the runround carriages, and the locomotive will be trying to claim a path forwards through the switch. Callon isn`t required yet. It is very likely that the static train has already claimed the path ahead, and the signal is correctly red. How do you know the static train really is static? Was it made static through the #start field or #dispose? Or perhaps from a command like $detach /nonpower /static.
Or possibly another train is making a conflict. This is why you need to look at the Shift F5 dispatcher viewer, because it shows information on train conflicts.
Suspected trains can be disabled temporarlily by putting comment at the top of the train column
Weter`s problem is different from Jan`s because Jan has a signal that leads directly to the runround consist, and Weter does not. Jan probably has a callon problem, and Weter does not.
Yes when you have a problem train, it is good to watch it as AI, and to drive as player.
#13
Posted 03 August 2020 - 04:38 AM
Weter, on 02 August 2020 - 05:33 AM, said:
1.starts outside the station (somewhere at pool park's track in real life)
2.arrives to platform with engine at the head for boarding (~10 minutes)
3.performing runaround, as soon as possible, during that time (without success)
4.departs to the branch line, at opposite direction, rather have arrived.
So, it has main path, runaround path and than, forms outbound train.
When you refer to 'runaround', do you actually use the /runaround qualifier in the $forms command?
If so, what you could try is to drop the /runaround command and use $detach and $attach commands, making the run around move a separate train.
The runaround qualifier is much 'older' than the $detach and $attach commands and does not have the same active interaction with the signalling as the later commands do.
Regards,
Rob Roeterdink
#14
Posted 03 August 2020 - 10:09 AM
Quote
That train arrives(from the left), then forms another train, which has to depart to opposite way(to the left on diagram) 40 minutes later.
so, first one has dispose field, second-only start and during that 40 minutes, third performs runaround.
#15
Posted 03 August 2020 - 12:15 PM
roeter, on 03 August 2020 - 04:38 AM, said:
Hi, Rob!
Now I am a little confused. Obviously, I didn't understand this point well.
What did you mean by saying "interaction with the signalling"? Does that mean that a signal script is overruled by the qualifier and an action of /runaround will permit to "runarounding" unit(s) to pass signal at danger aspect?
Regards
Oleg