Upcoming Games

(UTC times)


Full list
Add a game

Upcoming Events

No events to display

Who's Online

KneeOn, rodney30, cdoward, MikeBR152, kaiwhara (5 users seen recently)

Crew Change timing issues

You are here: Home > Forum > General > General questions, comments, and issues > Crew Change timing issues

Page 1 of 1

Crew Change timing issues 11/06/2017 at 15:53 #95803
Lyn-Greenwood
Avatar
239 posts
While taking part in the testing of the updated Peterborough 1 July 1977 timetable I came across some issues where Crew Changes interact badly with departure times and the Rule "X must not depart Z until N minutes after X arrives at Z". I've summarised my observations below and also attached a saved session of a test timetable that highlights the problems, so anyone interested can have a go themselves to see what happens.

1. If I don't set a custom dwell time for the crew change, then the crew phone in saying they will be ready at the scheduled departure time.

2. If I set the crew change dwell time to be X minutes, then the crew say they will be ready at "X minutes before the scheduled departure time" (not those actual words, of course, just the time).

3. If I set a location dwell time where the crew change is to take place but don't set a crew change dwell time, then the crew say they will be ready at the scheduled arrival time, which seems sensible seeing that any activities only take place after the crew change.

Now this all works fine if trains arrive early or on time, but not if they arrive late. A late train is ready to depart almost immediately after it arrives, which isn't very realistic. So we need a Rule to prevent the train from departing until a realistic time after it arrives, but I'm afraid it's not that simple. The Rule kicks in even when the train arrives early or on time, so it ends up departing late. The Rule works for a late arrival, but delays trains that are on time!

It looks as though the system is not using the correct time value for its Rule calculations. I would have thought that the actual departure time should be either the scheduled time or actual arrival time + dwell time stated in the Rule, whichever is the later.

Now if method (3) above is used, then everything works fine for early, on-time and late trains, but you lose the 'C' in the departure time as it gets replaced by 'w', which is a small price to pay for getting things to work properly.

In my attached saved session (for Peterborough), 0Z01 has a crew change dwell time of 2 minutes; 0Z02 has the same plus a Rule (for late running) to prevent departure until 2 minutes after arrival; 0Z03 has no crew change dwell time but has a location dwell time of 2 minutes where the crew change takes place. Try running it with trains allowed to enter the station immediately and then with trains held outside for 8 minutes. The F2 list shows some interesting information.

From my observations, I believe it would be better for crew changes to be completed at "arrival time + crew change dwell time" so that other activities can be carried out well before departure time rather than forcing them to be delayed until departure time, which is what happens now.

I look forward to comments on the above, especially from people who have a good knowledge of how the core code is supposed to handle this area of a simulation.

Post has attachments. Log in to view them.
Log in to reply
Crew Change timing issues 11/06/2017 at 17:17 #95804
58050
Avatar
2652 posts
Can't say I've had any issues using the crew change facility with my York summer 1991 timetable. You don't need to add un an additional 'dwell' time. Just arrival & departure time & check the crew change box. The usual time allowed is 2 minutes, however there is a freight train in the Peterborough 1985 timetable I'm writing which has a 5 minute stop for crew change. If trains are running early you get a phone call advising you what time the forward crew will be available & so the signaler has to regulate accordingly.
Log in to reply
Crew Change timing issues 11/06/2017 at 17:32 #95805
postal
Avatar
5208 posts
Lyn

I entered #15713 to Mantis on 01/09/16 with text reading:

"As currently configured any actions due to take place when a crew change is due are held back until the crew change has taken place.

"That means that things like a pilot attaching or detaching at the rear of the train does not happen until after the delayed crew change has taken place at the other end of the train.

"Is it possible to split the actions from the crew change so that things like attaches and detaches can take place even if the crew change has not taken place? This would allow a more realistic crew change scenario."

To date the bug has not been acknowledged or updated. Two other reports I made at about the same time in regard to the crew change have been resolved.

“In life, there is always someone out there, who won’t like you, for whatever reason, don’t let the insecurities in their lives affect yours.” – Rashida Rowe
Log in to reply
Crew Change timing issues 11/06/2017 at 17:44 #95806
Lyn-Greenwood
Avatar
239 posts
58050 in post 95804 said:
Can't say I've had any issues using the crew change facility with my York summer 1991 timetable. You don't need to add un an additional 'dwell' time. Just arrival & departure time & check the crew change box. The usual time allowed is 2 minutes, however there is a freight train in the Peterborough 1985 timetable I'm writing which has a 5 minute stop for crew change. If trains are running early you get a phone call advising you what time the forward crew will be available & so the signaler has to regulate accordingly.
Hi Pascal,

It's when a train arrives late that things go really wrong. The train leaves almost immediately and if you add a Rule to prevent this, the rule comes into play even when the train arrives on-time or early, which it shouldn't. It looks as though the Rules software is using the departure time instead of the arrival time when it checks if the Rule should come into play.

Try the saved session I supplied and you will see what I mean.

Lyn

Log in to reply
Crew Change timing issues 11/06/2017 at 21:43 #95813
Lyn-Greenwood
Avatar
239 posts
postal in post 95805 said:
Lyn

I entered #15713 to Mantis on 01/09/16 with text reading:

