A few Arduino Questions

[St. Simon]

Hi,

 

Despite having some (albeit fairly basic) Arduino experience, I have a few questions concerning a new project. 

 

The project is to create a full prototypical interlocking for my new layout, I'm basing the interlocking on British Railways SW67 Free-Wired Route Relay Interlocking circuits and I'm simply converting these relay logic statements into 'if' statements in Arduino using nested 'and' and 'or' conditions (so far I'm upto 2300 lines and I'm quite far from the finish!)

 

My first question is to with replicating the characteristics of certain types relays. Specifically slow to drop relays, these are relays that are used in certain circuits to prevent a relay de-energising when 'switching' between conditions that energize it. So, for instance if a relay needed a switch in either one of two positions to energize, the relay would be slow to drop to prevent the relay de-energising as the switch was in the center position as the switch was switched over (I hope that makes sense). How would I go about replicating these relays without using the 'delay' function (as I want the code to run in the background).

 

My second question is related, sort of, how many timers can an Arduino run at once? I have the possibility of up to severn approach locking timers running at once.

 

My third question is what is the best way of making an LED flash under one condition, but show steady under another condition? Is is best to have to different outputs, one going straight to the LED and one going via an external flashing unit or do the flashing sequence internally? I would need up to 14 LEDs show either steady or flashing depending on the conditions.

 

My forth and final question (for now), is what is the simplest way to expand the I/O capabilities of an Arduino? I have worked out so far that I require 63 inputs (switches / buttons and track circuits) and 110 ouputs (15 to Arduino slave units, 9 to relays and 86 to LEDs).

 

I hope someone can help with this!

 

Regards,

 

Simon

Edited February 26, 2019 by St. Simon

[melmerby]

My first question is:

Are you using Unos?

If so have you considered the Mega? More I/O pins/More Memory/faster.

 

Second question:

Why Arduinos?

Surely you could do this with a computer running an railway automation program & DCC?

 

See Here:

 

Edited February 26, 2019 by melmerby

[Baby Deltic]

You could use 74595 shift registers or I2C devices to expand the I/O. A mega has a lot more I/O than an UNO as mentioned. I would use a switched 555 to flash LED's because several routines doing the same job at the same time will load the CPU unnecessarily.

[Junctionmad]

1 hour ago, St. Simon said:

Hi,

 

Despite having some (albeit fairly basic) Arduino experience, I have a few questions concerning a new project. 

 

The project is to create a full prototypical interlocking for my new layout, I'm basing the interlocking on British Railways SW67 Free-Wired Route Relay Interlocking circuits and I'm simply converting these relay logic statements into 'if' statements in Arduino using nested 'and' and 'or' conditions (so far I'm upto 2300 lines and I'm quite far from the finish!)

 

My first question is to with replicating the characteristics of certain types relays. Specifically slow to drop relays, these are relays that are used in certain circuits to prevent a relay de-energising when 'switching' between conditions that energize it. So, for instance if a relay needed a switch in either one of two positions to energize, the relay would be slow to drop to prevent the relay de-energising as the switch was in the center position as the switch was switched over (I hope that makes sense). How would I go about replicating these relays without using the 'delay' function (as I want the code to run in the background).

 

My second question is related, sort of, how many timers can an Arduino run at once? I have the possibility of up to severn approach locking timers running at once.

 

My third question is what is the best way of making an LED flash under one condition, but show steady under another condition? Is is best to have to different outputs, one going straight to the LED and one going via an external flashing unit or do the flashing sequence internally? I would need up to 14 LEDs show either steady or flashing depending on the conditions.

 

My forth and final question (for now), is what is the simplest way to expand the I/O capabilities of an Arduino? I have worked out so far that I require 63 inputs (switches / buttons and track circuits) and 110 ouputs (15 to Arduino slave units, 9 to relays and 86 to LEDs).

 

I hope someone can help with this!

 

Regards,

 

Simon

Everything you want can be done in software , if you structure the code correctly and this is your challenge. 

 

(A) you can implement multiple timers in software driven by a single hardware timer 

 

(b) delays , like flashing an led , need non blocking delays , essentially you record a time stamp and periodically return to check the timer has either expired or exceeded a given value , if so you toggle the led , during the time your not checking the timer , you can do other non-blocking tasks ( the techniques are often called superloop programming ) 

 

