Arduinos - applications & stuff

[J_F_S]

Many thanks for the post Simon, however, I am struggling a bit to understand the lever frame set-up. If I understand correctly, you are using the CAN bus to multiplex the leverframe microswitch positions to the servo controllers. But, if that is 'all' it is doing, this seems to me to be massive overkill. On the Leeds set-up we just used 25 way D cables for this purpose - on the 70-lever mechanical frame we needed 3 of these, for the 55-lever frame and each of the NX Panels, we needed two for each - controlling over 100 point ends or signals.
This hardwiring has the advantage of simplicity, and rock solid reliability whilst the actual conections at the frame and servo ends are exactly the same regardless of using mulitiplexing or hardwiring. Putting that another way, with reliability as the prime aim, even where the Arduinos are used to provide the control/interlocking functions, we still used hard wiring from the panel outputs to the servos. That way, if ever anything stops working (and so far it never has) a voltmeter is the only tool needed!

Is it that you are intending to provide interlocking functionality via the Arduino, or is there another advantage to going this way which I have overlooked?

As I mention in my post mentioned above, we have been very queesy about introducing the Arduinos (Teensy in our case) because if they ever do 'sit down' on us, there will be 15 or so operating crew all standing about with nothing to do whilst 'somebody' switches off and on again in the hope that clears the lock-up! So far, so good, but...

 

[ovener]

Nice work. Serious amount of veroboard there!

 

[magmouse]

Hi Nick,

the main gripe is that I can adjust brightness levels on each channel, but I have not (yet) provided any means of saving the settings, so when I turn it all off, I lose them. This is not insurmountable. If you wanted to, you could run 15 PWM channels on a Mega, and it would be entirely feasible to have settings saved on an SD card if you wanted to. Equally, you could have a “mixer board” with a pot per channel, and simply use the Arduino as a simple multi channel dimmer.

Indeed, you could arrange for lights to come on in a sequence, in response to other things happening (room lights being dimmed, for example) and with some random effects too (eg bathroom or office light).

very versatile.

and time consuming. Which is why the w-iron etches haven’t been done…

cheers
Simon

Thanks - so nothing to do with the technology itself, then. The problem with this hobby is it is crammed with sub-hobbies, each of which could be a full-time occupation in itself!

I am planning to be able to program, save and recall 'scenes', with a balance of various light sources and slow fade times to be able to go from day to dusk, for example.

Nick.

 

[simond]

Thanks - so nothing to do with the technology itself, then. The problem with this hobby is it is crammed with sub-hobbies, each of which could be a full-time occupation in itself!

I am planning to be able to program, save and recall 'scenes', with a balance of various light sources and slow fade times to be able to go from day to dusk, for example.

Nick.

That sounds entirely feasible. And you could spend days tweaking it….

 

[simond]

Many thanks for the post Simon, however, I am struggling a bit to understand the lever frame set-up. If I understand correctly, you are using the CAN bus to multiplex the leverframe microswitch positions to the servo controllers. But, if that is 'all' it is doing, this seems to me to be massive overkill. On the Leeds set-up we just used 25 way D cables for this purpose - on the 70-lever mechanical frame we needed 3 of these, for the 55-lever frame and each of the NX Panels, we needed two for each - controlling over 100 point ends or signals.
This hardwiring has the advantage of simplicity, and rock solid reliability whilst the actual conections at the frame and servo ends are exactly the same regardless of using mulitiplexing or hardwiring. Putting that another way, with reliability as the prime aim, even where the Arduinos are used to provide the control/interlocking functions, we still used hard wiring from the panel outputs to the servos. That way, if ever anything stops working (and so far it never has) a voltmeter is the only tool needed!

Is it that you are intending to provide interlocking functionality via the Arduino, or is there another advantage to going this way which I have overlooked?

As I mention in my post mentioned above, we have been very queesy about introducing the Arduinos (Teensy in our case) because if they ever do 'sit down' on us, there will be 15 or so operating crew all standing about with nothing to do whilst 'somebody' switches off and on again in the hope that clears the lock-up! So far, so good, but...

yep, I’m using CAN to connect the control panels to groups of actuators.

I don’t think it’s overkill at all, as it means a three-wire bus can carry the control signals throughout the layout (which will be quite large, but nowhere near your set-up) and a local slave (and local power brick) can deal with whatever it’s required to do, with very short wiring runs. A local reset can be arranged at each node, so a full turn-off-turn-on will hopefully not be necessary, and it is easy to program in delays so that everything starts comfortably in sequence when I turn the layout on.

