Jump to content
 

Signal interlocking with Arduino


Robin2
 Share

Recommended Posts

The question of using an Arduino to manage signal and point interlocking was raised in a few posts (16-20) in this Thread.

In the latest (May 2014) edition of Railway Modeller there is an article about interlocking using the Modratec lever frame. I used it as a basis to develop an Arduino program to do the same thing. The full code (for an Uno, and should also work on a Mega) is attached for anyone that is interested. Comments are very welcome.

The code for actually testing for approved movements is short.

void checkValidMove() {

  if (numErrors > 0) {
    return;
  }
    // we want to see if this move is allowable 
  numErrors = 0;
  for (byte n = 1; n <= numLevers; n++) {
    if (lever[n].leverPosition != lever[n].lastValidPosition) { // only check levers that have moved
                                         
         // test if the OFF requirement is met
      byte offTest = curOffStatus & lever[n].offReq; // offTest represents all the relevant levers
      byte errVal = 0;
      if (offTest != lever[n].offReq) { // do the relevant levers match the requirement?
        errVal = 1;
      }
      
          // repeat for the ON requirement
      byte onTest = curOnStatus & lever[n].onReq; 
      if (onTest != lever[n].onReq) {
        errVal = 1;
      }
      numErrors += errVal;
    }
  }
}

One of the problems with using software is that there is nothing physical to prevent a user moving the wrong switch or lever. In my code a wrong move won't have any effect except to cause the onboard LED to blink. Two or more wrong moves cause the LED to blink faster. The function checkValidStartingPosition() exists to allow the user the opportunity to set the levers back to a valid position.

I have tried to devise a system that allows the locking requirments to be specified easily. For any lever you need to tell it what other levers must be OFF and what other levers must be ON. The default is to require nothing. As faar as I know the following implements the scheme in the RM article. The values lvr1, lvr2 etc are defined to be unique to each lever. In effect each lever is represented by one bit in a byte.

void setLockRequirements() {

    //  set the locking requirements - tedium here is unavoidable
    
  lever[1].onReq = lvr3 + lvr4 + lvr8; // lever[1] should only move if 3,4 and 8 are ON
  
  lever[3].onReq = lvr4;  // lever[3] should only move if 4 is ON
  lever[3].offReq = lvr1; //    and 1 is OFF

  lever[4].offReq = lvr1 + lvr3; // lever[4] should only move if 1 and 3 are OFF

  lever[8].offReq = lvr1; // lever[8] should only move if 1 is OFF
  
}

My code requires two Arduino pins for each lever - one for the lever switch and one for the output. In the sketch the output just lights an LED to illustrate the workings but it would be relatively easy to modify the code to manage servos for point or semaphore signal movement.

In case anyone is confused I have created an array of 9 levers (numbered 0 - 9 ) and I have ignored lever[0] completely so that there is a simple corresondence between the lever index and the physical lever number. Getting interlocking to work is complex enough without continually having to remember that lever[4] really means the 5th lever.

I know little or nothing about signal interlocking. I think my code properly matches the RM article but I won't be surprised if someone points out a flaw.

...RInterLock.ino

Edited by Robin2
  • Like 2
Link to post
Share on other sites

Robin

 

Thx for this. Looks like you beat me to it!

 

As I said, I eventually got to go out for a beer with my pals, and we discussed interlocking. Effectively, a given lever operates something, and prior to so doing it is either released by none, or one, or more other levers, and when pulled, it may release or lock other levers. Levers can also be locked by the block.

 

Normally, due to the way the tappets / sliders work the operation of one lever would lock the lever that released it.

 

The GW tables that I've looked at over the last few days show the lever number, its name / descriptor, a list of "released by" levers, and a list of levers that it "locks".

 

Furthermore, it is also possible that when a route is set, and the starter is pulled, it "backlocks" the route so that the route cannot be cleared until the train has cleared the block.

 

There are many contributors to RMWeb who can write with more authority than I on this! I haven't read the RM article though I did see last month's.

 

I think your "setlockrequirements" is doing what I have described above - you have described "onreq" & "offreq" which are similar to the "locks" and "released by", but I suspect that they are not exactly the same - I shall give this some thought!

 

I had in mind to create an excel table as described above - I think this can then be read into the Arduino code, though I'm not yet sure how. I then wanted to have each lever connected logically to a function loop, which would then verify the locking table and if allowed, act accordingly.

 

