Not signed in (Sign In)

Vanilla 1.1.4 is a product of Lussumo. More Information: Documentation, Community Support.

    • CommentAuthorianwallis
    • CommentTimeJul 23rd 2010
     
    Just spent a frustrating couple of days with a new installation and wanted to share the information with others so you don't have the same problems.

    The scheme is unfinished so the controller is running the junction plus a shuttle set of signals on stream 2. It is therefore running CLF 24 hours to maintain the linking as the reservoir between is quite short. We had a number of reports of the shuttle sticking red overnight although initial checks found nothing. However I had an early morning start on Tuesday and sure enough they were stuck red and the controller was in VA mode (the shuttle signals have no detectors as the timings are dictated by the plan).

    The problem appears to be the PTC1 timetable. Each entry has an end time (default midnight) so the entry put the overnight plan on at 19:00 but instead of running to the next plan entry at 07:00 it got to midnight and switched back to VA, then came back onto plan at 07:00. The obvious fix is to put another entry to run the overnight plan from midnight until 07:00 but the PTC1 requires the timetable entry to be in time order and there is no insert command. This means that I have to re-write my existing 12 entries into the next slot down to free up the first slot for my midnight starting entry (everyone still with me?). It's a huge bind and in my opinion a serious mistake in the original programming of the operating system.

    Incidentally, this applies whenever you wish to add a timetable entry so to keep in time order you will always have to re-write any entries which are timed to start later.

    So going back to my original intention which is to prevent similar hassle for others, If you want CLF to run through midnight you will need to get a midnight start entry put into the PROM at configuration time and it might even be worth getting a blank one put in even if you don't plan to use it initially - at least you can modify that one instead of having to re-write the whole timetable down a slot.
    • CommentAuthorIanStewart
    • CommentTimeJul 23rd 2010
     
    Thanks for that information, Ian. I live in dread of having to write a solicitor's report on the operation of one of these controllers, and will keep hold of the original configuration request to work from, instead of the controller specification which is unreadable.
    • CommentAuthorfreddy2780
    • CommentTimeJul 26th 2010
     
    Ian,

    I would be interested to hear what (if anything!) PEEK are planning to do to solve this issue.
    • CommentAuthorPVG
    • CommentTimeAug 5th 2010
     
    Yes, we noticed this in our PTC-1 trials in London. As you say the PTC1 timetable has an end time of midnight.

    We had to put in an exit time of cycle time - 1 so that the plan run to the end. Then you can re-introduce the plan again after midnight plus the amount of seconds that the plan overruns at midnight. It is a pain and you have to calculate the amount of plan overrun at midnight by working out how long your plan runs for since introduction time until midnight, divided by cycle time and find the remainder.

    We had no base time, perhaps it is simpler with base time CLF as the controller should recalculate plan position.

    I can't remember what exactly we did but it is something like written above. I know it took a lot of playing on the simulator.

    However there are still problems.
    1) Would somebody redo all this maths on a CLF or timetable ram change
    2) As FT is also really a CLF plan then you don't know introduction time as it is whenever the FT button was pressed.

    If you don't calculate a smooth over midnight CLF re-intoduction then you get what we nicknamed the midnight jitter when the CLF plan jumps and then you have lost sync with other controllers.