2

I'm going to drive a bunch of 230VAC motorized ball valves from an ESP32.

I'll have several boards, each with 8 triacs driven by MOC3052 opto-triacs. This will be connected to another board with an ESP32 with short ribbon cables.

There isn't enough IO to drive all the MOC's, so I'll be using PCA9554B I2C IO expanders. I chose these because they have a 200mA maximum total sink current, which suits 8 optos driven at 10mA each.

I have two options available:

  1. I2C IO-Expander on ESP32 board, and route the outputs through the ribbon cable to the triac board.

This would be the most robust solution. Since the triacs will be on/off and not phase-cut dimming, I could add filter caps on the control lines.

  1. I2C IO-Expander on the triac board, and route I2C through the ribbon cable.

This would be more flexible, as I could add more triac boards along the I2C cable. However, I2C isn't famous for being robust against EMI, and this thing is going to sit in an enclosure with lots of mains wiring, and all the loads are inductive.

The motorized ball valves have limit switches which are quite bouncy, so they emit a burst of EMI when the switch opens. That caused problems with the first version of the board. I've added snubbers and that worked very well though.

I'm leaning towards option 1. Thoughts?

DamienD
  • 3,093
  • 1
  • 14
  • 23
bobflux
  • 70,433
  • 3
  • 83
  • 203
  • If you choose Option 2, then consider looking at the specs for [SMBus](https://en.wikipedia.org/wiki/System_Management_Bus), which mostly is I2C routed over short interconnects between boards. – Solomon Slow Dec 12 '21 at 20:55
  • @SolomonSlow SMBus has a timeout feature, so if a chip has a problem it will reset itself and the bus won't get stuck, it also has checksums, it is much more robust... – bobflux Dec 12 '21 at 21:05
  • 1
    Is it possible to use differential I2C? That would be much more noise immune. – jfowkes Dec 12 '21 at 21:56
  • @jfowkes There's a [chip](https://www.farnell.com/datasheets/2340284.pdf) for that but it's unobtainium. Besides, it's a lot more expensive than using flat cables with more wires... – bobflux Dec 12 '21 at 22:14
  • 2
    Depends how important no accidental/missed ons/offs are. If it's not, could use PCA9554 with an I2C overwrite pass every, say, 100 ms so mistakes are short lived. If it's critical, could use a readily-available MCU with I2C and parallel I/O (8x IOL OK?), making your own very simple message protocol with (a) a checksum in write/read messages and (b) a confirmation read message of MCU after each write message, leading to a retry message if failed. Nothing elaborate, just simple and solid. But that relies on the max. bus noise you could get being low. I've done similar, in industrial machine. – TonyM Dec 12 '21 at 22:29
  • @TonyM Rewriting the IO every 100ms would be absolutely fine. The ball valves need about a minute to open or close, so if there is a corrupt bit for 100ms, no problem. I'd be more worried about the I2C state machine getting stuck. PCA9554 datasheet says "to reset the chip, turn off power" which is... not that practical... – bobflux Dec 12 '21 at 22:31
  • @TonyM in fact, the output register of PCA9554 can be read back over I2C, so it is possible to verify the value was written correctly. – bobflux Dec 12 '21 at 22:34
  • 1
    I know as I inherited PCA9554s on remote board driving a safety-critical motor. If the cable between boards broke or was too noisy, it'd stay on forever. PCA9554 has no reset so couldn't easily add a watchdog timer, cleared by a PCA9554 pin. I changed it immediately for a single-chip MCU with a software watchdog function. Simple software and removed the problem. 80p MCU, plus of course the development, documentation, software verification/validation, production test and programming costs. – TonyM Dec 12 '21 at 22:34
  • My suggestion would be a chain of tpic6b595 or similar shift registers. Then something like a hct125, 04 or 367 for the level translation. If you want something a little cheaper, the hc595 with uln2003 or uln2803 or a handful of bjts or mosfets. – Kartman Dec 12 '21 at 22:35
  • @TonyM OK, if you got it to stay stuck due to noise, that kinda answers the question lol. – bobflux Dec 12 '21 at 22:36
  • @Kartman I had trouble with [NPIC6C595](https://electronics.stackexchange.com/questions/598721/npic6c596-resets-itself), I should receive TPIC6C595 tomorrow, hopefully the TI version will be less sensitive and less prone to self-reset... – bobflux Dec 12 '21 at 22:39
  • @bobflux, I didn't know about the checksums. I worked on a project where we used SMBus buffer chips to connect different boards together, but the actual peripherals on the boards were just standard I2C parts. I don't remember the part numbers of the buffer chips. Somebody else designed the boards. I'm just a software geek. – Solomon Slow Dec 13 '21 at 02:22
  • @Kartman I have solved the problem with NPIC6C595, so this solution now takes the lead ;) – bobflux Dec 13 '21 at 11:46

1 Answers1

2
  • With regards to I2C, read a previous answer on this topic .
  • EMI problems: it's not clear what those were in the first version. What I can see on the picture is that your Phase and Neutral lines are not tightly together, creating loops. I fixed a real issue in an electrical cabinet once where the Neutral and Phase going to a motor were on the left and the right of a differential fuse. That fuse triggered occasionnaly. For over a year electricians did all sorts of things to try to fix this (not identifying the issue with those wires, but replacing components, devices, screwing more tightly, etc).
    After that period I carefully scrutined the cabinet and found those wires and figured that the magnetic field was detected by the differential's solenoid. So I fixed it by keeping those wires close to each other. It has never failed again since (15 years now).
    Make sure that you got the reasons right for your case.
  • Regarding the "MOCs" - use "MOCs" with Zero Crossing Detection (ZCD) instead. There are "MOCs" that require only 2mA of current for the optocoupler. That will be easier on your power supply as well.

Your first solution, having only control lines + GND to the TRIAC boards seems the least expensive one as you do not need to power the boards remotely.

I would use a dedicated signal/GND for each board to avoid issues with return currents, and plan for filters - at least on the TRIAC boards - (see this question and replies for a discussion on filtering).
By "plan", I mean that I would design two incoming connectors on the TRIAC board, one connecting directly to the optocoupler's diode (with in series resistor), and the other one with an in-line filter.

The second solution, using an I2C port expander on each TRIAC board, would be more expensive, require powering the boards, but bring more flexibility. Each board would need to have it's own I2C address, making it more difficult to configure/manage in the field (what if the technician sets the same address on two different boards?!). Your I2C network could give you troubles of its own.
I would add I2C pull up resistors on each board inversely proportional to the capacitance that the interconnect could represent. So each time you add a board, the overall pull-up resistor values become smaller.
Having a pull-up resistor locally on each TRIAC board should make the local I2C signals less prone to noise (without a resistor, noise on the I2C signals adds or substract from the voltage seen at the microcontroller's terminal that is sending the data). You could plan for capacitors on the SCL and SDA lines on the TRIAC boards to allow adding local RC filters. If you use them, ensure that your total capacitance (cables included) remain within acceptable operating conditions.

le_top
  • 3,111
  • 11
  • 22