The question you raise about showing locked levers has also been on my mind. The red led is a good solution, and I do like the "flashing, flashing faster" approach, but it seems to me that it requires an extra Arduino pin per lever - I wondered if it's possible to use the connection to the switch to do both the lever input, and the led output, I guess the Arduino can swap between input & output modes as needed. I also thought about using buttons and LEDs to indicate the "virtual" lever position and locking state, but this seems to me to be moving away from the representative nature of a row of switches - I guess a case of horses for courses / rule 1.

 

It's all good fun - I'll have a play at some point, but I'm trying to get the turntable finished, so I have some space on the workbench!

 

Best

Simon

Link to post
Share on other sites

Thanks Simon, a few thoughts ...

 

If you write an Excel spreadsheet that can test your locking sequence then it should be a simple matter to have it present the requirements so that copy and paste would put them into the Arduino function.

 

As things stand my code uses 2 pins per lever. One for the "lever" switch and one for the output. I have an LED for the output for demo purposes and I guess that could stay for a working version. If the LED lights it means the lever is ON. I just use one flashing led (pin 13, the onboard led) to indicate all errors. I think in practical use the flashing will start before you get your finger off the switch/lever so it will be obvious which one is wrong.

 

The only way I can think of to reduce pin requirements is to use a PC screen for inputs instead of physical switches. You may be able to use something like a couple of 74HC595 chips to reduce the output pin requirement, but I think that's only an option with coloured light signals. Of course an Arduino Mega has more pins, or cheap breadboard Atmega328s could be used to provide local locking.

 

...R

Link to post
Share on other sites

Hi,

 

You should be able to get around the problem of x pins/lever by using shift registers. You'd use a "parallel in to serial out" IC to read the switch state, and a "serial in to parallel out" reg to drive the LEDs.

 

Each reg has 8 input or output parallel lines. They can be chained together so a few pins can be used to read or write quite a lot of multiple lines. You can also get I/O expander ICs which give you say 16 I/O pins on a chip driven by maybe 3 or 4 lines from the MCU.

 

Shift regs are really easy to use once you understand how to clock the data in. It took me a while to figure out that the first bit of data from a "parallel in to serial out" shift reg was ready before you pulse the clock.

 

That's my plan, if I ever decide to make one of these.

 

As for stopping the action I was thinking a switch known to be in error can just be ignored so the point or signal isn't changed. The LED tells you why it didn't happen.

 

Anyway, cool to see someone working on the software.

 

Regards,

David.

Link to post
Share on other sites

  • 2 weeks later...
  • RMweb Gold

Thanks Robin and Simon for your thoughts above.
I've only just come across this thread.

 

I particularly like the idea of downloading a “table” with all the interlocking for each lever.

It should never be underestimated how many times you will need to change the interlocking to get things right.

We (I assume) are not signalling engineers and thus will not be able to think of all the permutations/possibilities for the points and signals, let alone doing it with safety being paramount.

 

Although “safety”, (required to mirror the prototype we are trying to recreate), will probably get in the way of operability of the layout. Whilst not forgetting that 'our layout' will probably be VERY condensed in length with many parts, of the whole scenario, being off scene – ie. not really existing.

 

The nomenclature of signalling and signal interlocking is something I really need to know about but am finding that I have little time (priority?) to research this vital subject.

 

 

I know that the title of this thread states that this is for the Arduino but while the programming is in a “high level language” it should not be too difficult to adapt/modify the code for other micros.

The concepts and ideas certainly can.

(I only use PIC micros for example.)

 

 

As for the Lever being able to be physically moved whilst it is (allegedly) interlocked, I too have given this some thought.

For my solution, I also use 2 uController pins for each Lever. One to read the Lever's physical position – (in my case, it's an ADC value), and one for the LED for user feedback - (I use a Bi-colour LED).
The Bi-colour LED is used so that more meaning can be communicated back to the Layout Operator/Signaller/Loco Driver(!) with options of red,orange,green and various flashing modes being available.

 

 

This is such a fascinating thread with real application to model layouts.

 

 

Kev.

 

Link to post
Share on other sites

Kev, David, Robin,

 

Thanks for the thoughts & suggestions

 

Not much happening in the signalling domain on the SD workbench at the moment - turntable on edge whilst the Arduino pro mini gets sorted, but the 28xx is finally green following the pleasant weather of the last few weeks. ( Halfords mixed up Land Rover deep bronze green in a rattle can for £14 - very happy). So I'm getting it built up again, which means the bench is a tip... Too many jobs on the go at once.

 

