Entry posted by Fen End Pit
4,644 views
Over the last week I've been experimenting with my MERG CBUS components and JMRI with a view to producing a way to make a mechanical signal box frame which is interlocked and interfaced with a PC. The requirements I've set for myself are as follows:-
- I want a mechanical lever frame, with proper chunky levers to pull. I've already build one from the Scalefour stores produced by the Shropshire & Herefordshire Area Group (######).
- I want the frame to prevent me from setting conflicting routes, basically I want prototypical interlocking of the levers.
- I'd like to be able to change the interlocking easily if I make a mistake when I define it, I'd rather not have to re-file the notches on a load of mechanical locking bars.
- I'd like to be able to run the layout without having to have a PC on, but are prepared to only have the interlocking working with a PC connected.
The plan is to use a simple electro-mechanical locking bar on the frame which will be unlocked if the lever to be pulled should be free. In simple terms each lever features two micro-switches:
- The first which is off when the lever is normal and on when it is reversed.
- The second is on the catch handle of the lever and is on when the handle is pulled, indicating that this is the lever which the signalman wants to change.
In basic operation the signalman pulls a catch handle on a lever which sends out a signal saying 'I want to pull lever no. X'. The software on the PC then works out if lever X is free based on the position of all the other levers and if appropriate removed the lock from the frame. As I'm not trying to achieve HMRI levels of safety I'm OK with the entire frame being locked/unlocked with a single bar. There is obviously a risk that the signalman pulls the catch handle on an unlocked lever, unlocks the frame and then pulls a completely different lever but I'm probably going to live with that limitation in safety.
From my experiments with CBUS and JMRI I've now been able to make the basic idea work. I'm sure there may be other better ways to do this so I'll be interested in any feedback from experienced JMRI users. One thing I've found from playing with JMRI is that the British approach to signaling isn't necessarily the way JMRI (or certainly most of the documentation) is written. I'm hoping what I've done will make some more sense to British modellers.
For my demo board I had my levers with one switch on the lever and one on the catch handle and a number of outputs which will ultimately be linked to servos. At present I haven't implemented the locking bar and am just showing a light when the frame is locked. However I'm confident that this will be relatively easy to implement.
Training the CBUS boards
The first step was to train the CBUS output board (CANACC8) to respond to the relevant events on the CBUS consumer board (CANACE8c). This is basically a case of selecting the output you want to train, then sending the signal which you want it to respond too. All pretty straight-forward and explained in the relevant MERG CBUS documentation. The result of this is that pulling lever 1 makes output 1 change, lever 2 makes output 2 change etc. I used 4 events on the CANACE8c to the the turnouts and 4 to be the catch handles. Ultimately the events from the catch handles don't need to have any corresponding actions on the CBUS hardware as their only use is in telling the PC which lever is trying to be pulled.
Starting with JMRI
Having got the test rig so that levers and catch handles on the frame made appropriate outputs on the consumer board the next step was to link it up to the PC using the CAM-USB. I download and installed JMRI and started it up, telling it that it was connected to the layout via MERG-CBUS. This worked fine and when I select CBUS console I could see events from the switches being displayed.
The next step is to define the turnouts, adding the name of the CBUS event which changes the point and giving it a meaningful User Name, I made the User Name include the type and lever number of the for simplicity of understanding later e.g. turnout2, home1. Having selected that the turnout is a MERG controlled turnout the system code is sent for you a MTxxxxx, the format being +N{node #}E{event #}.
You have to put an entry in the turnout table for both turnouts and signals so here we have defined that there is a signal I'm calling 'shunt4' and it is changed by sending a CBUS event node 1 event 4. The complete turnout table, with 4 levers and a 'turnout' which will be my locking bar eventually looks like this.
Next I needed to define a signal, and this is where the American nature of some of JMRI's documentation caused me some head scratching. When adding a signal you make up a system name of the form MHxxx, I decided to make xxx the lever number on the frame for consistency.
The User Name has to be the User Name defined in the turnout table. The completed signal table looks like this. By clicking on the 'state' button we can change our signal from red to green.
Next I put the first two elements, home1 and turnout2 onto a simple layout diagram. (I found an icon for a home signal I liked but these are pretty straightforward to change as they are just .GIFs)
At this stage clicking on the turnout or the signal changes the light representing it on the test rig because the PC sends out the appropriate CBUS event. The lever also changes the light but this change is NOT reflected on the diagram on the PC (and obviously changing on the PC doesn't change the lever on the test rig)
In order to get the PC to see the change in state of the lever I define a sensor using the same CBUS node/event as the for the turnout table. Again I gave a User Name based on the number of the lever with the intention of hopefully keeping things consistent and easy to follow later on.
Now what I needed to do was make a change in the sensor on a lever also change the state of the object in JMRI. A side effect of this is that the PC will then send the same CBUS event out, effectively duplicating the message to the accessory, but this doesn't appear to be a problem. The way this is done is to define 'logix' in JMRI. For each lever I define a two rules, one that says when you see the sensor on the lever go active you set the turnout to reversed and the other which puts the turnout back normal when you see the sensor for inactive.
Having created this logic the lever on the test rig now changes the light representing the accessory and the relevant symbol on the layout diagram in JMRI. I drew some suitable GIFs to show a lever normal and reversed in various colours to match a lever frame.
Defining some locking
Now want I wanted to do was use a sensor on the lever's catch handle to workout if the locking bar could be moved. You will see on the layout diagram above a little green dot indicating the catch handle on the lever is normal (i.e. not pulled). What needs to be defined is two (or maybe three) rules that define what actions happen with the catch handle sensor.
The first rule, which will be the same for all catch handles is to restore the lock after the catch is released.
The second rule is the one which does the work, this removes the locking bar when the catch handle is pulled, but only when the other turnout/signal/sensors are set correctly.
In this example you the locking is only removed on signal 1 if sensor 2 is inactive, in other words lever 2 reversed locks lever 1 or the home signal can only be pulled off if the turnout is set for the straight, normal, route. Obviously a matching rule to lock the point if the signal is clear needs to be applied to the catch handle on turnout2.
Finally I used the icon for a Scissors crossover icon to show on the diagram if the locking bar is locked or unlocked (when the crossing over route is shown it means unlocked)
The Third set of rules will be needed for levers which are locked in reverse as well as normal.
Conclusions
Well the basic components are there to allow me to build my electro-mechanically interlocked frame. The 'Logix' part of JMRI seems to be comprehensive enough to cope with most forms of locking. The hardest part is going from the logic you usually think of when doing locking (lever 2 locked by lever 1) in terms of what is released by what (level 1 released by 2 normal).
I'm sure there must be many alternative ways of achieving what I done, I'd really like to hear your suggestions.
David Barham
1 Comment
Recommended Comments
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 accountSign in
Already have an account? Sign in here.
Sign In Now