Never-ending crew change?

You are here: Home > Forum > Simulations > Released > Oxford PSB > Never-ending crew change?

Page 3 of 3

Never-ending crew change? 05/12/2017 at 21:19 #103712
GeoffM
Avatar
6274 posts
Lyn-Greenwood in post 103688 said:
Geoff,

Now you are working on an interim fix to the Crew-change Dwell-time issue, do you also intend to fix the long-standing problem with the Train-type Station Dwell-time (both of them) so that the Dwell-time is measured from the Actual Arrival time of the train rather than from the time its last Activity completes?

I'm sure there would be some very happy users if it could be done now rather than when the mega-changes to the Dwell-time logic are agreed and implemented.
If only it were that simple...

There has been a LOT of discussion off-forum about the way dwell times are dealt with - your solution, for example, is not acceptable to some TT authors. Please be patient while we try to get to a compromise that everybody is happy with, not just one that fits a few people.

SimSig Boss
Log in to reply
Never-ending crew change? 05/12/2017 at 22:36 #103718
Lyn-Greenwood
Avatar
239 posts
GeoffM in post 103712 said:
Lyn-Greenwood in post 103688 said:
Geoff,

Now you are working on an interim fix to the Crew-change Dwell-time issue, do you also intend to fix the long-standing problem with the Train-type Station Dwell-time (both of them) so that the Dwell-time is measured from the Actual Arrival time of the train rather than from the time its last Activity completes?

I'm sure there would be some very happy users if it could be done now rather than when the mega-changes to the Dwell-time logic are agreed and implemented.
If only it were that simple...

There has been a LOT of discussion off-forum about the way dwell times are dealt with - your solution, for example, is not acceptable to some TT authors. Please be patient while we try to get to a compromise that everybody is happy with, not just one that fits a few people.
I'm sure there is a lot of behind-the-scenes discussion taking place on how to best deal with the various dwell times that SimSig supports and I agree it's not a simple matter. However, we currently have a bizarre situation which I'll try and explain. If a train has a 5 minute Train-type Station dwell time set to ensure it stops at stations for a sensible time if running late, then if it arrives early or on time at a station and a crew change is scheduled, then the crew change completes on time but the train always departs 5 minutes late. The departure time also gets delayed in the same fashion if a new loco attaches (or a join takes place) before the scheduled departure time. If you remove the Station dwell time, then everything works fine, but you get an enforced delay if there is a Station dwell time, which just doesn't seem right to me.

I'm sure you'll come up with a scheme which prevents the strange behaviour I've outlined above, so I'll wait patiently for the outcome.

Log in to reply
Never-ending crew change? 05/12/2017 at 22:38 #103719
Albert
Avatar
1313 posts
GeoffM in post 103534 said:
In a slightly unusual step I'm going to attach a WIP version of the Loader. Firstly it should show that progress has been made, albeit not complete yet. Secondly, some posters on this thread are not testers but do have significant interest in this issue. Thirdly, it's useful to me to be sure of the right direction before it's too late.

I've loaded a save of a train which was stuck in the platform waiting for crew into 4.6.5.3 and within seconds it gave me a TRTS, so that's at least working now. What I have noticed though is; you do not see crew change anymore in the window to show a train's timetable; the "CC" activity is only shown in the editor.

Thanks for the quick fix at least!

AJP in games
Last edited: 05/12/2017 at 22:38 by Albert
Reason: None given

Log in to reply
Never-ending crew change? 05/12/2017 at 23:19 #103721
JamesN
Avatar
1570 posts
Lyn-Greenwood in post 103718 said:
GeoffM in post 103712 said:
Lyn-Greenwood in post 103688 said:
Geoff,

Now you are working on an interim fix to the Crew-change Dwell-time issue, do you also intend to fix the long-standing problem with the Train-type Station Dwell-time (both of them) so that the Dwell-time is measured from the Actual Arrival time of the train rather than from the time its last Activity completes?

I'm sure there would be some very happy users if it could be done now rather than when the mega-changes to the Dwell-time logic are agreed and implemented.
If only it were that simple...

