Exceptions using GPIO Pin 3 on RasPI4

[jimcarreer]

What were you doing?

Using GPIO (Pin 3) on octoprint both for control and sensing. Note: I have already resolved permissions issues related to /dev/gpio* and I have reviewed #188 and it does not appear to be applicable or OctoPi / this plugin has shifted so that the advice given does not seem applicable for my current situation.

Settings:

Changing the sensing produces the following error:

2021-10-03 19:35:41,859 - octoprint.plugins.psucontrol - ERROR - Exception while setting up GPIO pin 3
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.8/site-packages/periphery/gpio.py", line 592, in _reopen
    fcntl.ioctl(self._chip_fd, CdevGPIO._GPIO_GET_LINEHANDLE_IOCTL, request)
OSError: [Errno 16] Device or resource busy

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.8/site-packages/octoprint_psucontrol/__init__.py", line 216, in configure_gpio
    pin = periphery.CdevGPIO(path=self.config['GPIODevice'], line=self.config['senseGPIOPin'], direction='in', bias=bias)
  File "/home/pi/oprint/lib/python3.8/site-packages/periphery/gpio.py", line 496, in __init__
    self._open(path, line, direction, edge, bias, drive, inverted, label)
  File "/home/pi/oprint/lib/python3.8/site-packages/periphery/gpio.py", line 547, in _open
    self._reopen(direction, edge, bias, drive, inverted)
  File "/home/pi/oprint/lib/python3.8/site-packages/periphery/gpio.py", line 594, in _reopen
    raise GPIOError(e.errno, "Opening input line handle: " + e.strerror)
periphery.gpio.GPIOError: [Errno 16] Opening input line handle: Device or resource busy
2021-10-03 19:35:45,837 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...
2021-10-03 19:35:45,837 - octoprint.plugins.psucontrol - ERROR - Exception while reading GPIO line
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.8/site-packages/octoprint_psucontrol/__init__.py", line 253, in _check_psu_state
    r = self._configuredGPIOPins['sense'].read()
KeyError: 'sense'

What did you expect to happen?

No exception occurs, power can be switched off using pin 3.

What happened instead?

The exception occurs and power cannot be turned on or off with the plugin.

Version of OctoPrint-PSUControl

1.0.6

Operating System running OctoPrint

OctoPi : Version 1.0.0, running on Raspberry Pi 4 Model B Rev 1.4 OctoPrint : 1.6.1

Link to octoprint.log with octoprnt.plugins.psucontrol set to DEBUG

https://gist.github.com/jimcarreer/97510a83f68a1f917d406c9b9ae079b0

[kantlivelong]

Result of gpioinfo gpiochip0?

[jimcarreer]