Need to finish the King, put a chip in the Fowler, send my Lenz kit in for a s/w upgrade, and build a 1361 ST, as well as finish the turntable!!!

 

More soon, but don't hold your breath!

 

Simon

Link to post
Share on other sites

  • 11 months later...
  • RMweb Premium

I am looking into the various options for Signal Interlocking and have decided on using the Scalefour Lever Frame with three microswitches per lever, one operated by the "Latch Lever" and the other two showing the Normal / Reverse positions. I am proposing to "lock all" levers until such time as a valid "Latch Lever" is operated, this would release a "Solenoid Lock" to allow the lever to move. Once the lever has moved and the "lever latch" has been released all levers would be locked again. The only thing I'm not decided on is if I use a Arduino or just CMOS Logic chips; this thread has given me a few ideas!!

Link to post
Share on other sites

  • RMweb Gold

It is a bit six and two-threes, to be honest, and terminology usually reflects company practice. If pulling, say, the up advance starter releases the up distant, then it could be said that the up distant backlocks the up advance starter. Generally speaking, the logical consequence of this is to choose one way of describing it, and to stick with it, to avoid confusion.

 

Over 30 years ago now there was a series of articles on simple logic and locking in Model Railways. The layout Thame, joint MRC and SGMRS (as was, back then: SSMRS now) had electrical interlocking that was digital using a "black box". As per the prototype, the locking was on the catch handles, and not the levers. (On a full size frame, the levers offer sufficient mechanical advantage to send the locking frame.)

1.  The use of catch handle or direct (driven by movement of the lever) locking varied considerably - for example Midland Railway frame used catch handle locking as did their descendants, and many McKenzie & Holland/Westinghouse descendant frames also use(d) it,  but all of the GWR in-house designs, and those of the GNR and GCR used direct drive off the levers.  Overall on UK designed lever frames a quick run through a summary of the many designs suggests that direct locking drive was probably more prolific.   And I can assure you that on a Western 5 bar vertical tappet frame it is impossible to move a lever when it is locked - however much force you apply (or try to apply).

 

2. I think the major problem with model lever frames is how you actually apply locking to them.  Undoubtedly if you want locking to work absolutely prototypically the better answer is probably to use mechanical locking but if you can find a way of applying an electric lock to a lever frame (which would usually require a tappet to be provided in just the same way as would be done on a mechanically locked frame it would be feasible to electrically lock a small scale lever frame.

 

3.  interlocking the point/signal functions themselves is a different matter and in many respects far simpler because if they are electrically operated you can interlock them - you won't necessarily be interlocking whatever works them (if it is a lever frame) but you would be interlocking what is out on the ground baseboard thus avoiding conflicting point & signal or signal & signal settings (however it does mean that what is out there could disagree with the setting of your lever frame unless you have also physically interlocked its levers with each other.

 

4. As far as interlocking the actual functions is concerned there is no doubt in my mind that the simplest way to to do is to follow the prototype's locking rules and probably also its practice of setting out a locking chart by showing each lever with its 'Locks' and 'Released By' relationship to other levers - it's a very simple layout to follow but you need to know the locking rules to enable you to draw up the chart if you want a prototypical result.

 

5.  if people are interested I would be happy to set out the basic locking rules and conventions - which you can use however you produce your actual interlocking by whatever means.

 

If you wish to learn more about mechanical locking and some further detailed information on the subject there is an excellent page on John Hinson's site which was written by a former colleague Peter Woodbridge, a highly qualified Signal Testing & Design Engineer, - here -

 

http://www.signalbox.org/branches/pw/

 

It might also help to see some mechanical locking - in this case GWR 5 bar VT - to see how in this design the lever drives the tappets (which move vertically) through a cambox.  You can also see how the tail end of some tappets goes into a blue box - that box contains either a circuit controller or other form of electric lock and while you can't see the mechanism it gives an idea of what can be involved in adding electric locking to a lever frame in any scale

 

post-6859-0-94394000-1428081259_thumb.jpg

 

post-6859-0-91473600-1428081282_thumb.jpg

  • Like 2
Link to post
Share on other sites

Mike,

 

I'm interested...

 

I agree with your comment under point 2, (and the consequences in point 3) that it is actually rather difficult to electonically lock a model lever frame - effectively you'd need to put a solenoid on each lever to lock it - and then interlock these, rather than the simpler option of interlocking the points, signals, etc,.  My pal, John Mathews, previous owner of Scale Signal Supply, did develop a very nice frame and tappet arrangement, which Pete Linda still sell, but it is necessarily complex and expensive - good if you want to make a model box, but perhaps a bit of a diversion, if you actually want to make a model railway. 

 

I like Robin's solution - a red led, which flashes if you get it wrong at the lever frame - and flashes faster if you persist in getting it wrong!  This seems like a good compromise between function and cost/complexity.  I was pondering a led against each lever, but haven't yet worked out how to common the switch that the lever operates and the led, on a single pin of the Arduino - I bet it can be done and could offer a significant saving in wiring and I/O pins.

 

I also still want to make a simple table (eg in Excel) that I can then read into my Arduino, to set up the interlocking, and to be able to edit it easily.  Not spent any time on this over the last 6 months or more, but the cogs are still ticking round...

 

best

Simon

  • Like 2
Link to post
Share on other sites

Hmmm... just found this topic thread. Locking logic is something I'd like to create too, perhaps as Simon and Robin discuss earlier via levers and LEDs connected to an Arduino / ATMega chip.

 

Mike - excellent info there, thanks for compiling that. If you're able to set out the basic locking rules and conventions, it would help us 'lay' modellers to ensure we're on the right track.  :)

 

Simon - it looks like it's fairly easy to read in a CSV (comma separate values) data file to the Arduino during processing/upload:

http://arduinobasics.blogspot.cz/2011/06/reading-text-or-csv-file-using.html

 

So I guess you could create a template worksheet in Excel (perhaps with another sheet containing help info), which could then be saved as a CSV file for import to an in-memory Array by an initial Arduino 'import' routine. The template data would need to be in the form of a matrix I would think. I began to try to work out a simple structure for that, but then had a look at Mike's PW link above, which confirmed that prototypical locking is really complex, so I will wait for Mike's explanation before thinking on this further!  :scratchhead:

 

 

Alan

Link to post
Share on other sites

  • 2 years later...

Although I'm not interested in computer control of a layout, I'd like to create a representation of working Token Block signalling and although I've not yet thought too much about how I want to achieve that, I'm tending to think a software solution may be the way to go.  I'd therefore be interested in any updates from those who have tried this before - no-one has posted on this thread in two years.  Is that good or bad?

 

In my case, I'm not bothered about a lever frame.  As I'll be using colour light signalling, I envisage the use of momentary push buttons to set a route.  Whilst I could wire up a switch to change a few points and clear a signal, it's the 'checking' part that I see an arduino as a possible solution.

 

Basically I'd like to press a button and a 'system' first checks that there are no conflicting routes already set (ie it would check that certain signals were at red).  It would then check that various track circuits are showing as unoccupied.  This would be to ensure that points are not thrown under a moving train.  Having confirmed that no conflicting routes are signalled, these routes do not have a train on them and the path that I want to set is clear, the system then throws the required points.  It would then check that the required points have thrown and clear the signal.  I'd also want to relay this information back to a control panel that has lots of LEDs (around 38) that will indicate the way each set of points is lying, what signal aspects are showing at each signal and which track circuits are occupied.

 

Finally, once the train has started moving and occupies the next track circuit after the signal, this will be set back to red automatically since this is something i often forget to do when operating our club layout.

 

Does an arduino sound the best way to achieve this, or are there any alternative solutions worth looking at?  The number of pins available on an arduino may be an issue, although its been suggested that there are ways to overcome this.  The interlocking only needs to consider four points, seven signals of varying types and probably 12 track circuits.  There would probably be eight route setting switches.

 

Any ideas welcome.

Edited by Dungrange
Link to post
Share on other sites

Does an arduino sound the best way to achieve this, or are there any alternative solutions worth looking at?  The number of pins available on an arduino may be an issue, although its been suggested that there are ways to overcome this.  The interlocking only needs to consider four points, seven signals of varying types and probably 12 track circuits.  There would probably be eight route setting switches.

 

I like Arduinos and that can certainly be done with Arduinos. I am building something similar at the moment. I am using an Arduino Mega at the control station - so it will take inputs from switches and operate LEDs on the panel. And it will send messages to a few "slave" bread-board Atmega 328s to operate points and uncouplers (using servos) and colour light signals. My plan is that all of the "slave" boards will be identical so that all the "intelligence" will be in the Mega.

 

Part of the reason for the master and slave idea is to reduce the amount of wiring between the control panel and the layout boards. Communication will just require 3 wires - Rx, Tx and GND.

 

This system won't have interlocking - but that would just require extra software.

 

Light Dependent Resistors embedded between the sleepers are a cheap and convenient way of detecting the presence of trains

 

...R

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...