On Sat, Feb 18, 2023 at 11:48 PM Tomek CEDRO <to...@cedro.info> wrote:
> Hello world :-) > > I am working on a pretty industrial automation project right now that > will control 3 phase motor over 400V/25A relays. > > There are 6 relays to provide all possible modes of 3 phase motor > control. There are 3 groups of two relays for a task like direction > change, star-left-star-right, and star-triangle switch. Each two of > the relays in the group will have exclusive control (i.e. when one is > on the other will have control cut off). But there groups are not > fully exclusive physically due to their function. So when all three > groups are turned on then big bang happens :-) > > I am still wondering how to protect against this big bang. For sure I > will add some physical protection so this situation is impossible > (i.e. some sort of logic between GPIO and relays where only one line > will indicate possible safe operation state of all relays, while zero > or more than one line set high will always result in a safe state). > > This lead me to think of the initial state of the ESP32 GPIO pins > after boot then after NuttX starts.. or when device will be in > bootloader / flashing state.. in case of malfunction.. or malicious > actions (it might be connected to the internet somehow).. or simply > sending 0xFFFF to /dev/gpio0 etc etc? > > My question is: it is possible to be sure of the GPIO pin state since > power-on through bootloader + RTOS up to the application run? For > instance not to let all pins go high/low/random? > > Any hints welcome :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > Rather than use the default GPIO driver, I would probably consider a custom driver that doesn't present to applications as individual GPIO pins, but rather as higher level constructs (motor off, star-left, star-right, etc), with mappings to specific GPIO pins in board.h. That custom driver would initialize the actual pins to the safe state (motor off) on boot, would return the pins to that state when the driver is closed, and would produce only allowed combinations of GPIO outputs. In addition, never trust software when it could cause real-world big bangs! Since industrial controls must be connected to a safety controller (emergency stop or "E Stop"), that can put the entire machine or line in a safe state, I would design logic on the circuit board that E-stops the system if: (1) any forbidden combination of GPIOs is ever output, or (2) a hardware watchdog that ensures the software hasn't frozen. Cheers Nathan