pi@octopi:/home/ubuntu$ gpioinfo gpiochip0
gpiochip0 - 58 lines:
    line   0:     "ID_SDA"       unused   input  active-high 
    line   1:     "ID_SCL"       unused   input  active-high 
    line   2:       "SDA1"       unused   input  active-high 
    line   3:       "SCL1"  "periphery"  output  active-high [used]
    line   4:  "GPIO_GCLK"       unused   input  active-high 
    line   5:      "GPIO5"       unused   input  active-high 
    line   6:      "GPIO6"       unused   input  active-high 
    line   7:  "SPI_CE1_N"   "spi0 CS1"  output   active-low [used]
    line   8:  "SPI_CE0_N"   "spi0 CS0"  output   active-low [used]
    line   9:   "SPI_MISO"       unused   input  active-high 
    line  10:   "SPI_MOSI"       unused   input  active-high 
    line  11:   "SPI_SCLK"       unused   input  active-high 
    line  12:     "GPIO12"       unused   input  active-high 
    line  13:     "GPIO13"       unused   input  active-high 
    line  14:       "TXD1"       unused   input  active-high 
    line  15:       "RXD1"       unused   input  active-high 
    line  16:     "GPIO16"       unused   input  active-high 
    line  17:     "GPIO17"       unused   input  active-high 
    line  18:     "GPIO18"       unused   input  active-high 
    line  19:     "GPIO19"       unused   input  active-high 
    line  20:     "GPIO20"       unused   input  active-high 
    line  21:     "GPIO21"       unused   input  active-high 
    line  22:     "GPIO22"       unused   input  active-high 
    line  23:     "GPIO23"       unused   input  active-high 
    line  24:     "GPIO24"       unused   input  active-high 
    line  25:     "GPIO25"       unused   input  active-high 
    line  26:     "GPIO26"       unused   input  active-high 
    line  27:     "GPIO27"       unused   input  active-high 
    line  28: "RGMII_MDIO"       unused   input  active-high 
    line  29:  "RGMIO_MDC"       unused   input  active-high 
    line  30:       "CTS0"       unused   input  active-high 
    line  31:       "RTS0"       unused   input  active-high 
    line  32:       "TXD0"       unused   input  active-high 
    line  33:       "RXD0"       unused   input  active-high 
    line  34:    "SD1_CLK"       unused   input  active-high 
    line  35:    "SD1_CMD"       unused   input  active-high 
    line  36:  "SD1_DATA0"       unused   input  active-high 
    line  37:  "SD1_DATA1"       unused   input  active-high 
    line  38:  "SD1_DATA2"       unused   input  active-high 
    line  39:  "SD1_DATA3"       unused   input  active-high 
    line  40:  "PWM0_MISO"       unused   input  active-high 
    line  41:  "PWM1_MOSI"       unused   input  active-high 
    line  42: "STATUS_LED_G_CLK" "led0" output active-high [used]
    line  43: "SPIFLASH_CE_N" unused input active-high 
    line  44:       "SDA0"       unused   input  active-high 
    line  45:       "SCL0"       unused   input  active-high 
    line  46: "RGMII_RXCLK" unused input active-high 
    line  47: "RGMII_RXCTL" unused input active-high 
    line  48: "RGMII_RXD0"       unused   input  active-high 
    line  49: "RGMII_RXD1"       unused   input  active-high 
    line  50: "RGMII_RXD2"       unused   input  active-high 
    line  51: "RGMII_RXD3"       unused   input  active-high 
    line  52: "RGMII_TXCLK" unused input active-high 
    line  53: "RGMII_TXCTL" unused input active-high 
    line  54: "RGMII_TXD0"       unused   input  active-high 
    line  55: "RGMII_TXD1"       unused   input  active-high 
    line  56: "RGMII_TXD2"       unused   input  active-high 
    line  57: "RGMII_TXD3"       unused   input  active-high 

[kantlivelong]

Just wanted to check. Seems like #182 applies here.

[jimcarreer]

@kantlivelong Seems like it, so I did switch to internal sensing but the problem I have there is it seems the power state gets out of sync and then gets stuck in the opposite state, I can switch back and forth but obviously using this for powering off on idle times won't work, do you have any tips for this ?

[kantlivelong]

Internal is just a baseline lazy bit flipper. The right way would be to config sensing on another GPIO pin to the expected DC voltage(using a opto isolator, ~resistor~ voltage divider, etc).

[jimcarreer]

I've got it synced now so the state matches, as for

The right way would be to config sensing on another GPIO pin to the expected DC voltage(using a opto isolator, resistor devider, etc).

I'm afraid this is outside my current understanding, do you happen to know some place I could do some further reading on how to set this up? Or even some google keywords to get me over Mount Ignorance.

[kantlivelong]

I personally just use a voltage divider to convert 12V (or 24V) to 3.3V. https://www.youtube.com/watch?v=fmSC0NoaG_I seems like a decent explanation.

[jimcarreer]

Ah so there's some confusion here: I've actually got the pi wired up to a relay that's just switching mains power on and off. By that I mean there is no DC voltage to step down, I'm just switching the mains power to the printers power supply externally and I'm not wired into either the power supply nor the main board of the printer (and don't want to mess with doing this). Could I just jump the GPIO pin I'm using as the control to another GPIO on the pi?

[kantlivelong]

Even with switching mains you would wire sense to the DC voltage provided by the supply. You can just jump the GPIO pins too but that really doesn't verify that power is truely on.

Say mains was switched on but isn't actually plugged into the wall. The plugin would say power is on but it clearly wouldn't be.

Either way "works" but verifying the expected voltage is provided is better.

[jimcarreer]

Ah yeah that's a good point. And honestly now that you point it out, doing the jumper isn't much better than using the 'software' (aka dumb flag aka 'internal') level detection. I'm not really interested with cracking open and wiring up detection on the supply, in fact I was very directly avoiding it which is what I meant when I said:

I'm not wired into either the power supply nor the main board of the printer (and don't want to mess with doing this).

Ill just live with the software level tracking it hasn't caused me any issues the way I have things configured so far.

[jimcarreer]

Going to just close this out, I've got everything working and even if this is a "legit issue" to discuss here, it seems like its basically a duplicate of #182

[kantlivelong]

Jumping would at least prevent out of sync problems that "Internal" can run into. That's about the only benefit over the other I can think of.