(c) a better construct would be to implement an RTOS , but this is not simple stuff

 

to accept lots of inputs and drive lots of leds , you’ll need to consider input matrix scanning and output multiplexing ( or even charlieplexing ) along with expanded IO if necessary 

 

you are entering complex embedded systems software here , so you need to understand the underlying software constructs before hacking any code together 

 

 

[Baby Deltic]

19 minutes ago, Junctionmad said:

Everything you want can be done in software , if you structure the code correctly and this is your challenge. 

 

(A) you can implement multiple timers in software driven by a single hardware timer 

 

(b) delays , like flashing an led , need non blocking delays , essentially you record a time stamp and periodically return to check the timer has either expired or exceeded a given value , if so you toggle the led , during the time your not checking the timer , you can do other non-blocking tasks ( the techniques are often called superloop programming ) 

 

(c) a better construct would be to implement an RTOS , but this is not simple stuff

 

to accept lots of inputs and drive lots of leds , you’ll need to consider input matrix scanning and output multiplexing ( or even charlieplexing ) along with expanded IO if necessary 

 

you are entering complex embedded systems software here , so you need to understand the underlying software constructs before hacking any code together 

 

 

 

I suppose another way of using one of the internal timers could be to use a timer triggered interrupt to break into a subroutine which either toggles all of the LED's being flashed on or off depending on the last  known state. You would need to store the port status word in another register    and know exactly what data to write to toggle the outputs being simultaneously flashed whilst maintaining the state of any outputs not being flashed. I would be tempted to use an external timer and try use a bit of 7400 or 4000 series logic. It would mean using two outputs per LED though as you would need to be able to have standard on/off and gated timer to flash. A lot of Arduino projects in the various books do use external components.

[eldavo]

All perfectly doable and not really that complicated.  For large numbers of inputs and outputs look at examples of using 74HC595 and 74HC165 chips. Lots of examples on Arduino playground and other places. Also cheap as chips! You can use I2C devices but these basic chips can be strung together very simply.

 

I've never used an external flasher circuit as I've always found the Arduino is fast enough to do the work as long as your code isn't dreadfully inefficient.

 

Timers are easy. Do it all in the loop() function. Grab the current time using the millis() function then simply compare against the time you last made a state change. Multiple ifs don't cost much. Just note down when you last changed a flashing LED from on to off or changed a switch etc. and do a compare. Only use millis() once at the top of your loop() function as it's much more efficient.

 

Happy to share examples of all this if you need it. The Arduino is a great tool for the job.

 

Cheers

Dave

 

[Ian Morgan]

Timer Interrupts are your friend, if you can get your brain around them. Set up some public variables to use as counters and flags which your main program sets to indicate what relays to operate, or which LEDs to switch on, off or flash, and then your interrupt handler can check the flags to see what it should do (on/off/flash each LED), then increment flash or delayed off counters and switch LEDs or relays on or off as required, with a bare minimum of code. Your main program can then do its main job without needing to bother about delays/timers or whatever. With some thought, you could probably control all the LEDs and relays with just the one interrupt handler.

[Junctionmad]

1 hour ago, Ian Morgan said:

Timer Interrupts are your friend, if you can get your brain around them. Set up some public variables to use as counters and flags which your main program sets to indicate what relays to operate, or which LEDs to switch on, off or flash, and then your interrupt handler can check the flags to see what it should do (on/off/flash each LED), then increment flash or delayed off counters and switch LEDs or relays on or off as required, with a bare minimum of code. Your main program can then do its main job without needing to bother about delays/timers or whatever. With some thought, you could probably control all the LEDs and relays with just the one interrupt handler.

 What I do , where I have an application that potentially needs several non blocking timers , is create dynamically a “ timer chain” my application can request a millisecond timer , load it woth a count down value and examine it when it’s reaches zero , this timer is not shared with any other functions , the timer code optionally allows me to alternatively request a seconds and minutes timer for much longer delays. I can create as many timers as memory constraints allow. 

 

The software timers are driven fron a single hardware timer using an interrupt to update the timer chain 

 

there’s no need for external timer logic , that’s  quite frankly daft. The code overhead is very small 

 