"As currently configured any actions due to take place when a crew change is due are held back until the crew change has taken place.

"That means that things like a pilot attaching or detaching at the rear of the train does not happen until after the delayed crew change has taken place at the other end of the train.

"Is it possible to split the actions from the crew change so that things like attaches and detaches can take place even if the crew change has not taken place? This would allow a more realistic crew change scenario."

To date the bug has not been acknowledged or updated. Two other reports I made at about the same time in regard to the crew change have been resolved.
Postal

I'm in total agreement with your proposals. I'm sure that crew changeovers would occur when the train arrived, not just before it was due to depart, so that the new, fresh crew could handle any splits, joins, etc.

What amazed me the most when I did my tests was that Rules created to deal with late running actually caused early and on-time trains to depart late! Bizarre, to say the least.

Anyway, let's see whether the core code programmers can explain what is supposed to happen as opposed to what actually does happen.

Log in to reply
Crew Change timing issues 13/06/2017 at 10:38 #95823
Lyn-Greenwood
Avatar
239 posts
I'm very disappointed that no-one has tried to explain how the crew change timings are supposed to work and why requesting a crew change somehow clobbers the correct working of the Rules code. Surely there's someone out there who can say whether the issue I've found is a genuine bug or a design feature and that the issue has been added to Mantis if it is a bug.
Log in to reply
Crew Change timing issues 13/06/2017 at 10:59 #95824
headshot119
Avatar
4869 posts
Lyn, only Geoff or Clive could tell you if it's working as designed or not. I'm afraid rules and dwell times aren't something I know much about.

Postal already has an open ticket (#15713) which I've added this thread to.

"Passengers for New Lane, should be seated in the rear coach of the train " - Opinions are my own and not those of my employer
Log in to reply
Crew Change timing issues 13/06/2017 at 14:15 #95827
Lyn-Greenwood
Avatar
239 posts
headshot119 in post 95824 said:
Lyn, only Geoff or Clive could tell you if it's working as designed or not. I'm afraid rules and dwell times aren't something I know much about.

Postal already has an open ticket (#15713) which I've added this thread to.
Thanks, Karl. I'm away on holiday tomorrow for 2 weeks so I'll have a look when I return and catch up with progress.

Log in to reply
Crew Change timing issues 13/06/2017 at 16:23 #95831
GeoffM
Avatar
6325 posts
Lyn-Greenwood in post 95823 said:
I'm very disappointed that no-one has tried to explain how the crew change timings are supposed to work and why requesting a crew change somehow clobbers the correct working of the Rules code. Surely there's someone out there who can say whether the issue I've found is a genuine bug or a design feature and that the issue has been added to Mantis if it is a bug.
There are a lot of things happening at a station that come into play including crew changes, dwell times (whether per location, per train type, per specific value, or by sim), divides/joins, reversals, TRTS up to a minute before, rules, triggers.... it's quite possible we have something the wrong way around, or it may be that the ordering is correct under some circumstances but not others. It's not a simple answer!

SimSig Boss
Log in to reply
The following user said thank you: Lyn-Greenwood
Crew Change timing issues 13/06/2017 at 20:50 #95832
Steamer
Avatar
3945 posts
GeoffM in post 95831 said:
Lyn-Greenwood in post 95823 said:
I'm very disappointed that no-one has tried to explain how the crew change timings are supposed to work and why requesting a crew change somehow clobbers the correct working of the Rules code. Surely there's someone out there who can say whether the issue I've found is a genuine bug or a design feature and that the issue has been added to Mantis if it is a bug.
There are a lot of things happening at a station that come into play including crew changes, dwell times (whether per location, per train type, per specific value, or by sim), divides/joins, reversals, TRTS up to a minute before, rules, triggers.... it's quite possible we have something the wrong way around, or it may be that the ordering is correct under some circumstances but not others. It's not a simple answer!
Please could you (or Clive) post the way the code handles each type of dwell time at present, and how the types are 'added up'? Are some dwells handled concurrently, for instance does time spent joining also count as 'station forward'? It would be really useful for timetable writers to know instead of having to deduce the rules from trials, and I don't think a full guide has been written up on the Wiki either.

"Don't stress/ relax/ let life roll off your backs./ Except for death and paying taxes/ everything in life.../ is only for now." (Avenue Q)
Log in to reply
The following user said thank you: KymriskaDraken
Crew Change timing issues 16/06/2017 at 15:24 #95861
clive
Avatar
2756 posts
GeoffM in post 95831 said:
Lyn-Greenwood in post 95823 said:
I'm very disappointed that no-one has tried to explain how the crew change timings are supposed to work and why requesting a crew change somehow clobbers the correct working of the Rules code. Surely there's someone out there who can say whether the issue I've found is a genuine bug or a design feature and that the issue has been added to Mantis if it is a bug.
There are a lot of things happening at a station that come into play including crew changes, dwell times (whether per location, per train type, per specific value, or by sim), divides/joins, reversals, TRTS up to a minute before, rules, triggers.... it's quite possible we have something the wrong way around, or it may be that the ordering is correct under some circumstances but not others. It's not a simple answer!
And, since my name has been invoked in this thread, I'll comment that life is currently overloading me and I don't have any time right now to investigate.

Log in to reply
The following user said thank you: DriverCurran