TimeTable Questions
#21
Posted 25 May 2020 - 11:15 AM
Anyway, back to the problem. If it is not really necessary that the first leg of train 17 preceeds train 40 but this can wait until 40 has departed, then a $wait could be set for 17 to wait for 40 - provided this is really the first leg of 17 and there are no other overlaps between the paths for 17 and 40.
If, however, the first leg of 17 must indeed take place before 40 departs, you have the classic problem with a reversal going back up a path which is common for a following train in both legs before and after the reversal. Splittig train 17 is then the only solution. Splitting train 40 will not help.
Regards,
Rob Roeterdink
#22
Posted 25 May 2020 - 01:07 PM
https://i.ibb.co/XCNs3WX/Run-Activity-2020-05-25-16-22-46-24.png
I don't think that splitting of train 17 will also help me.
This is because I encountered a similar situation again and again. What I described happens when the location is occupied by a static train and another train approaching the station claims the track sections ahead the static consist. Could this be due to the signal logic?
if (enabled && (block_state() ==# BLOCK_OCCUPIED) && (next_state <# SIGASP_RESTRICTING)) {state = SIGASP_RESTRICTING;}
If so, I need to modify my signal files...
I posted here a question about function approach_control_lock_claim(). That function as described in blueprint looks like possible solution for my problem.
Thank you
Oleg
#23
Posted 26 May 2020 - 01:05 AM
VicenteIR, on 25 May 2020 - 01:07 PM, said:
Your pictures were indeed also blocked on all previous posts. But I can now see the pictures in both your last and previous post.
It's the dispatcher hud in your previous post which actually tells the story - and a quit surprising one at that.
The multiple reversals of 17 have somehow confused the deadlock logic, and the switch ahead is actually blocked by the deadlock processing - even though 17 and 40 are moving in the same direction at this point. It looks like the deadlock processing has set up a 'deadlock trap' at this switch for one of the other legs of 17.
As the deadlock processing is independent from the signalling, changing the script won't help here.
Two things might perhaps sort this problem. One is to set a "$wait /notstarted" command for 40 at the stop location, making 40 wait for 17. The deadlock processing is prevented from setting 'deadlock traps' when a train has a wait command for the other train.
The other option is to split 17, with the first train formed of the incoming leg of the train to the pickup, and a new train formed after the pick up.
Regards,
Rob Roeterdink
#24
Posted 26 May 2020 - 03:19 AM
I'm glad that finally you can see the images. (Obviously old server was from Russia and they blocks everything normal that exists on the Earth)
I still think that the point is a consist without power units when the following train reserves sections "through" this consist. I have a different situation on my Timetable with the same result. In that case there are no reversal points on the path of attaching locomotive. It sheduled to attach by $attach = train command, case to exist and the approaching train behind the static still reserves sections ahead.
If a power unit is connected to static before approaching train claiming, no surprises happens and everything is works as planned.
#25
Posted 25 June 2020 - 10:00 PM
Quote
What does that mean please? :curiousPC:
#26
Posted 26 June 2020 - 04:51 AM
>For some obscure reason I cannot see the pictures you include in your post, all I get is "Your IP is blacklisted". Where this blacklist is taking place I do not know - Elvas Tower, my server, my laptop? Anybody any idea?
It is most likely to be your IP that is banned, you need to talk to your ISP.
#27
Posted 04 July 2020 - 02:27 AM
VicenteIR, on 25 June 2020 - 10:00 PM, said:
Information: Train XXXX (44) : Looped at 360
What does that mean please?
A train always tries to clear its path ahead. Sometimes, when trying to clear that path, a section is found ahead of the train which somehow is already occupied by that same train. This can happen when the train is in a loop-track (or balloon-track), and is looking at its own tail. It does, however, also occur sometimes when the train is reversing and due to some previous error, not all sections the train occupied earlier have been properly cleared.
In this situation, the program tries to sort the problem by checking the actual occupied position, and by checking if there is indeed a real loop.
Sometimes, however, the program cannot properly sort out the problem, and as the section cannot be cleared as the train itself is apparantly still occupying that section the train is stuck, and the state is set to Looped.
If this happens when there is no actual loop track, it is caused by an earlier error when not all previously occupied sections were properly cleared.
Regards,
Rob Roeterdink
#28
Posted 17 July 2020 - 11:42 PM
Even though I specify a $forms command with a runaround (or "turnaround" since it uses a loop track) maneuver, and even though I've clearly specified the path for the runaround, the consist still dissappears when the first train terminates, and reappears when the next train begins.
What am I doing wrong?
#29
Posted 18 July 2020 - 01:22 PM
Can you show us the command line?
#30
Posted 18 July 2020 - 03:02 PM