Hello
is there a way, within node-red, to ensure that there is an interlock between gpios such that two pins can never be high at the same time (this is for an H-bridge; so two high pins = magic smoke).
thank you
Justin
If it is a possible smoke situation then don't do it in software. You need a hardware solution.
2 Likes
In all my other hBridge installations I've used software apart from one where the modules had logic gates to "ensure" interlock. It blew up, not because the software was wrong but because the logic was wrong.
I'm happy to use hardware but I want my software implementation to be compliant too.
So my question stands. Any advice on how to achieve this in nodered or node?
Are you using Node-red to set the GPIOs?
It's clearly possible to code it to set pin A low before setting pin B high
For example a trigger node to send false, wait 250ms then send true. Send message 2 to a separate output lets you easily direct the two messages to different pins.
1 Like
But. .., again it depends on hardware. While the system is booting and Node-RED has not yet started the gpio pins may be in an unpredictable state .
Thanks
I think relying on delay is an idea but not foolproof. It looks like I'll have to code it in a function node or roll my own package.
I wasn't aware that the state of the rPi pins is arbitrary on system boot. That's worrying and worth researching.
On pi I think they “should” default to inputs, though some pins are also used for dual purpose (like SPI, I2C, etc). What that means for output level you will have to check.
They default to inputs. If you want to guarantee that they are low on startup then connect external pulldown resistors to them so that when the pin is an input it will be held low by the pulldown.
Are the three other states valid (00 01 and 10) valid?
What are the possible input states that determine the possible states of the two pins?
The truth table for hbridges usually allows 00,01,10 on the direction selectors. It's 11 that becomes problematic, if you think about it.
I'm hunting for the schematic of the module I'm using (a 30A generic variant) to see what protections it has. But am going to go with writing my own handlers not least as I've also seen that there is no control over the frequency of the pwm signal in the standard node for gpio control, only the duty cycle (which confusingly seems to be labelled Hz, although I've not dug into the source code of those packages).
What has PWM got to do with it? This is the first time you have mentioned that.
Take care that you know which way up is which on the outputs. If I remember correctly they are active low, which means that a 1 output to a pin drives it low. Also note that they are only 3.3V outputs and you must not connect to a signal that may float to 5V, for example.
many H-Bridges for motors drive one of the gates with pwm to create speed control.
If you set the GPIO as PWM how do you make it go to the Off state when required?
I know I might be a little late to this gathering, and apologies if its moved on since.
But I seen the word "lock", and my own node sprung to mind.
Place any GPIO ON command BEFORE a semaphore take
Place a semaphore release AFTER any GPIO OFF command (ONLY)
I know @Colin & @dceejay also created something similar using Core Nodes?
Wouldn't something like these work?
Disclaimer: I am not an electrician, and cant be held accountable for magic smoke 
yes - quite possibly that would work. Thank you.
currently I am waiting for the GPIO to read low before asserting high on its counterpart GPIO
most h-bridge modules have two input pins to set direction (corresponding to setting the top left and bottom right FETS to On or vice versa). the danger is when both input pins are set high. speed is done through an EN pin which is pulsed. I've not looked at the functional block diagram for the controller chip to know which of the gates are actually being pulsed. but to avoid a reversing-torque issue for motors typically you'd set the PWM to zero, wait a bit then swap the IN pins.
In my case, I'm using the driver for an electrode and would need to prevent rapid switching of "direction" to avoid a situation where the electrode plates are charged (like a capacitor) and would suddenly be attempting to be charged in reverse.
You can't read a GPIO pin that is configured as an output.
And they really do not have built in interlocks to prevent smoke? I am amazed if that is correct. It would be a trivial bit of extra logic in the circuit.
some of the modules that I have used have logic gates to create an interlock. These have blown up even when I'm careful and with minimal current. I've stopped trusting hardware modules that I've not created myself and now use belt and braces. Normally I'd use esp32 or atmega chips to manage this but since i have to use a pi for the larger project i am trying to do all the functionality on the same board.
re the assertion that you cannot read a pin designated as an output, I find that an astonishing limitation; but I'm really not used to this hardware platform.
That is a feature of the hardware of the pi. It is not a problem in node-red because you can easily know the value you last wrote to it.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
