Shutters on arduino and SSR not working correctly (partially)

Hi,

I'm trying to make a windows shutters controller (I have 12 shutters to control).
The idea is to have one module with 24 relays connected via shift registers to Arduino micro. The module should be connected to CAN bus and receive commands to open/close specified shutters. The shutters are standard motors with one common output, one for moving up, and on for moving down.

After assembling and connecting the device, I noted that around half of the shutters are not working (either not moving at all or moving with a lot of shutter...). What I did to isolate the problem is:

  • try to connect one working shutter to every socket in the device - it was working correctly on all of them
  • try to connect not working shutter to every socket in the device - it was not working on all of them
  • connect not working shutter directly to power supply - it was working correctly

Here is the partial schematic of the device (I isolated the part that IMO is most likely to cause problems):

From the code perspective, I'm just sending to the shift registers the bytes of the relays that should be turned on/off. Here is the interesting part:

void setup()
{
    pinMode(SHIFT_REGISTER_LATCH, OUTPUT);
    pinMode(SHIFT_REGISTER_DATA, OUTPUT);
    pinMode(SHIFT_REGISTER_CLOCK, OUTPUT);
}

void loop()
{
    uint32_t driverOutputs = 0xFFFFFF;
    // calculating the correct state - this looks to be working correctly...

    digitalWrite(SHIFT_REGISTER_LATCH, LOW);
    // I have 3 shift registers
    shiftOut(SHIFT_REGISTER_DATA, SHIFT_REGISTER_CLOCK, LSBFIRST, (driverOutputs >> 0) & 0xFF);
    shiftOut(SHIFT_REGISTER_DATA, SHIFT_REGISTER_CLOCK, LSBFIRST, (driverOutputs >> 8) & 0xFF);
    shiftOut(SHIFT_REGISTER_DATA, SHIFT_REGISTER_CLOCK, LSBFIRST, (driverOutputs >> 16) & 0xFF);
    digitalWrite(SHIFT_REGISTER_LATCH, HIGH);
}

Any idea what can be wrong here? Or what should I test/measure to check what is wrong?

I'm posing the full diagram as well:

Thanks a lot for any help.

First thing I notice, you have an LED in series with the SSR input. They are not designed to handle that... The
G3MB-202PL-DC5 has a resistor build in to be connected to 5V, not 2-3V (depending on the LED). So they might struggle here.

And two questions, why use the PL version instead of the P?
And are the motors fine if both up and down are turned on? Because this setup has no protection build in so fully depends on software for that. And I'm not sure if the output state of the 595 is guaranteed if powered on.

Thanks for the fast response :slight_smile:
So:
PL vs P versions - just checked, I made a mistake, I have P version, but I have a question - does it actually matters in this case?

