Solenoid connected to SSR, Arduino Rapid Firing

[BodhiSci]

Hi,

I have a pcb where there are 8 circuits like below connected to a arduino. Basically the arduino pin is on HIGH when it is off and Low when it is on. That doesn matter though I don't think. The issues is if I program the arduino to 500ms high the 500ms low in a loop, the solenoid will rapid fire when it first starts, then ususally it will go half a second on and off like all the other working ones, but then at the end it or in the middle sometimes it will rapid fire again. Can anyone tell me if this is just a Bad SSR or what? All the others work fine, one other had a minor hiccup but it seems ok. Thank you.



SSR Pin

1 - 12V Battery
2 Schottky Diode (SS3P6) AND Solenoid
3 Arduino Uno Pin #13
4 150 Ohm resistor to 5V

 

[Harald Kapp]

the solenoid will rapid fire

Do you mean the solenoid switches faster than the expected 500ms on/off?

What type of SSR and solenoid do you use?
Can you measure the current through the solenoid (or the voltage across it, if not the current through it) with an oscilloscope to show us the waveform and amplitude?

 

[Fish4Fun]

Hey BodhiSci!

I would strongly suspect the problem resides in the Arduino code.....On ReSet most or all I/O Pins on AVRs are in the "High-Z Tri-State" until initialized to some other state.....how the DDRx Register and the PORTx registers are initialized...and how "toggling" is actually achieved in code affects how the pin behaves.....frequently (to those not familiar with the AVR way of doing things) quite counter-intuitively....I would suggest you review the Atmel datasheet segment entitled "I/O-Ports" for the particular processor on the particular Arduino you are using and post any questions in the Micro Controller forum.....If the solenoid // SSR behave normally except "at the beginning and End" of the code loop then almost certainly the problem is in the code...not in the circuit or SSR....

A VERY likely issue might be the location of the "Delay" wrt (With Respect To) the Pin state change.....especially if your code uses a timer based interrupt delay rather than an idle-loop delay.....Or if the code simply "toggles the state prior to/after each delay loop...." For instance:

ldi r16, 1
out  DDRA, r16     ;Set PORTA.0 = Output
out  PORTA, r16   ;Set PORTA.0 = High
;Note: The above code will cause a ~62.5nS "Low Glitch" on PORTA.0 if PINA.0 = 0 when DDRA.0 is changed because there is 1 clock cycle between setting the direction and setting PORTA.0 = High

ldi r17, 1
sts DDRA, r17      ;Set PORTA.0 = Output
ldi  r16, 1               ;
mov r1, r16           ;
sts PORTA, r1      ;Set PORTA.0 = High
;Note: The Above code will cause a 262nS "Low Glitch" on PORTA.0 if PINA.0 = 0 when the DDRA.0 is changed.....because there are 4 clock cycles between setting the direction and setting PORTA.0 = High

While it is unlikely a 62.5nS Low Glitch would give a mechanical relay time to respond, it is quite probable it would trigger a thyristor-based SSR..... Different C Libraries handle bit toggling differently....in some cases toggling a bit might take 10 to 20 AVR clock cycles.....assuming 20 clock cycles @ 16Mhz this would mean a "Glitch" of 1.25uS .... this **might** cause a mechanical relay to engage but would absolutely cause an SSR to fire....since most SSRs are AC devices (and thyristor based) this would mean at minimum an SSR would "latch on" until the next zero-crossing point....which @ 50hz could mean it was "on" for as much as 10mS....and if the load were inductive it might stay latched on for a full cycles (20mS) before the snubber actually forced turn-off.

C is a very powerful programming language, but it is not a panacea.....frequently (unless special attention to the idiosyncrasies of the target processor are accounted for) the compiled results are not as deterministic as one might hope....especially wrt tight timing loops involving pin toggling.

Good Luck!

Fish

 

[BodhiSci]

Harald and Fish4Fun,

Thank you so much for your responses. I want to apologize for my delay. I was under pressure at the time. There was indeed some serial I/O issues with the Uno as well as the pin being used was the pin associated with an LED that that lit up when Uploading a sketch. So would flash the LED and that high state flash triggered the SSR. Since "ending" a sketch was really uploading again, it flashed and repeatedly triggered the SSR again. I believe the intermediate things, when they happened were due to the I/O issues.