# Interlocks on node-red (raspberry pi bookworm)

**URL:** <https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037>\
**Category:** General\
**Created:** [28 June 2024 10:55 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037 "2024-06-28T10:55:57Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![jpadie](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jpadie/32/87036_2.png) [@jpadie](https://discourse.nodered.org/u/jpadie)\
**Post date:** [28 June 2024 10:55 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/1 "2024-06-28T10:55:57Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [28 June 2024 11:22 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/2 "2024-06-28T11:22:31Z")

</div>

If it is a possible smoke situation then don't do it in software. You need a hardware solution.

---

<div class="post-metadata">

**Author:** ![jpadie](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jpadie/32/87036_2.png) [@jpadie](https://discourse.nodered.org/u/jpadie)\
**Post date:** [28 June 2024 11:50 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/3 "2024-06-28T11:50:27Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![jbudd](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jbudd](https://discourse.nodered.org/u/jbudd)\
**Post date:** [28 June 2024 12:11 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/4 "2024-06-28T12:11:39Z")

</div>

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.

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/4/8/4825f213f5cf1af41b461209bd2823a96914c464.png)  
 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/6/5/657df6d107bf396875f4005a49feb9c1aa15a497.png)

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [28 June 2024 12:37 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/5 "2024-06-28T12:37:50Z")

</div>

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 .

---

<div class="post-metadata">

**Author:** ![jpadie](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jpadie/32/87036_2.png) [@jpadie](https://discourse.nodered.org/u/jpadie)\
**Post date:** [28 June 2024 13:02 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/6 "2024-06-28T13:02:53Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [28 June 2024 13:05 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/7 "2024-06-28T13:05:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [28 June 2024 14:35 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/8 "2024-06-28T14:35:28Z")

</div>

> [@jpadie](#):
>
> I wasn't aware that the state of the rPi pins is arbitrary on system boot.

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?

---

<div class="post-metadata">

**Author:** ![jpadie](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jpadie/32/87036_2.png) [@jpadie](https://discourse.nodered.org/u/jpadie)\
**Post date:** [28 June 2024 15:26 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/9 "2024-06-28T15:26:35Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [28 June 2024 15:37 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/10 "2024-06-28T15:37:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jpadie](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jpadie/32/87036_2.png) [@jpadie](https://discourse.nodered.org/u/jpadie)\
**Post date:** [30 June 2024 11:14 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/11 "2024-06-30T11:14:59Z")

</div>

many H-Bridges for motors drive one of the gates with pwm to create speed control.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [30 June 2024 11:28 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/12 "2024-06-30T11:28:46Z")

</div>

If you set the GPIO as PWM how do you make it go to the Off state when required?

---

<div class="post-metadata">

**Author:** ![marcus-j-davies](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/marcus-j-davies/32/103435_2.png) [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)\
**Post date:** [30 June 2024 11:51 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/13 "2024-06-30T11:51:46Z")

</div>

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)

![Jun-30-2024 12-41-36](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/e/3/e3dff24d6ee45f20dfae81c7a9d676c31c900a83.gif)

> **[@marcus-j-davies/node-red-semaphore-plus](https://flows.nodered.org/node/@marcus-j-davies/node-red-semaphore-plus)**
>
> An advanced set of semaphore Nodes for Node RED, with a dynamic fail-safe

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 😃

---

<div class="post-metadata">

**Author:** ![jpadie](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jpadie/32/87036_2.png) [@jpadie](https://discourse.nodered.org/u/jpadie)\
**Post date:** [30 June 2024 12:14 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/14 "2024-06-30T12:14:19Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jpadie](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jpadie/32/87036_2.png) [@jpadie](https://discourse.nodered.org/u/jpadie)\
**Post date:** [30 June 2024 12:19 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/15 "2024-06-30T12:19:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [30 June 2024 12:28 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/16 "2024-06-30T12:28:54Z")

</div>

> [@jpadie](#):
>
> currently I am waiting for the GPIO to read low before asserting high on its counterpart GPIO

You can't read a GPIO pin that is configured as an output.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [30 June 2024 12:33 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/17 "2024-06-30T12:33:06Z")

</div>

> [@jpadie](#):
>
> 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).

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.

---

<div class="post-metadata">

**Author:** ![jpadie](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jpadie/32/87036_2.png) [@jpadie](https://discourse.nodered.org/u/jpadie)\
**Post date:** [30 June 2024 12:43 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/18 "2024-06-30T12:43:03Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [30 June 2024 12:56 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/19 "2024-06-30T12:56:49Z")

</div>

> [@jpadie](#):
>
> you cannot read a pin designated as an output, I find that an astonishing limitation;

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.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [28 September 2024 12:57 UTC](https://discourse.nodered.org/t/interlocks-on-node-red-raspberry-pi-bookworm/89037/20 "2024-09-28T12:57:00Z")

</div>

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.