Never-ending crew change?

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.

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.

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.

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.

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.

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 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.

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.

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

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?

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

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.