I certainly don’t want everything hard wired. Reliable, yes, but lying under a baseboard flicking solder in my eye, I’m too old for that game! And, I’d suggest, it’s the logical alternative if you want the signalling & pointwork control separate from DCC - though I imagine it would be relatively easy to build an interface to allow the DCC to put commands on the CAN bus if there were a need.

And given the local nature of the slaves, fault location should be relatively easy if it’s ever required. If nothing works, check the frame, if one district doesn’t work, check that.

I’m aiming to do some custom PCBs for the slaves as they’re a bit fiddly to wire up and I‘ll have more than a couple, maybe 5-10, as they’re cheap - less than a tenner - and it’s worth putting one where you need it, rather than saving a few quid and running loads of wire under the layout. The initial prototype was a collection of bits on the bench with loose wires, the one I photographed above was the result of yesterday’s efforts and is now in Excel & CAD and will be committed to KiCAD when I’m inspired to do it. The slaves are designed to operate servos, but have 12 outputs comprising 5V, GND & a digital pin, which can easily be used for colour light, lighting, or a stepper controller with minimal effort.

Doing it this way also means that I can have all the point & signal control hardware bits and pieces in a box waiting for the trackwork, rather than have to build and wire it when the baseboards are built.

Regarding interlocking, I rather like the mechanical frames that John built, and I may well modify them to suit my track layout. It is, of course, perfectly feasible to build it into software. A chap called Fabrice Fayolle (sp?) did quite a bit in the Cercle Zero magazine and on RMW but I haven’t seen him about for a while. It would be ideal to simply upload an array for the locking table into a general program, but I suspect a lot of work, probably easier to simply write the program for each instance.

I guess like so much in our hobby, you pays yer money and you takes yer pick..

 

[simond]

Another rabbit hole here.

PASSIM Interlocking Project

Just wanted to flag up this project on which I am working. The intention is to develop an interlocking program for an Arduino single-board computer. The first phase of the project is to develop a Windows program with which to prove the interlocking logic for a simple station layout. If anyone is ...

www.rmweb.co.uk

which then led me off down another, and I found a lot of the history of my loco shed control, which, unwisely, I had initially done by I2C - the change to CAN was a fundamental step in the right direction.

@-missy- I also found a much earlier post about gear hobbing…!

 

[michael080]

the main gripe is that I can adjust brightness levels on each channel, but I have not (yet) provided any means of saving the settings, so when I turn it all off, I lose them.

Simon,

why not storing the values in the Arduino EEPROM?

https://www.arduino.cc/en/Tutorial/LibraryExamples/EEPROMWrite

You could attach a button with the function "store all momentary settings in the internal EEPROM."

 

[simond]

Simon,

why not storing the values in the Arduino EEPROM?

https://www.arduino.cc/en/Tutorial/LibraryExamples/EEPROMWrite

You could attach a button with the function "store all momentary settings in the internal EEPROM."

thanks Michael. I never got round to it! Sounds like a sensible solution.

thx
S

 

[J_F_S]

Yep, I’m using CAN to connect the control panels to groups of actuators.

Many thanks for the informative reply Simon. I certainly see where you are coming from. and I could not agree more about having nothing below the baseboard - on John's layout, there are cupboards under there as everything is mounted on the basboard fronts, including the servos which then drive the points via over-baseboard wire-in-tube whilst the signals plug-in from above. But my point was that the final connection to the servo is independent of the means of transmission from the frame - at some point you have one wire per lever/one wire per servo! Of course I over simplified how John makes the actual servo connections on Leeds - he uses the MERG controllers via a local relay - it is these which are hardwired to the switches via the D leads. A complication is that in addition to the "proper" controls, an over-ride allows the points to be worked from manual switches allowing John to work the layout when none of the rest of us are there!

