Indeed! For now, the Lever Ops Board and the PMs will stay virtualised (but completely represented) within the simulator whilst the artefacts themselves remain static. Here's our mini-IMR, which some may have seen, with the frame in the middle, Programme Machines to the right, code/spot generators and logic cards to the left:
Great work, thanks very much for making this available. Two questions/observations: 1. How are dwell times currently modelled? At the moment, trains seem to be bunching quite noticeably around the stations where they are held to time by the programme machine. Of course I'm not familiar with how realistic the timings in the timetable were in practice, but it does seem a like trains are making the journey a little too quickly. 2. I'm not sure if this anything useful for you to go on, but yesterday I noticed the service falling apart after a train got stuck departing Walthamstow from platform 2. The front of the train was stopped over track circuit WN and the indication for that track on the IMR diagram was dark.
Thank you very much for your feedback. You raise some good points.
1) The dwell times have a minimum randomised duration at non-IMR sites and, currently, do leave early so that they do not arrive late at the next IMR site. This does mean that they are somewhat prone to bunching on approach to an IMR site, and therefore sometimes request permission from the logic to proceed early. This is currently prevented by all sites running in NOOT (No out-of-turn), as there is usually no human around to manually prevent the logic granting this permission (as per design of each site/PM). If I attempt to increased the average dwell time any further, it leads to the occasional train arriving late - Basically I really need to set minimum dwell time on a per-platform basis, but I haven't written this piece of code yet!
2) Interesting. I don't suppose you happen know what time that was, approximately (both GMT and simulator time)? The simulator should run a full day fine, but it is certainly possible things may fall apart (and are then compounded by a lack of manual intervention to fix things in a timely fashion!). Of course, if anyone has put any of the sites into Push-Button/FCFS/PM Only and then manually routed anything, expect the whole thing to fall apart when trains turn up out of order; One cannot renumber trains at the moment, or send extra trains from the depot if they are put away, so trying to put the service back together is very difficult!
There is only one simulator that everyone shares. If it's clear the service is broken, whilst one can try to fix it via the desks, do feel free to just reset it via the 'V' in the bottom right-hand corner.
(Also, if you've worked on this equipment, you likely know more that I do! All the logic is transcoded from the original bookwirings and is available for inspection [See spreadsheet linked on the Home page] as I'm sure I've made the odd typo. This information, along with live state of PM functions, may help identify whay happened at Walthamstow. I'd certainly appreciate any help!)
Regarding 1), and possibly differing dwell times between peak and off-peak, too? But you also have a good point regarding the current state of the sim - with a) a single shared sim instance, that b) needs to be able to run unsupervised and c) only limited facilities to deal with disruptions as you mentioned (renumbering trains currently not possible, etc.) you wouldn't want to have too many delays happening.
Regarding 2), no, I'm only interested in signalling same as you, although not really on the circuit-level so far. I did take a look at your documentation, though and I think I might have found an explanation that's more likely than a random bug: According to the ATO SB sheet, WN goes to "no code" when VPSBER or VPNBER are down, so someone (and I can't exclude myself there for certain) probably operated one of the NB/SB ER (emergency replacement?) buttons on the debugging desk. Consciously doing so certainly seems to be able to replicate the situation I originally witnessed.
However I've noticed two other things at Finsbury Park that seem like genuine bugs this time: 1. If I put the IMR into push button-mode, NB trains get stuck departing. It seems like the route dropping at signal 5 as the train passes it somehow affects the track circuits in advance of the signal (most likely 443D, although the panel only shows the combined indication for 443ED) as well and as such the train presumably gets tripped. Resetting the route (even with half of the train still in the station) gets it going again though, which is probably also why the problem doesn't affect auto mode, as there the route remains set continuously. 2. If a NB train is stopped at Finsbury Park and a second train approaches, that second train seems to get stuck somewhere around 441BA and remains there even once the first train starts moving and vacates the platform.
Yes 1) is a balancing act delivering a self-running display that may also be fully-demonstrated. I'm also not from a railway background, so I'm on a steep learning curve, so things I hadn't even considered often appear unexpectedly! I have departure times for IMRs as I'm working from the Programme Machine files, but I suspect it might be possible to interpolate intermediate station departure times from these (or the inter-IMR time differences), and this might be a reasonable solution to cover both peak and off-peak...? Unsupervised running is important, but so will an automated reset if the desks aren't used for a period of time. Still much work to be done!
2) You may have a point regarding No Code on WN if either direction Emergency Relays are activated. (Do you recall the ATO code for WN at the time, as I did have a problem where the communication from simulator to the web-updater froze and I restarted it after about 5 minutes - all trains would have frozen). I have yet to make available the train status page via a web interface. This shows each train's number, speed, leading car track circuit, ATO code and brake spot(if any) and rate, and also helps see the scale of any issue.
3) Finsbury Park. I think you're on to something there; that's clearly not right. I need to get the bookwirings out to compare. Quite probably a transcoding error. More on this once I've had a look. Thank you for reporting this!
Thank you again for your time and very valuable information.
a) Logic inverted in 5L meant lock lifted early allowing Lever 5 to Normalise resulting in 443E and 443D going code 120 under the train. Was not an issue in auto mode as Lever 5 is permanently reversed
b) i) Typo in 4ALR logic referencing 1004_GR (Relay for Lunar white VK4 signal) meaning that 439E, 441B and 441A would never select ATO code 270, so a stopped train could never auto-restart from those tracks, nor could it run up to 443 headway post. However, in Auto, with no train in NB platform (i.e. evenly spaced service), trains would always receive 420 and run through fine. This also stopped the Route Call to VK4 being cancelled in manual after the passage of a train. ii) 441A code selection circuits had a reference to Lever 4 (R) instead of (RB) lever band, which caused a 120 code the moment lever 4 moved from Reverse towards mid. In auto, this lever is permanently reversed so the issue is not normally visible.
Thank you for your great sleuthing that pointed me directly to the issue. No mean feat when you're faced with my spreadsheet!
I've live-patched the simulator (I believe!), so it should run correctly now, but it won't be updated in the spreadsheet until I do another complete export. Do keep me posted!
Whilst not prototypical, I've temporarily added all the northbound ATO code lamps to help prove whether I've got this correct now. Note: These are *not* vertically aligned with the track occupation indications due to space limitations!
I'm proud of the simulator but, quite frankly, I'm standing on the shoulders of giants.
The engineering that went into the original line to support ATO is astounding. Layer upon layer of automation on top of the trusted lever-frame was a truly incredible feat of engineering that I really don't think is fully appreciated in these days of the microprocessor.
Even armed with all the answers (i.e the bookwiring), and with powerful computers to hand, I have found this a very challenging project. Goodness only knows how Dell and his team managed to work all this out on paper - some very, very clever people, and with management who were prepared to invest in such a bold scheme.
Earls Court, though, umm, maybe not! Programme Machines, Auto-reversing sites, ATO and then linking it to the original equipment is probably me done! And I still reckon I have a good few working months of soldering to go!
I've been building a display system to allow the various screens for a chosen IMR to be displayed simultanously. Here's Seven Sisters with the Frame and its diagram w/ATO, and a screen for each of the five programme machines, and the PM diagram: (Apologies for the poor photo, but you get the idea at this stage)