LES - it is there just to be able to check what's going on, but you're right, it should not be put on the relay (would be probably better to put it in parallel with it's own resistor. I'll check it tomorrow.

Output of 595 - right now I'm putting power on only after program is fully initialized, so it's not a problem for now, but I known that I will need to fix this issue. By the way, is there any good/standard solution for that? I saw some diagram with the standard relay that was working because the relay has two outputs with one of them on by default (you're connecting the second relay through the default output of the first one), but what can I do when I have SSR with only one output?

So, from what I guess, the LED is for now the only suspect here for this problem... If it appears to be true, is there any logical explanation why one shutter is working and the other is not on the same rellays while both of them works without rellays?

mlewando:
PL vs P versions - just checked, I made a mistake, I have P version, but I have a question - does it actually matters in this case?

You don’t need the phase-cut capability of the P, so having zero cross detection will introduce less noise.

mlewando:
LES - it is there just to be able to check what’s going on, but you’re right, it should not be put on the relay (would be probably better to put it in parallel with it’s own resistor. I’ll check it tomorrow.

I get the purpose but putting them in parallel would be the way to go. Really underdriving them may be the cause for them to not fire.

mlewando:
By the way, is there any good/standard solution for that?

Try to figure out if the HC595 has a fixed power on state. I could not find it when I did a quick look. But be sure to wire everything so that this known state is the OFF.

mlewando:
is there any logical explanation why one shutter is working and the other is not on the same rellays while both of them works without rellays?

Slightly different triac, slightly different motor current. If you’re driving them borderline the smallest variation may cause them to not work (reliable).

Also not, that driving all SSR’s will probably stress the HC595 beyond it’s limits. The SSR datasheet unfortunately doesn’t state it explicitly but the current seems to be around 10mA per SSR. 8 x 10mA = 80mA which is >70mA of the absolute maximum rating of “Continuous current through VCC or GND”.

And I have no idea if the build-in snubber network is sufficient for your motors. ::slight_smile:

Ok, without LEDs it worked like a charm :slight_smile:
Thanks a lot for help and explanation :slight_smile:

There is possibility to set all outputs of HC595 on HIGH/LOW with OE/SRCLR pins, I'll find out the correct setting for this. But I would also like to find out the way to be sure to not turn both rellays on even by program error...

About the current, I should never turn on all 8 outputs, Max is 4 (for 4 shutters), so I should have Max 40mA and that should be ok from what I know. But thanks for pointing this out :slight_smile:

I don't actually have any snubber network for the motors... And the one that I have for the rest of the module is taken from examples in the Internet. I'd need to educate myself how to calculate it correctly.
I found some example here: https://www.hackster.io/gomecin/blinds-or-any-ac-power-motor-control-27f633 but I'd like to really understand it before applying one. And of course thanks for that note too:)

Btw. Do you have any more comments/advices for this module?

Ah, yeah, with OE I wanted to include (but forgot ::slight_smile: ). That should also fix the overload problem.

Uhm, couple things. Be sure to separate mains and low voltage nicely on the PCB. Adding slots can help.

And because every two SSR's control a single shutter, I would just use a single fuse per shutter :slight_smile:

As for the "not both on", can be done in software if you careful write functions etc around it and only use those. So make a clear interface to 'driverOutputs' instead of writing to that variable from anywhere in code.

Sorry for long silence form my side and thanks for help, but I'd like to ask for one more advice...

I'm still thinking how to have some hardware secure version of "not both on". I was experimenting with some transistors for this and my current idea is it connect base of one PNP an one NPN transistor to one input of the shift register and then connect each transistor to one relay. Then use the second output of the shift register to turn the pair of relays ON/OFF (also through the transistor, just for safety of the shift register). It looks like this:

In general - it works :slight_smile: but there is a slight "but" :frowning:

I noticed, that when I disconnect the two bases from the shift register (so they stay connected together, but not either GND not VCC), both relays/leds are on... And I failed to figure out why is that :frowning: Is there any option that you could explain me this behavior (as google failed in this case)? Or maybe just evaluate is this is the good approach?

As for the OE - here also I noted one strange behavior - not matter how I connect two leds (just for tests) to the shift register, when I'm doing random power on, power offs for the whole device, I can sometimes notice that LEDs are blinking once at the startup (sometimes one of them, sometimes both). It does not matter if I connect OE to the ground of VCC. This is something that I probably still need to investigate deeper.

As of PCB - mains will be as far as possible from low voltage and will be separated by slots as much as possible :wink:
I'll upload here the final schematic, PCB and probably push code to github after this will be done and working :slight_smile:

A quick question that pops into mind: does it hurt (both electrical and functional) if one of the two SSR is always on?

Mm, start up behavior isn't that specified indeed. But I would have thought that is !OE is pulled low on power up the outputs should just float.

The whole design with transistors looks a bit over complicated for the task, especially if you want that 8x. An easier way I can think of, simply place the SSR's in anti-parallel connected to two outputs. That way they are both off if both output are low, one turns on when the outputs are HIGH-LOW and the other when the outputs are LOW-HIGH. Indicator LED's can also be placed anti parallel with a single resistor.

PS Modern leds are pretty bright, and with 470R on red leds's you are getting close to the limits of the HC595, so I would go for at least 1k :slight_smile:

Yes... The transistors idea is definitely complicated and not 100% working (tough it solves the HC595 current limit).
With anti-parallel connection of relays: this will basically mean that I will draw current from two outputs of HC595. In fact this will basically be the same current as in original design, but shouldn't it be then calculated twice? If yes, then I'm outside of the HC595 limit...

About LEDs - I need them just for visual debugging, so I'll put them the maximum resistor that will light them up just a little bit.

No, you don't count it twice. Because the overall limit comes from the limits of Vcc and GND. And if you drive the SSR from two pins, one is HIGH aka sourcing from Vcc while the other is LOW aka sinking to GND :slight_smile: So now both Vcc and GND see a load but both only once.

About the leds, that's what I thought. Once made a small board with a red indicator led and used like 470Ω at first but it was so damn bright :smiley: Swapped it for 1k but I could easily use 1k5 and it would still be visible in daylight :stuck_out_tongue: