Processor Control of Lineside Items
Posted
Full Member
How to automate and control signals, level crossing gates, etc.
It's been a while since I last posted any updates. So I thought I'd give an update on where we're at at this point in time.Following on from the (eventual) success of the long running turntable saga that seemed to be never ending, life finally returned to the subject of the automatic signalling project; this is after some decent weather and a number of trips out and away in the caravan (together with numerous other interruptions - otherwise known as illnesses and "life"!). But not before I got round to installing a long forgotten Ground Positioning Signal (for Shunting back into the siding at the small Halt station). It took ages (many days in fact) to find where it had been put for "safe keeping"; and while I was on with thoughts of the GPS, I decided I would also spend a further few days trying to find where I had put the Positioning Signals (two white lights) that will allow a loco to move forward against an otherwise red aspect into a siding area; the Train Room is such an untidy place! After much tearing out what little hair I have left, I finally got them all found - not that I'm going to do anything with the Positioning Signals just yet a-while - but I needed to find them for peace of mind if nothing else; they'll soon be needed in the Terminus as part of this overall signalling project.
A few problems with the Ground Positioning Signal came along (mostly light bleed into an unlit aspect), but finally it was reconfigured and is now in position and wired into the signalling boards - see my post under John Street for more on this signal itself (https://yourmodelrailway.net/view_topic.php?id=14501&forum_id=21&jump_to=304264#p304260).
Returning (at long last) to the Automatic Signalling Project:
First job was to check the signal aspects and this proved simple and easily and quickly checked. Next on the list was to ensure all sensors were wired up and working correctly before I progressed further. One block of four sensors did not fill that criteria; two were fitted but needed adjustment - the other two were just not there at all!
One snag I found was that, now that I am automating the signals somewhat more than I had previously thought, which also included occupancy detection (of sorts), and a need to detect the entire length of a train and not just the loco (which already has a small piece of silver foil stuck under each belly, this being easily detected by the in-track sensors), the underbelly of coaches and trucks were not reflective enough to be detected by these sensors and I didn't want to have each and every coach and truck with silver strips of foil stuck underneath. This has meant having to replace each in-track sensor with an across-the-track sensor and to effectively hide them from view, blending into the scenery, etc. Not so easy when two of the sensors are on a double-track part of the layout. Hence a few low lying bushes have suddenly sprung up between the two running tracks to hide the infra red emitters; the sensors are hidden elsewhere not too far removed from the track side either in more bushes or inside buildings. The line of detection needed to be at an angle to be high enough to be blocked by the coach/truck body (not the through wheels) and at such an angle along the track so as not to see the inter-coach coupling gaps.
For those with figures and more detail on your minds:
with the RPR-220 emitter-sensor pair buried into the tracks, the voltage swing between sensing a coach/truck or nothing was around 0.5v with a +5v supply and a 470k resistor in the receiver collector circuit (refer back to https://yourmodelrailway.net/view_topic.php?id=16438&forum_id=7&page=1#p296757 which gives the circuit details). And a 0.5v voltage swing was certainly not enough to be considered stable enough for detection by the LM339. Back to the drawing board then.
The idea of using across-the-track sensors was again looked at but with a gap between the emitter and receiver (on one particular sensor position) of around 10inches (255mm) the sensitivity of the circuit was a little lacking. I tried pushing up the emitter power, perhaps beyond its undisclosed rated value, to 70mA. This made a slight difference in the sensed voltages, but not enough to be overly comfortable. So the emitter current was dropped back to 35mA (I think a normal maximum value would be 50mA) and the sensitivity of the receiver checked with differing collector resistor values. At 100k (more normal for a +5v supply) there was little difference between states; at 470k things started to look a little better and with careful alignment I could get a difference of 1.25v between train and no train on the test bench. I then tried increasing the resistor to 1M and at this point I started to get the inevitable 'leakage' current through the sensor and possibly also the LM339, but the train-in-position voltage dropped to 2.9v - giving a nice and acceptable 1.5v difference - all this on a +5v supply. I eventually settled for a 680k resistor which gave me, when emitter and sensor were fitted and glued into place, 4.52v blocked and 3.37v clear path giving a difference of 1.15v over a distance of 9.75inches (250mm). On the test bench I was able to get a usable voltage difference over a 15inch (380mm) gap, but the difference was starting to become minimal.
So that's been fun! This is what this hobby is all about for me - experimentation to get an end result that suit the situation.
So now I have to go back to the software side of the project and make a few changes in the program to reflect the change from in-track sensors - where I had need to add additional code to compensate for the gaps between coaches (the couplings). The only in-track sensor is now only going to be "looked at" when a train is reversing into the Halt siding. Overall, it should make the program a little faster.
That's it for today - hopefully I may get out for a breath of fresh air and stretch the legs this afternoon and then (just maybe) I can get back into the train room and get the new sensors fitted onto the layout.
Posted
Full Member
Staying on the thread Kevin.
Posted
Full Member
I recall the arc of the LU trains many moons ago when I lived/worked down that way. And also on the Southern 2-BIL,2 -HAL, 4-LAV, etc. units when I lived not 25 yards from the main south coast line (not that I knew the nomenclature at that time - they were just trains that rattled the windows to me at age 5 or so). I'm sure the drivers did the arcing on purpose!
You mention the small magnets under your locos. On my first layout I used that sort of thing riding over a reed relay across a couple of sleepers just beyond a signal. It worked quite well. Everything then was done using nothing much more than diodes and suitable voltages applied. But that was only used to trigger a signal from green to red - I can't recall how it went back to green again - probably using more diodes further down the track when the next signal went from green to red.
And as the track on this layout was already laid and cutting the rails to allow for current detection was not feasible there had to be another way of achieving the same result - detecting the presence of a train or part of a train on a given section of track and to light up an LED on a track diagram to give a visible indication should the train be in a section of track hidden from view.
But these days I'm wanting to use microprocessors which will not just change signal aspects but also simulate track occupancy. Namely, so long as a loco, coach or truck is present in a section then the section before that signal will not become "clear" and the previous signal will remain at red. A sensor is placed across the track so that once blocked by a loco it immediately trips the signal (signal B) just passed to red and puts that section as occupied. So long as that sensor remains blocked by the remainder of the train the section just being left remains "occupied" and the previous signal (signal A) remains at red. Once the final coach has cleared the sensor, that is when that previous signal (signal A) is allowed to go to a yellow aspect (in the case of a 3-aspect signal). It is, I guess, a software version of (in the real world of full sized trains) the more modern track circuit where a wheel-set/bogie makes a "circuit" across the two rails and a small current is drawn between one rail and the other and it's this loss of the voltage on one rail which is in turn used to indicate something is on the track in that section of track, i.e. section blocked.
This was never thought about when I first started this layout. The initial idea being to simply change signal aspects. Then the problem came about of the in-track sensors not being able to properly detect the presence of a coach or truck for the track occupancy. New sensors, update the software.
This is how the layout has developed over time. Start with the basic and then think about what might come next - and then solve the problems caused. If I had a plan……. how many times have I heard that?
Posted
Full Member
Staying on the thread Kevin.
Posted
Full Member
Staying on the thread Kevin.
Posted
Full Member
Only the other week I bought a new loco (as a treat to myself as it fitted in very nicely with the timescale of the layout). Only problem was that it didn't like one set of trailing points and kept derailing. The main issue was this set of points is buried under the main terminus throat and far from easy to get at. There's more to read on this at https://yourmodelrailway.net/view_topic.php?id=14501&forum_id=21&jump_to=305347#p305335
So that took a couple of weeks to sort out.
Then there was an errant couple of sensors I thought had been installed - but no. And that turned out to be a can of worms, so-to-speak. And it turned out more difficult than I had expected. The sensor, a 2-leg device, looking like an ordinary LED but darker, you would expect to connect it the same as an ordinary LED - long lead to positive/supply and short lead to ground. No! Whoever thought it would be a good idea to swap it round - long lead to ground, short to positive…….
No wonder it wouldn't work!
And then I thought that I would like to be able to switch off at the end of a running session (or in the case of a power fail) without the need to store everything back in sidings or in the terminus and to be able to pick up exactly from where I left it, occupied sections and all. Such is the problem with software-derived signalling and occupancy detection as opposed to "current detection". Everything normally gets lost at power off.
So that's meant another look at the programming - hoping in the process I'm not slowing things down too much by adding in these extra (write to eeprom) commands.
Surely this project can't be far off completion now, or maybe…..
Posted
Full Member
I'm assuming you know what you're doing because I got lost when you mentioned "breadboard" and didn't follow up with the type of flour you'd used ………………. :cheers
It does however, seem that you're making steady progress so onwards and upwards Sir !! :thumbs
'Petermac
Posted
Full Member
Having got the sensors sorted and working and a new set of points fitted (the original set didn't like the new Oxford N7 loco - down to a set of diverging Peco set-track points apparently). With a new set of Peco Streamline points fitted, together with having to change the approach tracks, all is now well in that area. Nowt's easy or straight forward these days!
So it was eventually back to the signalling project - and that wasn't quite the roaring success I had hoped for - no surprise there! The whole project - controlled by a set of four processors - need to chatter to each other to pass bits of information between them. Only they didn't chatter; not strictly true - two of them did, the other two failed to receive anything.
A simple programming error - aren't they all. But finding what the correct commands were was far from straight forward. The manual didn't make certain aspects clear to the "unknowing" (me) and it was a bit of a head-against-brick-wall theme. Basically, there are three areas of accessible "memory" in the processors and getting bits of information into and out of the right areas can be confusing. Well, that's my story anyway!
To cut a long story short (I never was much good at précis at school!), the guys on the associated forum have put me straight and all systems might appear as though they will be up and running pretty soon. I have faith now.
While all this has been going on, I keep adding bits to the software as fresh ideas come along - and making sure they should work takes time, of which I usually have little to spare.
Anyway, I'll get round to installing some test software pretty soon before unleashing the full programs onto the layout. Fingers crossed…..
Posted
Full Member
We never had these problems with Hornby Dublo 3 rail on the carpet………………. :roll:
'Petermac
Posted
Full Member
I’d love to see some videos of the progress. I’m sure you’ve said, but what language are you writing the code?
Chris
Posted
Full Member
And to Chris - it's not quite as grand as it might appear. It's only a relatively small 8x4 figure-of-8 layout on 2 layers.
The only reason I use 4 processors is because of a lack of input ports on each processor when you consider each of the 10 main layout signals have two outputs (Red and Green - the yellow comes from some logic chips), the terminus has 6 roads each wanting another output (Red - Green coming from logic chips - no yellow), plus white shunt ahead signals for each and 6 starter buttons. Then there are inputs for 10 points, 4 outputs for the theatre display, 10 outputs for track occupancy, 11 in-track sensors and a few other input/outputs for other controls. Getting on for 80 or so ports needed. And the largest of the processors can only handle 31 ports - add in the comms channels and that reduces to 29.
So I have one processor for the Layout, one for the Terminus signalling, one for the sensors and one for the terminus pointwork.
Then there's another processor to control the level crossing and another for the turntable - they're just for good measure.
So there's a lot going on keeping track of and operating the trains without the need to manually control signals as well - hence automating the signalling, trying to keep it moderately close to what might be seen on the real thing.
And the code is all in BASIC. Relatively slow in comparison to C+ (and probably others), but speed of operation is not the real factor here. I grew up with BASIC (on the early Sinclair Spectrum) and that's what I'm kind-of comfortable with and I'm a bit long in the tooth to start learning a new language.
As for videos of it all working - there's not much to show other than one signal operating after signal after another ……….(boring!) as a train run the layout. There's a video of the Turntable in operation on my YouTube page at: https://youtu.be/RAqhEKJtn5A
I'll post a photo of the rather crammed processor board once all is up and working, together with the Track Diagram (maybe a video of that as a train runs the layout might be worth putting on youtube - I'll see how it looks). Watch this space….but don't hold your breath - things move very slowly around these parts.
I bet you wish you never asked now!
Posted
Full Member
Lots of ways to do a similar things.
Posted
Full Member
Roger OO DC Steam
Posted
Full Member
Progress has been very slow ("very" slow) - and very trying at times - but it's now (more or less) complete. Problems have been (as always) mainly with time being available in between "life" and the numerous and varied issues software can throw up. The software is now pretty much complete - there are still a few "twiddly" bits that need to be added in and tested, but I now have a basic run-around that works and, for which, I am quite happy with.
On the railway side of things, before I got too far back into programming, I came across a simple (I should have already known about) problem with an across-the-track infra-red emitter and sensor. As the sensor looks like an ordinary LED, I expected it would also connect in the same way as an ordinary LED. And after much scratching of the head as to why this one sensor just would not work, I finally did hit on the reason why. What makes it worse is I already have another eight of these devices already up and working - but installed a couple of years or so ago - but the brain cell seemed to have forgotten that.
An ordinary LED (having the same shape and appearance of the infra-red receiver LED) has the longer leg connected to the positive supply and the shorter leg to ground. Not so the sensor/receiver - this looks exactly like an ordinary LED, but darker in colour; but this has the longer leg connected to ground. What 'bright spark' came up with that?! Confused? It certainly got me. Anyway, that sensor was finally got up and working and was effective over a relatively long distance - but not after another problem in that the LM339 wouldn't switch states (it needed a differential of over 1v between blocked and clear states before it would work). The remedy was to increase the IR emitter's current and light output and also increase the resistor to the sensor collector to increase the sensitivity of the device
Then I hit on one of the few remaining through-the-track RPR-220 emitter/sensor combined units. Again, this I could not get to work correctly (it used to!). Then, after taking it out from being buried in the track, it started to work somewhat better; not 100%, but much better. That turned out to be the value of the resistor in the collector path was way too high in value causing the sensor to be overly sensitive to the emitter sitting right next to it (both pointing skywards through the track). The cure here was to reduce the value of that resistor from 470k down to 47k and, hey presto, it works fine now. A couple of steep (re-)learning curves - or is it to remember it all! I tend to write all this stuff down as I go along - but it seems to make little or no difference to the grey matter, and the written-down stuff get filed away and misplaced.
While on the sensor discussion, I decided to swap one of the RPR-220 in-track devices for across-the-track separates. And to keep all the sensors reporting in the same manner - clear at 5v and blocked at 0v - I also needed to change the input to the LM339 from the inverting to the non-inverting inputs (or was it the other way round?). A simple job but something else added into the mix of getting this whole project up and running. Is nothing straight forward and easy?
Having now finally got those errant missing sensors installed and setup I could again progress further. The next part of the signalling project was to update the Home Signal board which controls the entrance to the Terminus; it's been in use for a good few years, long before this signalling project was even thought about, and, apart from controlling the Home signal for the terminus approach, it reads the settings of the points in the Terminus area so that it can display the platform number into which an approaching train will arrive. But a couple of port changes on the processor (for the i2c data bus) needed to be made which involved moving two points inputs to otherwise spare ports. Easily done other than my introducing a short circuit with a minute sliver of solder across the incoming power tracks which caused a shutting down of the entire power supply. Ooopps! Once that was found and sorted and the new program installed and tested, I was able to move onto getting the new "brains" of the project installed - the signalling microprocessors.
Coming next, more detail of the project of automatic signalling around the layout.
Posted
Full Member
A couple of short test progrmms were cobbled together to check the signals and that the sensors were getting through to the "master" processor and were being recognised correctly; all was looking good. That was a relief!
The software has been a bit of a nightmare for a couple of reasons - mostly with having only short chunks of time to write the programs spaced over many months. During the non-programming periods, the old grey cell tends to forget where it was and it takes time to get back into programming-mode. And then there have been various thoughts of how best to go about the programming - the methodology. It's mostly complete now, a few niggles will no doubt come to light as I find running trains might not be quite so straight forward as it might first appear. One problem I came across was getting data between one processor and another. It sounded easy enough, but, again, the practicalities were a little different.
I've given some detail in dribs and drabs over past posts about this automatic signalling project, but I feel it worthwhile to recap most of it now that it's up and working and that over the past months, various aspects have changed somewhat, this is mostly for anyone just coming to here, so that it's all in one place to save having to search across the past numerous pages of postings (er, ramblings). So forgive me if you've read bits of this before.
This is, in most respects, a very bespoke project in that the software is specific to my layout. But it does prove what can be done to automate the signalling around a layout rather than have a sensor on a signal and a timer to put the signal back to green after having gone to red by the passing of a train. There are other simple designs around that will change a couple (or more) signals between red, yellow and green but they do not tend to take into account route setting at a junction or on the approach to or departure from a terminus or even the occupancy of any given section of track or platform. This project covers all of that. Not that it provides complete route setting from A to Z but simply from one signal to the next, in much the same way as the real thing by moving from signal to signal if the section is clear. There are no track isolation circuits to prevent one train running into the back of another - so I do need to keep an eye on where each train is and how the signals are presenting themselves to the driver of each train.
The software is written in PICAXE BASIC, so is relatively easy to put together (he says with a degree of trepidation!), once you get the hang of the syntax rules and remembering to put the punctuation/separators in where it needs to be (I keep forgetting some of them as I type!).
The most important parts of this project are the numerous microprocessors - each has a specific area to look after:
Home Signal on the approach to the Terminus - type 28X2 (on AXE201 board) - I/O ports available: 22 - used: 19 (points, signal & theatre display) + 2 for i2c + 1 serial/download (spare ports: none)
Terminus Signals for trains departing the Terminus - type 40X2 - I/O ports available: 31 - used: 23 (6 signal heads, terminus sensors, starter buttons) + 2 for i2c + 1 serial/download (spare ports: 6)
Layout Signals for the overall layout - type 40X2 - I/O ports available: 31 - used: 30 (9 signal heads, section LEDs, point) + 2 for i2c + 1 serial/download (spare ports: none)
Sensors (the "master") - type 18M2 - I/O ports available: 16 - used: 12 (sensors, points) + 2 for i2c + 1 serial/download (spare ports: 1)
Level Crossing - type 18M2 - I/O ports available: 16 - used: 8 (servo motors, LEDs, point, sensors) + 1 serial/download (spare ports: 6)
From this, it can be seen there is very little wriggle room for expansion and why some data has to be moved from one processor to another. Although the Level Crossing processor has a number of ports spare, the opening/closing of the gates precludes it from being used for anything other than controlling the gates and (hard-wired) signalling to the "master" as to whether the gates are open or closed; this open/closed signal is then passed to the Layout processor. With a bit of additional thought I might be able to offload some functions elsewhere - but this works as is, and that's fine - for now.
The two devices control the signalling - one for the layout itself, and one for the terminus. As each of these processors are very heavily output orientated in driving the signal LEDs, and as the microprocessors are current limited in what they are able to supply, some buffering devices were needed to allow them to effectively provide sufficient output for the LEDs - each LED needing around 15mA to achieve a good light output.
The buffering devices used are ULN2003a (7-port) and ULN2803a (8-port), whereby a positive output voltage from the microprocessor is applied to an input of the ULN2x03a which will cause output to be driven to ground and thus the LED to become illuminated at the output. In this manner a permanent +12v supply is applied to all LED anodes via its limiting resistor; it is the negative (cathode) end of the LED that is brought to ground via the ULN2x03a devices causing the circuit to be made and the LED to light. Two exceptions to this is a pair of gantry signals which were wired the other way round (i.e. conventionally) before everything had been planned fully. So some jigging around was needed to do the job.
The Home Signal and Terminus microprocessors both need to know the state of the points around the terminus area so that they can decide whether there is a valid entry or exit path before it sets a green (OFF/proceed) signal. In the case of the Terminus processor, a double-white positioning (shunt ahead to the turntable/siding area) signal will be connected as well. Due to the lack of ports available on the Terminus microprocessor the points data comes from the Home Signal board via the i2c data bus. These two microprocessors do not directly "talk" between themselves. A fourth microprocessor (the "master") acts as a go-between between the microprocessors. Along the way it also has the job of monitoring the track sensors around the layout; this data is passed to the Layout microprocessor so that it knows roughly where each train is. A few other bits of data are also passed around via the "master" device and the i2c data communications, the other microprocessors acting as "slave" devices.
Coming next, the data being passed between processors and driving the signal LEDs.
Posted
Full Member
Terminus points - read and used by the Home signal - passed via the "master" to the Terminus;
Layout sensors - most are read by the "master" - passed to the Layout;
Layout points - some read by the "master" - passed to the Layout - others read directly by the Layout;
Platform occupancy - controlled by the Layout - passed via the master to the Home signal;
Level crossing state - hard wired to the "master" - passed to the Layout
I don't want to clog this overview up with too much information. I've probably lost a number of readers already, but I feel it important for an understanding of the constraints being faced due to the restriction of port and current availability on any given processor. Any future expansion of the layout will most likely involve an additional processor (maybe more) - but we'll not go there just now; no expansion is planned.
One aspect of the i2c data bus that needs to be remembered is that it needs to have a 4k7 "pull-up" resistor on both the clock (SCL) and data (SDL) lines involved. The value of these resistors is not critical but they do need to be fitted for the 'bus' to work. Only one resistor per line is required. It's worth bearing in mind that the i2c communications bus is for relatively short distances of less than a couple of metres or so. Anything over this length requires the use of the more normal serial data (RS232).
A look back at the block diagram in my post #37 on page 2 gives an overview layout of the processors and what they do.
A few "tricks" are used along the way - recall from earlier that there are not enough output ports on the processors to supply each and every signal LED with its own output. The Terminus processor only uses one output for each red and green starting signal. Likewise, the Layout processor uses the same "trick" for two of its 2-aspect signal heads. To effect this, the processors provide a +5v output for one signal (the red) and is passed via one port of a ULN2x03a to the red LED and, when turned off (0v), as a grounded output for the other signal (the green) which goes to a 7404 inverter chip which inverts that grounded signal into a positive signal to turn on another ULN2x03a port and activates the OFF (green) LED. The signal gantry at the Terminus exit only had space available for a red/green signal heads to be mounted. Had I found the space to use a three aspect head then a further processor would most likely have been needed for both a red and a green output in order to provide the yellow aspect (as noted below for those signals on the layout which are 3 aspect signals).
The other "trick" is to generate a yellow aspect from using two processor outputs by making use of a 7402 NOR gate, whereby one processor output will generate a red signal, another output will generate the green signal - both of which are passed to the 7402 device (as well as input ports of the ULN), and, according to the 7402 truth table, if both outputs are turned off, the 7402 will generate a positive output and hence the yellow signal - each signal then being passed to individual ULN2x03a ports and to their respective LEDs.
Next up, the final chunk, software additions.
Posted
Full Member
Each input/output goes to via a patch board to make the interconnections between the sensors and signals and the processor board - easier to isolate and fault find (should the need arrive).
As an aside to getting the signals to work, I have also paralled each output onto a Track Diagram (as yet only partially completed) which comprises a series of 4 stripboard panels that mimic each signal, section occupancy and point setting. The software, while noting which sections are occupied, allows for each section to light a short series of LEDs when a train is present on that section. I thought this was a good idea as around 50% of the layout is hidden from view but is still signalled in the normal manner as the visible trackwork signalling. This makes it easier for me to know where each train is when I can't see it and it gives a little animation when nothing appears to be happening on the visible part of the layout - I like animation.
The picture shows a train in section 3 with a green aspect in front of it (over the open level crossing) with an amber signal immediately behind and a green on the signal further back. Section 4 is a small siding (unoccupied) shown under section 3. The Terminus signals are shown on the far right with a red aspect being shown for each of the exit roads. Two more pcb sections are in the process of being built which will show the remainder of the layout.
Another piece of software was written to keep track of Terminus platform occupancy. No point in allowing the Home signal to send a train into an already occupied platform! Likewise, no point in setting an OFF signal to an empty platform.
No doubt that there will still be some updates to the software to come as I find various quirks in the way the signals operate under differing running conditions and loco placings. The simulation program can only go so far and certainly nothing related to data being passed over the data bus - nothing beats real world testing. There may be more hair pulling yet to come! And there's little of that left already.
So now I need to get the remainder of the Track Diagram completed and that'll be job (more or less) done. It's been quite a long project to get to this stage - a few issues along the way, and some not necessarily directly to do with the signalling project, that has seriously prolonged its getting to the current state.
Finally, a picture of the completed processor board showing the two main processors, one each for the Terminus (at the bottom) and the Layout (at the top). Also just visible at the lower left is the "master" processor. A board crammed with components that do all appear to work as hoped!
It's been a lengthy and an interesting project to work on - from what started out as a simple theatre display on the Home signal to a full-blown signalling system with new ideas coming along at various stages.
There are, no doubt, simpler methods and systems that can be built (or bought) that would do a similar job, but….. Thank goodness this one's complete - unless I think of something else to add to it. I'll let you know.
Thanks for bearing with me and for reading through to the bitter end.
Posted
Full Member
A few changes have happened along the way, mostly with the programming of the PICAXE chip(s) that control the signalling on the layout and also that involved with the Terminus. It's been quite a bugbear getting it right, especially with regard to the small siding at Longmeadow station and linking the opening/closing of the Level Crossing Gates to it all.
The Level Crossing opening sequence is now controlled by a train entering the section beyond signal1 (sets the signal to red and creates a software "block" on that section) rather than having a sensor buried in the track a bit further down the line. In fact most in-track sensors have been replaced with across-the-track sensors that are more stable and do not require a piece of silver foil stuck under a loco (there's still a couple to do). And the crossing gates will not close until a train has fully cleared the crossing (quite vital that!) or if there's a second train on approach.
One in-track sensor at the Level Crossing has been taken out completely and some jiggery-pokery in the programming achieved the same purpose to make it redundant. I thought it would be simpler to implement train movements that way within the programming - but probably not so - I struggled with getting movements in and out of the siding right. The processor is now power-proofed to recall if a train is in the siding between sessions. As is the state of each platform at the Terminus. Terminus signals will not allow a green (exit) aspect from an empty platform and neither will the approach Home signal allow a path (green aspect) into an already occupied platform.
The Track Diagram (see photo in last post) has not been completed as yet - changed a bit though to indicate some pseudo signals in the hidden areas. I will get it completed one day. Currently it shows the first set of signals on the right pcb of the set (Terminus and signals1 and 2), but the left pcb now shows the pseudo signals.
Something else that still needs adding are the Positioning Signals within the terminus. It's mostly setup - I just need the 3D items drilling out and LEDs fitting. One day!
There's nothing much more that needs doing, automation related. Maybe a few more tweaks to the programming in one processor or other, but that's about it. Done and dusted.
Thank you, if you've been following this ramble through getting some processor (automatic) control of things on the layout. It turned out somewhat more complex than I had initially envisioned, but we got there - I kept adding things!. I appreciate the PICAXE processors are a bit of a one-off with their (slowish) BASIC programming code, but then again, if the Arduino (or whatever processor) is your bag, then any project will still become a one-off and will relate to "your" particular circumstances and needs. But hopefully, this set of posts has given an idea of what can be done with a processor or two, a bit of ingenuity and a lot of learning along the way.
Thanks again for reading.
Posted
Site staff
Posted
Full Member
All I can say with regard to the processors used in my quest to automate the signalling and certain other parts of the railway, is that when a processor goes bad, it goes BAD.
I had one of the PICAXE 40X2 processors that runs most of the layout signals, as well as controlling a few other functions, totally die on me - not sure why, but it did - and for a second or two it took the entire power pack which supplies +12v across the layout (and via +5v regulators to each processor, including this one) to shut down. All I was doing was downloading an updated program onto it. It died mid download and then failed to be recognised by the software uploader after that.
A quick check round of the voltages on the pins showed nothing amiss, so I must have been unlucky and that its "number" had come up and it went to meet its "maker".
The way the most of the processors on this layout are linked is through the i2c comms system I couldn't immediately check what other processors were still working (or not) until the failed processor had been ordered, received, replaced and loaded up. So, I needed to devise a test program or two to test the memories and input pins on each processor type and then test the remaining, hopefully still working, processors simply to prove to myself they had not been damaged by the power outage. One order is better than having to make multiple orders had others been damaged as well.
Anyway, all was well and, with fingers crossed I emitted a huge sigh of relief; the railway is now back up and running in time for a Christmas run-around. Phew.
1 guest and 0 members have just viewed this.