There has been a LOT of discussion off-forum about the way dwell times are dealt with - your solution, for example, is not acceptable to some TT authors. Please be patient while we try to get to a compromise that everybody is happy with, not just one that fits a few people.
I'm sure there is a lot of behind-the-scenes discussion taking place on how to best deal with the various dwell times that SimSig supports and I agree it's not a simple matter. However, we currently have a bizarre situation which I'll try and explain. If a train has a 5 minute Train-type Station dwell time set to ensure it stops at stations for a sensible time if running late, then if it arrives early or on time at a station and a crew change is scheduled, then the crew change completes on time but the train always departs 5 minutes late. The departure time also gets delayed in the same fashion if a new loco attaches (or a join takes place) before the scheduled departure time. If you remove the Station dwell time, then everything works fine, but you get an enforced delay if there is a Station dwell time, which just doesn't seem right to me.

I'm sure you'll come up with a scheme which prevents the strange behaviour I've outlined above, so I'll wait patiently for the outcome.
The crux of it is - should activities / dwell time happen concurrently or consecutively or a mix of the two (for example a train could change crew and elapse the dwell time concurrently; but you can't do the booked detachment until the crew have changed). It really isn't very simple to arbitrarily make that assumption to the satisfaction of all users - indeed the original behaviour wasn't faulty - it was doing what it was designed to do. Concurrent activities simply weren't considered when customisable dwell times were implemented.

Log in to reply
The following user said thank you: Lyn-Greenwood
Never-ending crew change? 05/12/2017 at 23:40 #103723
GeoffM
Avatar
6274 posts
Lyn-Greenwood in post 103718 said:
However, we currently have a bizarre situation which I'll try and explain. If a train has a 5 minute Train-type Station dwell time set to ensure it stops at stations for a sensible time if running late, then if it arrives early or on time at a station and a crew change is scheduled, then the crew change completes on time but the train always departs 5 minutes late. The departure time also gets delayed in the same fashion if a new loco attaches (or a join takes place) before the scheduled departure time. If you remove the Station dwell time, then everything works fine, but you get an enforced delay if there is a Station dwell time, which just doesn't seem right to me.
See, this is part of the problem. While what you describe you want might be perfectly correct in some situations, it might not be in others. Imagine in the above scenario that the passengers are not allowed to board during that divide/join - required with sliding door stock and health and safety, I believe: we do then have to have a dwell time after the divide/join to allow the passengers to board. In slam door times probably nobody would mind so much.

JamesN in post 103721 said:
The crux of it is - should activities / dwell time happen concurrently or consecutively or a mix of the two (for example a train could change crew and elapse the dwell time concurrently; but you can't do the booked detachment until the crew have changed).
Indeed, and there's more. Say a train divides into three portions: should the total divide time be the same as for one divide (probably not), or doubled (probably not), or somewhere in between (probably)?

JamesN in post 103721 said:
indeed the original behaviour wasn't faulty - it was doing what it was designed to do. Concurrent activities simply weren't considered when customisable dwell times were implemented.
The former - yes, by design (though clearly not what everybody wants!). The latter... yeah... as more features get added, we can look back and say "it was okay then, but how do we fit X in as well without breaking existing timetables".

Ultimately you want full control - but without it becoming a massive chore to write a timetable. That's the bit we're trying to suss out.

SimSig Boss
Log in to reply
The following users said thank you: Lyn-Greenwood, JamesN
Never-ending crew change? 06/12/2017 at 11:15 #103743
KymriskaDraken
Avatar
963 posts
GeoffM in post 103723 said:
Lyn-Greenwood in post 103718 said:
However, we currently have a bizarre situation which I'll try and explain. If a train has a 5 minute Train-type Station dwell time set to ensure it stops at stations for a sensible time if running late, then if it arrives early or on time at a station and a crew change is scheduled, then the crew change completes on time but the train always departs 5 minutes late. The departure time also gets delayed in the same fashion if a new loco attaches (or a join takes place) before the scheduled departure time. If you remove the Station dwell time, then everything works fine, but you get an enforced delay if there is a Station dwell time, which just doesn't seem right to me.
See, this is part of the problem. While what you describe you want might be perfectly correct in some situations, it might not be in others. Imagine in the above scenario that the passengers are not allowed to board during that divide/join - required with sliding door stock and health and safety, I believe: we do then have to have a dwell time after the divide/join to allow the passengers to board. In slam door times probably nobody would mind so much.

JamesN in post 103721 said:
The crux of it is - should activities / dwell time happen concurrently or consecutively or a mix of the two (for example a train could change crew and elapse the dwell time concurrently; but you can't do the booked detachment until the crew have changed).
Indeed, and there's more. Say a train divides into three portions: should the total divide time be the same as for one divide (probably not), or doubled (probably not), or somewhere in between (probably)?

JamesN in post 103721 said:
indeed the original behaviour wasn't faulty - it was doing what it was designed to do. Concurrent activities simply weren't considered when customisable dwell times were implemented.
The former - yes, by design (though clearly not what everybody wants!). The latter... yeah... as more features get added, we can look back and say "it was okay then, but how do we fit X in as well without breaking existing timetables".

Ultimately you want full control - but without it becoming a massive chore to write a timetable. That's the bit we're trying to suss out.
I don't know if this is possible or not, but if the station dwell times are made inclusive the other activities will happen while this counter is running down. You then add a checkbox/menu to each activity so that the writer can specify that the activity happens at the same time as the one before, happens after the previous one has completed, or happens at the same time as the next activity, the default being happens after previous.

For example a train has a ten minute dwell, and has to split and have a crew change you can specify that the split happens first, happens last, or happens at the same time as the crew change.

Kev

Log in to reply
Never-ending crew change? 06/12/2017 at 16:50 #103759
Lyn-Greenwood
Avatar
239 posts
I believe the current discussion on dwell times would be better conducted under the "Ideas on multiple dwell times" thread in the Timetables section of the Forum (see here).

Would a kind Moderator please move all posts from my Post #103668 onwards to this new location? I'll then add some more thoughts on the subject.

Last edited: 06/12/2017 at 16:52 by Lyn-Greenwood
Reason: Typo!

Log in to reply
Never-ending crew change? 07/12/2017 at 00:51 #103767
simonstops
Avatar
21 posts
Online
Please can someone advise me if i'm missing something? I read the forum and understand Albert has had success with the waiting crew problem since Geoff produced the updates. I've downloaded these files from the loader and started a fresh 2016 game. The problems are still there with 1P07 etc. I've tried playing the 2009 timetable and the problems are with that timetable too. Cheers
Log in to reply
Never-ending crew change? 07/12/2017 at 03:25 #103770
GeoffM
Avatar
6274 posts
Postal sent me a log file earlier which identified a couple of things not used in my test timetables. I've attached a new Loader. Again, this won't fix everything as I was just concentrating on the time aspect for the moment. Any testing ought to be done on fresh games, not saves.
Post has attachments. Log in to view them.
SimSig Boss
Log in to reply
The following users said thank you: BarryM, postal, Meld, simonstops
Never-ending crew change? 07/12/2017 at 05:19 #103771
BarryM
Avatar
2158 posts
simonstops in post 103767 said:
Please can someone advise me if i'm missing something? I read the forum and understand Albert has had success with the waiting crew problem since Geoff produced the updates. I've downloaded these files from the loader and started a fresh 2016 game. The problems are still there with 1P07 etc. I've tried playing the 2009 timetable and the problems are with that timetable too. Cheers
If your Loader version is 4.6.5 then the Crew changes have not been uploaded till Geoff's post applies today.

Barry

Barry, Sydney, New South Wales, Australia
Last edited: 07/12/2017 at 05:27 by BarryM
Reason: edit

Log in to reply
Never-ending crew change? 07/12/2017 at 05:44 #103772
BarryM
Avatar
2158 posts
Tested a Peterborough crew change 4E86. It arrived 2 minutes late, changed crew then departed 1 minute late.

Barry

Barry, Sydney, New South Wales, Australia
Log in to reply
Never-ending crew change? 07/12/2017 at 06:17 #103773
BarryM
Avatar
2158 posts
I like your additional phone call messages!. Excellent!

Barry

Barry, Sydney, New South Wales, Australia
Log in to reply
Never-ending crew change? 07/12/2017 at 10:35 #103779
simonstops
Avatar
21 posts
Online
Cheers for that BarryM
Log in to reply
Never-ending crew change? 09/12/2017 at 22:39 #103847
GeoffM
Avatar
6274 posts
Further investigations and a new version is being tested off-forum first. The two sims and timetables I was testing against had different results and on further investigation they had different setups. These are all pertinent factors in crew changes:
- Can depart early (d in timings)
- Crew change dwell time (00:00 or not)
- Station stop dwell time (x4 variations)
- Any other activities at the same location after the crew change (including Next/Divide/Join but not Share)
- Whether there is mathematically enough time to do everything required
- Run rounds where the divide-rejoin duration is unknown by the software

I'm withholding updates until this issue is resolved, but we may be there from the sounds of the first few hours of testing. To solve some of the above I've implemented a bit more of the things I intended to do later. I'll tell you more when I'm happy it seems to be working.

SimSig Boss
Log in to reply
The following users said thank you: 58050, Meld, JamesN, VInce, BarryM, Lyn-Greenwood, KymriskaDraken
Never-ending crew change? 11/12/2017 at 09:31 #103878
BarryM
Avatar
2158 posts
Albert in post 103099 said:
Here is a save of train 1P77 in the 2016 TT standing in Oxford P3 waiting for its 20:06 crew (it called me when entering reporting the crew would be there at 20:06).
However even when letting it run until 20:19, the train stays at "crew change" status.

Any way to get it to move?
I ran a test of Alberts dilemma using Loader 4.6.5.4 and found the Crew Change worked perfectly.

Barry

Barry, Sydney, New South Wales, Australia
Log in to reply
Never-ending crew change? 15/12/2017 at 04:38 #103969
GeoffM
Avatar
6274 posts
Thanks to everyone that tested these changes. As I mentioned earlier, there are a number of factors involved in the crew changes and some had an adverse affect. Another test version was released to my testers several days ago which was tried on a number of sims and timetables, and as multiplayer games. Apart from one issue (see below), we believe it's far better than it was.

The one known issue outstanding is a crew change followed by a run round (ie crew change, divide, join). Since the timetable does not necessarily know how long that run round might take, it doesn't include it in the crew's arrival time calculation which is offset from the train's departure time. It can't use the arrival time as (a) it might not have one; (b) the arrival time might be hours or even overnight before a crew change in the morning. We're still working on a solution for that.

You can now override each activity's duration. If the activity has a time of 00:00 then SimSig will use the dwell times for that train type. If it's 00:01 or greater than it'll perform that activity for around that length of time. So if you had a dwell time of 2 minutes for a divide, and had a train that divided into three portions which should only take 3 minutes total, then you could override the dwell time by setting each of the two divide activities to 01:30 (or whatever ratio). So, to re-iterate, you do NOT need to specify an activity duration UNLESS you want to override the default (ie you should only need to do it in less common cases, not for every activity).

Loader 4.6.6 is available by Check for Updates.

SimSig Boss
Log in to reply
The following users said thank you: WesternChampion, VInce, Lyn-Greenwood, 58050, Trainfan344
Never-ending crew change? 15/12/2017 at 10:28 #103982
VInce
Avatar
579 posts
Geoff,

Thank you and your testers very much for all of your hard work on this - I'm now incorporating these changes into the next version of Peterborough 1977.

I hope you don't mind a question which would save me a lot of testing time.

1) I have a parcels train which needs its full amount of time (20 mins) for loading and unloading whilst a run round takes place. What I've done in the past is use a location dwell time of 20 mins MINUS the time to detach, attach and an estimate of the actual time taken for the run round. In this example that would be:-

20 - 2(detach) -2 (attach) -3 (run-round) = 13mins

The 2 mins detach and attach are train type dwell times.

Does that still hold good? I appreciate the time taken for the RR is unknown and I would still need to be estimated.

In other words are the activity times still over and above the location dwell time or are they inclusive. i.e. is the 20 mins measured from the time the train arrives, irrespective of any activities that take place.

Hope that's clear - probably not!

Vince

I walk around inside the questions of my day, I navigate the inner reaches of my disarray, I pass the altars where fools and thieves hold sway, I wait for night to come and lift this dread away : Jackson Browne - The Night Inside Me
Last edited: 15/12/2017 at 10:34 by VInce
Reason: None given

Log in to reply
Never-ending crew change? 15/12/2017 at 10:45 #103985
MarkC
Avatar
1084 posts
As long as there is no Crew Change before the Detach - RR - Join then all should be OK.

The Identified issue stems from having a Crew Change Before the Runround (Crew Change - Detach - RR - Join).

Log in to reply
The following user said thank you: VInce
Never-ending crew change? 15/12/2017 at 14:54 #104014
postal
Avatar
5189 posts
VInce in post 103982 said:
Geoff,

Thank you and your testers very much for all of your hard work on this - I'm now incorporating these changes into the next version of Peterborough 1977.

I hope you don't mind a question which would save me a lot of testing time.

1) I have a parcels train which needs its full amount of time (20 mins) for loading and unloading whilst a run round takes place. What I've done in the past is use a location dwell time of 20 mins MINUS the time to detach, attach and an estimate of the actual time taken for the run round. In this example that would be:-

20 - 2(detach) -2 (attach) -3 (run-round) = 13mins

The 2 mins detach and attach are train type dwell times.

Does that still hold good? I appreciate the time taken for the RR is unknown and I would still need to be estimated.

In other words are the activity times still over and above the location dwell time or are they inclusive. i.e. is the 20 mins measured from the time the train arrives, irrespective of any activities that take place.

Hope that's clear - probably not!

Vince
Or you could make cast-iron certain without any need to estimate by setting up a rule that Train A must not depart from Location B until X minutes after Train A arrives at Location B. There is nothing to stop the train departing after a longer stay if matters so require but you will have at least the guaranteed X minutes station time unless you use F2 to ignore the rule.

The whole issue is challenging though. For example, the Royal Mail/EWS contract which came into force on 30/09/1996 at the start of the Railnet network included minimum platform times for every call made for Royal Mail purposes and which was totally independent of any railway related activity. Confusingly in view of the difficulty SimSig is having in trying to define the term, this was called a "dwell time" in the contract.

“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
Last edited: 15/12/2017 at 14:55 by postal
Reason: None given

Log in to reply
The following user said thank you: VInce
Never-ending crew change? 15/12/2017 at 16:51 #104025
VInce
Avatar
579 posts
postal in post 104014 said:
VInce in post 103982 said:
Geoff,

Thank you and your testers very much for all of your hard work on this - I'm now incorporating these changes into the next version of Peterborough 1977.

I hope you don't mind a question which would save me a lot of testing time.

1) I have a parcels train which needs its full amount of time (20 mins) for loading and unloading whilst a run round takes place. What I've done in the past is use a location dwell time of 20 mins MINUS the time to detach, attach and an estimate of the actual time taken for the run round. In this example that would be:-

