Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 5, 2019 17:14:46 GMT
Very impressive good luck in the wiring of the Lever Op board and Programme Machines they are complicated enough to learn when its already in situ
|
|
|
|
Post by sweetp on Mar 5, 2019 18:51:33 GMT
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:  And the Lever Ops board behind:  |
|
|
|
Post by sweetp on Mar 5, 2019 19:14:39 GMT
In the simulator the Programme Machines have full decodes and animations:  Whereas at the same time, the lever frame, also animated, looks like this:  Anyway, enough for now, lest I bore people. |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 5, 2019 19:55:20 GMT
Anyway, enough for now, lest I bore people. You've found the right audience to make that unlikely |
|
|
|
Post by zbang on Mar 6, 2019 0:35:29 GMT
You've found the right audience to make that unlikely Make that highly unlikely. |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 6, 2019 21:28:21 GMT
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.
|
|
|
|
Post by sweetp on Mar 7, 2019 1:30:36 GMT
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!)
Thanks again!
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 7, 2019 18:39:10 GMT
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.
|
|
|
|
Post by sweetp on Mar 7, 2019 23:28:04 GMT
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.
|
|
|
|
Post by sweetp on Mar 8, 2019 14:58:21 GMT
3) Finsbury Park - you were pretty much spot-on:
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!
|
|
|
|
Post by londonstuff on Mar 8, 2019 16:28:37 GMT
I’m pretty sure this level of detail wouldn’t be available anywhere and am astounded how it’s progressed. Just one of the reasons I think this forum is amazeballs!
|
|
|
|
Post by sweetp on Mar 8, 2019 16:41:57 GMT
I’m pretty sure this level of detail wouldn’t be available anywhere and am astounded how it’s progressed. Just one of the reasons I think this forum is amazeballs! I'm very lucky to have had the support of a number of people who've believed in what was, frankly, a bonkers project to even attempt! |
|
|
|
Post by sweetp on Mar 8, 2019 16:44:02 GMT
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!
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 8, 2019 17:29:10 GMT
I’m pretty sure this level of detail wouldn’t be available anywhere and am astounded how it’s progressed. Just one of the reasons I think this forum is amazeballs! I'm very lucky to have had the support of a number of people who've believed in what was, frankly, a bonkers project to even attempt! I think the original people who designed it in the first place and commissioned all that old stuff where scientists. And doing it into a computer programme I think it’s like brain surgery blindfolded so all I can say I’m very impressed in the way this has been done. Try to do somewhere like Earls Court with pseudo programme machines and that will screw your mind up. Oh and a pseudo programme machine is a machine which does not exist in real life physically but as far as the signal op sees it the machine does exist with all the same available functions |
|
|
|
Post by sweetp on Mar 8, 2019 17:50:31 GMT
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! |
|
|
|
Post by sweetp on Mar 31, 2019 11:49:40 GMT
A quick update.
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)
 |
|
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!