using one interrupt tends to get messy if you have a requirement for timers of radically different time periods , ie say a 30 ms debounce timer and a 3S application timer , as the timer range may ( and usually isn’t ) enough to handle that. , it’s ok where the various delays are all reasonably similiar in scale 

 

Dave 

Edited February 27, 2019 by Junctionmad

[St. Simon]

13 hours ago, melmerby said:

My first question is:

Are you using Unos?

If so have you considered the Mega? More I/O pins/More Memory/faster.

 

Second question:

Why Arduinos?

Surely you could do this with a computer running an railway automation program & DCC

 

 

Hi Keith,

 

The answer to your first question is I was planning on using a Mega (I already have 2) as the Master interlocking with some outputs going into Nanos (or possibly an Unos) as 'slave' units which work out aspect sequences and Train Describers.

 

The second question is a good one, I had originally intended to use JMRI running via a computer (I had researched other systems, but they didn't give me the fully prototypical interlocking I wanted without great cost and great effort), but even then, I found that JMRI 'user interaction' for me wasn't good and there was very little information on how I might go about creating a prototypical interlocking. Also, I find the Arduino Langauage easy to use, particularly now I have discovered how to created nest 'or' and 'and' statements, I've coded 75% of the interlocking in Arduino in the same amount of time it took me to work out to start drawing a track out in JMRI.

 

In answer to some other questions, I know that multiplexing and timers are getting deep into the bones of the software, but my plan is to code the interlocking without these and then go back and add them in later (the actual interlocking code won't be affected by that, it will be the reading and writing of I/Os which will affect it) either myself or by a friend who knows Arduino and has done some stuff like this before.

 

Simon

[St. Simon]

Hi,

 

I've had a thought about this and I think I'll push the flashing and approach locking timers on to external modules rather than code them in the software. I'm also going to reduce the approaching locking timers down to just 2 (an 'Up' and a 'Down') to make things easier.

 

So, my first question still remains in how to I implement a slow to drop relay? Is this again creating a timer or something different I could do?

 

Simon

[melmerby]

6 hours ago, St. Simon said:

Hi,

 

So, my first question still remains in how to I implement a slow to drop relay? Is this again creating a timer or something different I could do?

 

Simon

Slow to Drop? I'm not familiar with modern signalling so if this isn't relevant ignore it:

Could you introduce a delay when the relay is released that isn't there when operating?

 

(I'm thinking on telecom circuits where relays were slow to operate or slow to release compared to normal)

 

[Junctionmad]

13 hours ago, St. Simon said:

Hi,

 

I've had a thought about this and I think I'll push the flashing and approach locking timers on to external modules rather than code them in the software. I'm also going to reduce the approaching locking timers down to just 2 (an 'Up' and a 'Down') to make things easier.

 

So, my first question still remains in how to I implement a slow to drop relay? Is this again creating a timer or something different I could do?

 

Simon

Slow release relays ( which I beleive is the correct technical term ) could be modeled by simplt having a delay in software , from when the control to the relay activates to the activation of the “ logic output “ of the relay in software 

 

note it’s rather something of a “ conceit “ , because in software the conditions that lead to the necessity of a slow release ( also slow pull-in ) are rather “ manufactured “ , whereas in mechanical systems , there are inherent delays 

 

in other words there may be no actual point in implementing it as the conditions that necessitate it may ( or will not ) ever occur 

 

an an example would be a switch input being detected in software , in a real life system , ie there is no computer , so the switch has a period where the contact “ breaks “ before “ makes “ , hence a slow release relay would be utilized to prevent a “ glitch “ , 

 

however in software the transisition is in effect instantaneous , and the output transition is in effect equally instantaneous 

 

so so unless you introduce those peculiarities in your software , there will not be situation, where you need to emulate a slow release relay 

I mean , I presume you are modeling the relay logic in software , but not emulating the mechanical characteristics of the relay , what would be the point 

dave 

Edited March 1, 2019 by Junctionmad

[raymw]

If the slow release is there to allow another fast release to operate first, then you can't consider software transitions to be instantaneous. You can't consider software transitions instantaneous, anyway if interfacing to the real world. The OP needs to draw some block diagrams (not signalling blocks...) and isolate the various functions that need to be achieved. It may help to understand what is trying to be achieved in the full size railway, and how they achieve it in their simulation. He can then simulate what the full size railway needs, or simulate the full size simulation. An implementation of the MVC paradigm would most likely be of benefit.

[St. Simon]

19 hours ago, melmerby said:

Slow to Drop? I'm not familiar with modern signalling so if this isn't relevant ignore it:

Could you introduce a delay when the relay is released that isn't there when operating?

 

(I'm thinking on telecom circuits where relays were slow to operate or slow to release compared to normal)

 

 

Hi Keith,

 

Yes, in real world it is slow to release, the railway term is slow to drop.

 

To try to explain simply (without the full signalling jargon), I need to delay the resetting of a variable in Arduino (which I'm using to replicate relays that would be used in the real thing) whilst when one condition to set it is lost and another is gained. I don't think a simple delay would be enough as it would stop the whole interlocking from processing (which it needs to do so that the conditions to set the variable are processed).

 

I hope that makes sense?

 

Simon

[raymw]

555 timer chips are less than 20p each on ebay.

[Junctionmad]

What you are looking for is called non blocking timers 

 

using external 555 is daft given the power of an Arduino 

 

the way you implement non blocking timers is to record a timer value , loop doing others things and periodically check k the terminal value desired 

 

then you act on that event 

 

It would seem you are a novice at software , so it maybe that you ate biting off more then you can chew with this application initially 

 

I suggest you look at the huge range of Arduino applications and practice timers and loops 

 

jumping into  a full scale application may be a big jump

at this stage 

 

( I say this because what you want is very easy to implement in software ) 

Edited March 1, 2019 by Junctionmad

[Junctionmad]

6 hours ago, raymw said:

If the slow release is there to allow another fast release to operate first, then you can't consider software transitions to be instantaneous. You can't consider software transitions instantaneous, anyway if interfacing to the real world. The OP needs to draw some block diagrams (not signalling blocks...) and isolate the various functions that need to be achieved. It may help to understand what is trying to be achieved in the full size railway, and how they achieve it in their simulation. He can then simulate what the full size railway needs, or simulate the full size simulation. An implementation of the MVC paradigm would most likely be of benefit.

For the purposes of relay logic implemented in software in effect all transistions are instantaneous, you only introduce delays where outputs need to be delayed 

 

this is because there is no mechanical elements at play

 

so if event A must occur before event B or event B must occur only after event A , you can handle this with logic , not delays 

 

slow to release relays are primarily used to compensate for situations where a logic state is changing from one known to another but there exists an unknown state in between 

 

in software this doesn’t exist ( unless you specifically add it in ) 

even if you have mechanical inputs that have unknown or unspecified transistion states , it’s normal in software to remove this at the point you resolve input state , you don’t typically propagate the unknown state through the logic system as it’s wasteful , unnecessary and counter productive 

 

  

Edited March 1, 2019 by Junctionmad

[St. Simon]

2 hours ago, Junctionmad said:

What you are looking for is called non blocking timers 

 

using external 555 is daft given the power of an Arduino 

 

the way you implement non blocking timers is to record a timer value , loop doing others things and periodically check k the terminal value desired 

 

then you act on that event 

 

It would seem you are a novice at software , so it maybe that you ate biting off more then you can chew with this application initially 

 

I suggest you look at the huge range of Arduino applications and practice timers and loops 

 

jumping into  a full scale application may be a big jump

at this stage 

 

( I say this because what you want is very easy to implement in software ) 

 

Hi,

 

I thought that might be it, but I was hoping there might be a different way of doing it, I've coded timers before, but I just find them a pain to do.

 

I've written a few Arduino codes before, include two interlockings, but this will be first time I've coded a 100% prototypical interlockings.

 

It is just actually quite simple relay logic, I think I just need to see whether I can remove the slow to release from the circuits, I shall inquire!

 

Simon 

[Robin2]

For an example of how to do non-blocking timing  have a look at how the code is organized in Several Things at a Time

Note how each function runs very briefly and returns to loop() so the next one can be called. None of the functions tries to complete a task in one call. And there may be dozens of calls to a function before it is actually time for it to do anything.

 

And see Using millis() for timing. A beginners guide if you need more explanation.

 

...R