20 - 2(detach) -2 (attach) -3 (run-round) = 13mins

The 2 mins detach and attach are train type dwell times.

Does that still hold good? I appreciate the time taken for the RR is unknown and I would still need to be estimated.

In other words are the activity times still over and above the location dwell time or are they inclusive. i.e. is the 20 mins measured from the time the train arrives, irrespective of any activities that take place.

Hope that's clear - probably not!

Vince
Or you could make cast-iron certain without any need to estimate by setting up a rule that Train A must not depart from Location B until X minutes after Train A arrives at Location B. There is nothing to stop the train departing after a longer stay if matters so require but you will have at least the guaranteed X minutes station time unless you use F2 to ignore the rule.

The whole issue is challenging though. For example, the Royal Mail/EWS contract which came into force on 30/09/1996 at the start of the Railnet network included minimum platform times for every call made for Royal Mail purposes and which was totally independent of any railway related activity. Confusingly in view of the difficulty SimSig is having in trying to define the term, this was called a "dwell time" in the contract.
I remember this - while I was Network Services Manager East for EWS I shared an office at Doncaster with one of the RES managers. He was never in before 09:30 unlike us mere freight men and by the look on his face I could tell how the RES 0900 conference had gone.

When the freight and RES conferences were amalgamated we all got the chance to share in their agony. It became clear to me just how onerous the Mail contract was and I realised that the likelihood of EWS ever achieving its side of the agreement were slim to none, given Railtrack's propensity for taking emergency engineering blockages with little or no reference to mail train running.

I think everyone realised EWS were onto a hiding to nothing with the mail contract and it was no surprise when mail was finally lost to road. Some said at the time that was RMs whole objective. Make the terms of the contract impossible to achieve so as it gave them an excuse to move everything to road.

I'd left EWS by this time and couldn't comment on that but looking at it then from the outside there was almost an inevitability about the whole thing.

Vince

I walk around inside the questions of my day, I navigate the inner reaches of my disarray, I pass the altars where fools and thieves hold sway, I wait for night to come and lift this dread away : Jackson Browne - The Night Inside Me
Last edited: 15/12/2017 at 17:00 by VInce
Reason: None given

Log in to reply
Never-ending crew change? 15/12/2017 at 17:17 #104034
postal
Avatar
5189 posts
VInce in post 104025 said:
I remember this - while I was Network Services Manager East for EWS I shared an office at Doncaster with one of the RES managers. He was never in before 09:30 unlike us mere freight men and by the look on his face I could tell how the RES 0900 conference had gone.
Simon Patrick, David Copeland?

“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
Never-ending crew change? 15/12/2017 at 22:29 #104082
postal
Avatar
5189 posts
VInce in post 104025 said:
When the freight and RES conferences were amalgamated we all got the chance to share in their agony. It became clear to me just how onerous the Mail contract was and I realised that the likelihood of EWS ever achieving its side of the agreement were slim to none, given Railtrack's propensity for taking emergency engineering blockages with little or no reference to mail train running.

I think everyone realised EWS were onto a hiding to nothing with the mail contract and it was no surprise when mail was finally lost to road. Some said at the time that was RMs whole objective. Make the terms of the contract impossible to achieve so as it gave them an excuse to move everything to road.
At the time that the Railnet scheme was implemented Royal Mail was fully committed to rail (otherwise why would they have built the dedicated terminals at the likes of PRDC Willesden, Warrington, Bristol, Shieldmuir, Newcastle and Doncaster as well as spending money on Railtrack infrastructure at the likes of Tonbridge, Plymouth and Stafford). They also bought and still own the Cl.325 EMU sets.

However, there were two factors which came into play after the first couple of years that made the move to road inevitable. The first was the forthcoming WCML PUG. As mail is posted during the day and delivered the next morning that means that the overnight transits are the most important part of the Royal Mail distribution network. The PUG brought the virtual closure of the WCML each night as a trunk distribution channel. The WCML was the carrier of the heaviest flows of mail traffic on the rail network and the PUG closures would have wrought havoc with that. There would have been an impact on the Quality of Service (proportion of 1st. class letters delivered next day) which would have put Royal Mail in danger of financial penalties from its Regulator. At the same time there was an internal reorganisation in Royal Mail with the trunk networks of both Parcelforce and Royal Mail being brought into a common structure to achieve economies of scale and greater synergy. The senior management in the new structure were by and large from Parcelforce which had been running a road-based network for a number of years. Adding those two together does tend to point in one direction.

I can say that the senior Royal Mail executive who devised and led the Railnet project is to this day extremely bitter about the way that the highly successful project which he directed was subverted and destroyed. I was lucky enough to work in the team putting the project in and they were some of the happiest days of my working life.

“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
The following user said thank you: whatlep