Request for rpi-gpio out functional modification to maintain IO state when deploying

General
1

I'm using the rpi-gpio out node to control the status of a relay that control the power to some component. Unfortunately whenever I modify the controlling parameters in my code, and hit deploy, the default behaviour of the node it to always bring the PIN low, regardless of it's current state, then evaluate the controlling code and if the result leads to HIGH, then bring the IO pin high again right away.

This is bad because depending of what you are powering on and off, a rapid switch off and on again, could lead to surges and damage downstream components.

At present I have introduced a delay, but I feel the right behaviour would be to maintain the PIN in it's current state, evaluate the code when deployed, and only then bring the PIN to the opposite of it's current state, if the code/parameter changes lead to that.

Hope I'm clear.

Michael

2

You could trying adjusting what the deploy button does and only deploy modified nodes

image

That might prevent the effect your seeing

3

Thank you for the advice, I'll test; I still think the requested behaviour is the most logical.

Michael

4

I am on my phone, so can't check, but I thought there was a checkbox in the node to define the initial output.

5

Yes, there is indeed an "initialise pin state" so you can check that, and say if the pin should be initialised on or off, but I wan't it to remain the same as it is, and when I remove initialise pin state, it still turns off when it's on when you hit deploy.

Michael

6

I am not certain, but I suspect that when a redeploy happens that consists of two operations. First the node is stopped and therefore must disconnect from the pin. That will cause the pin to go to is quiescent state. Then the node is started again and will reconnect. The previous state of the pin is therefore lost.

7

Correct - if the node is stopped then we call the library GPIO.cleanup() - line 168 of nrgpio.py. as that is recommended practise.
a) you may of course comment out / delete this and see how it behaves for you.
b) when we do stop and restart the runtime (a full deploy) - then once we close the node - then we are no longer in control of the pin and as Colin mentioned it will be back under the control of the operating system and the default state may or may not be what you want. (even if that is for a very short time).
c) once we start up again - unless you have stored that old state somewhere (eg persistent context) and then re-loaded that - then we have no way of knowing what state it was in as we are starting clean...

8

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