Having built and fully interlocked four quite large installations for Leeds, (each of them bigger than most people's layouts!) using mechanical, relay and software approaches, I am getting a pretty good idea of the upsides and downsides of each. But if there is one thing I have learned from my involvement with the Leeds project, it is that both problems and solutions tend to be rather special for such a complex situation and things which are fundamental to us might be irrelevant to others.

Regarding interlocking in Arduinos, I use a large struct (though if you know enough about C++ an object might be better) to hold all the data which is created in an XL spreadsheet (to be human readable) and then copied and pasted into the code. The same approach is used for mapping all the I/O connection tables, LED function maps. Push button IDs etc. - the only thing "hard coded" is the logic which is universal and therefore transportable to any layout - so the code contains no "magic numbers" of any kind.

I would be happy to post some code snippets if you (or others) would be interested but since no one asked in response to my Leeds post, I assume no one is bothered.

<on> rant mode
I had a look at the PASSIM project - without wishing to be disrespectful, what a *^*%$ load of cr*p. No wonder there seems to have been no update in a while. I found it totally frustrating: these people do not know the first thing about either signalling or interlocking and have not troubled themselves to learn about it. Worse, they imply no one has ever previously signalled or locked a model railway correctly - I beg to differ and so would many of my modelling friends; one of whom wrote about his interlocked frame in MRJ 35 years ago and has exhibited with it over 50 times since! To PASSIM I say why not start by understanding the principles which have been developed by the real thing over 200 years? There is no problem we face on a model which has not already been solved many times over and it has never been easier to research such things. For my part, I went in my first mechanical signal box 58 years ago, my first panel box 2 years later. And at the age of 14, I spent my Sunday afternoons working a box on an electrified main line (12 trains per hour) whilst the signalman washed his car outside! I built my first interlocked lever frame 54 years ago - and a poor thing it was - and so I reckon to know a bit about the job by now; yet, every new project, every day; I learn more - and never by re-inventing wheels! (my mechanical locking is pinched from the GW!)

If the PASSIM people want to see mechincal locking simulated in Windows, they could look at my own simulations - including 131 levers at Exeter West and the busiest frame I have ever seen - with 94 working levers - at Crow Nest Junction ... Mechanical Signalbox Simulations for Windows

<off> rant mode

Looking forward to further developments...

 

[simond]

And at the age of 14, I spent my Sunday afternoons working a box on an electrified main line (12 trains per hour) whilst the signalman washed his car outside!

It sounds like you, and my pal, John, would have got on rather well. He sadly wouldn’t write it all down but he blagged his way into (and operated) an awful lot of boxes in his 90 years.

I’ve only managed one, Moreton in Marsh, and that was 30-some years back.

 

[simond]

Meanwhile,

one SSS dummy, recovered from the Greater Windowledge Railway, mounted on a servo mount and wired up so the light works from the servo supply. Don’t know what happened to the top of the lamp. 3DP to the rescue. One day.

 

[simond]

Regarding interlocking in Arduinos, I use a large struct (though if you know enough about C++ an object might be better) to hold all the data which is created in an XL spreadsheet (to be human readable) and then copied and pasted into the code. The same approach is used for mapping all the I/O connection tables, LED function maps. Push button IDs etc. - the only thing "hard coded" is the logic which is universal and therefore transportable to any layout - so the code contains no "magic numbers" of any kind.

This is where I imagined going, before getting John’s frames. I will see, one of these fine days, whether diy tappet locking or copying your approach (and your code, if you would be kind enough to share) is the way forward I wish to follow.

 

[J_F_S]

This is where I imagined going, before getting John’s frames.

They are wonderful and it would be mechanical locking for me! The balance point where mechanical locking becomes too much, will of course, be different for everyone. Equally, realistic operation of the signalling is not as high on everyone's agenda as it is on mine - though I am working on that - so personal choices again.

I am at the moment working on a general 'logic' system using a Teensy (for memory reasons) which would be intended to replicate 'any' relay-based control (including interlocking as just one example). The idea would be to have (say) 64 12v inputs coming from the layout and 64 outputs (each about 250mA peak) going back to it, the connections between them being determined by software - thus (like a ULA) the logic could be freely programmable.

Electronically it is simple (for us) as we already have the hardware. The challenge is to design the software such that it can be configured in XL by anyone - even with no programming experience whatsoever - the same principle as I used in the NX panel software - but not so straight forward for more flexible general control applications.

My personal philosopy is that the design of the software should take about twice as long as the coding of it. Many 'programmers' I come across seem to think that coding should take 1/3 the time with 2/3 reserved for debugging. They don't seem to understand what I mean by "design" and they certainly never expect code to work first-time! (not that mine ever does!)

I can certainly post some code - but it is the design which is key ... !!