Elvas Tower: Timetable Mode Coupling in Signalled Routes - Elvas Tower

Jump to content

  • 4 Pages +
  • 1
  • 2
  • 3
  • 4
  • You cannot start a new topic
  • You cannot reply to this topic

Timetable Mode Coupling in Signalled Routes Enabling Coupling operations for beginners Rate Topic: -----

#11 User is offline   Weter 

  • Member, Board of Directors
  • PipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 6,806
  • Joined: 01-June 20
  • Gender:Not Telling
  • Simulator:ORTS
  • Country:

Posted 02 August 2020 - 05:33 AM

Quote

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.

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

It is a useful check that your syntax and paths are correct

What Do You mean?

Quote

It could be that you have too many sub paths in your train

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 User is offline   rickloader 

  • Conductor
  • Group: Status: First Class
  • Posts: 479
  • Joined: 05-February 13
  • Gender:Male
  • Location:Southampton uk
  • Simulator:Open Rails
  • Country:

Posted 02 August 2020 - 03:14 PM

Hi Weter, the first part of my post above attempted to answer your request for more information about auto node mode. The rest of my post has suggestions that I hope might help everyone. Now I`m happy to try to discuss your problem.
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 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,419
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 03 August 2020 - 04:38 AM

 Weter, on 02 August 2020 - 05:33 AM, said:

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.

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 User is offline   Weter 

  • Member, Board of Directors
  • PipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 6,806
  • Joined: 01-June 20
  • Gender:Not Telling
  • Simulator:ORTS
  • Country:

Posted 03 August 2020 - 10:09 AM

Thank for recomendations.

Quote

Was it made static through the #start field or #dispose?

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 User is offline   VicenteIR 

  • Fireman
  • Group: Status: Active Member
  • Posts: 149
  • Joined: 24-April 15
  • Gender:Male
  • Location:Dimona, Israel
  • Simulator:Open Rails
  • Country:

Posted 03 August 2020 - 12:15 PM

 roeter, on 03 August 2020 - 04:38 AM, said:

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.

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

#16 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,419
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 03 August 2020 - 02:38 PM

The interaction between the signalling and the $attach, $transfer and $pickup commands runs through the various TRAIN_HAS_CALLON signal script functions.
These functions do not only check if the train is supposed to attach to the train in the section ahead, but also if this is indeed the correct train. It performs these checks based on information set to both trains based on the attach-transfer-pickup commands.
The runaround command was created much earlier and did not set the same level of information for both trains.
I would need to check the code for details, but it could well be that the TRAIN_HAS_CALLON signal script functions do not properly derive the required callon state in case of the runaround command.

Regards,
Rob Roeterdink

#17 User is offline   VicenteIR 

  • Fireman
  • Group: Status: Active Member
  • Posts: 149
  • Joined: 24-April 15
  • Gender:Male
  • Location:Dimona, Israel
  • Simulator:Open Rails
  • Country:

Posted 04 August 2020 - 01:54 AM

To rickloader:

Did you / does your friend tried to use the $forcereversal command in situation that you described at the starting post?

Regards
Oleg

#18 User is offline   rickloader 

  • Conductor
  • Group: Status: First Class
  • Posts: 479
  • Joined: 05-February 13
  • Gender:Male
  • Location:Southampton uk
  • Simulator:Open Rails
  • Country:

Posted 04 August 2020 - 08:03 AM

Hi Oleg, thanks for your suggestion. No I didn`t try $forcereversal. My understanding is that this makes the train reverse before the switch, instead of reversing right back to the next signal and then forwards through the signal. Forcereversal would help if there was enough space for the train between the switch and the signal.
But in many cases the signal is close to the switch, and the train can not fit.
I do not think that $force reversal over-rides the signal, and callon would still be needed to pass the signal.
Rick

#19 User is offline   rickloader 

  • Conductor
  • Group: Status: First Class
  • Posts: 479
  • Joined: 05-February 13
  • Gender:Male
  • Location:Southampton uk
  • Simulator:Open Rails
  • Country:

Posted 07 August 2020 - 03:40 AM

I`m pleased to report that jan has cleverly modifed his signal script to incorporate callon. The red signal now clears to allow coupling, and his problem solved.
However, this requirement for a user to modify their signal script to enable ADT is too demanding for many.
I would like to explore ways to make this easier. I think both diagnostic tools and some code changes are required.
I`m not critical of timetable mode : I admire it greatly. With a few minor changes, I think timetable mode could be much more accessible. Unfortunately, I`m not a programmer, so I can`t do this directly. Help appreciated!
Rick

#20 User is offline   rickloader 

  • Conductor
  • Group: Status: First Class
  • Posts: 479
  • Joined: 05-February 13
  • Gender:Male
  • Location:Southampton uk
  • Simulator:Open Rails
  • Country:

Posted 07 August 2020 - 06:31 AM

A check list for ADT problems.
1) Open the OR log file
Search for entries about your target train

2) Check the timetable-or for syntax errors
Look for typos - copy and paste all path, consist and train names from the timetable-or and the consist folder to make up an error free train column . Look for white spaces - extra or missing

3) Drive the train as player
. Can you tab past red signals and still couple? If yes it is likely you need callon in the signal script

4) Watch as observer
Either make an observer train, static out of the way or jump to your train with alt F9. Enable the signal state with ctrl alt f11. Try changing signal states from the ctrl 9 dispatcher viewer

5) Make a test train in auto node mode. This should be away from signals and reverse through a switch. If you can couple then it is likely that signal scripts need changing to enable callon

6) Test signal links. In explore or manual mode open the ctrl9 dispatcher viewer. set the switches to the train route and see if the signals clear. The route builder may not have set the signal links

7) Open the dispatcher HUD shift F5 Find your train and look for conflicts with other trains
(RHS path info ) characters like #*^~ suggest possible deadlocks. Also look aut "Auth" the authorisation state eg TRAH = train ahead

8)Comment out conflicting trains
Put comment at the head of a train column to disable it. Will the problem train run now?

9)Try alternative commands.
eg try making a $transfer in to a detach followed by a $pickup. Substitute generic type commands for train names. eg nonpower, static etc

10) Split the train in two using $forms in the dispose column
A single complex train with several commands and reversals can fail. 2 (split) trains is easier for OR to handle


  • 4 Pages +
  • 1
  • 2
  • 3
  • 4
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users