USB Power Control via OctoPrint


#21

You say that it works when you execute the script from SSH. What user do you use when run the script? You have to make sure that "pi" user has access to where you saved your script, and hs permission to run it.


#22

Smoke this thread down to the filter and you might figure out how to get a system command to run a script which needs root access to something like a GPIO pin.


#23

I'm using a similar solution to switch off my printer's board powered by a Raspberry Pi. It's based on this USB power control code :

config.yaml

system:
  actions:
  - action: printer_usb_on
    command: sudo uhubctl -a 1 -p 2 -l 1-1
    confirm: You are activating printer USB port.
    name: Printer USB ON
  - action: printer_usb_off
    command: sudo uhubctl -a 0 -p 2 -l 1-1
    confirm: You are deactivating printer USB port.
    name: Printer USB OFF
  - action: usb_hub_on
    command: sudo uhubctl -a 1 -p 3 -l 1-1
    confirm: You are activating USB hub.
    name: USB HUB ON
  - action: usb_hub_off
    command: sudo uhubctl -a 0 -p 3 -l 1-1
    confirm: You are deactivating USB hub.
    name: USB HUB OFF

/etc/sudoers.d/octoprint-uhubctl

pi ALL=NOPASSWD: /usr/sbin/uhubctl

I'm also using a 220 V mechanical relay for the power supply. It's switched on and off by the printer's board with G-Code instead of the Raspberry Pi. It's particularly handy when prints are finished.


#24

I faced the same issue with power backfeeding from the raspberry pi to the control board of my CR-10S.
Finally, instead of a hardware solution I'm using hub-ctrl to switch USB power permanently off (e.g. put the invocation into crontab with @reboot).
Switching the printer on/off with the TP-Link plugin works like a charm and octoprint automatically connects to the printer when powered on.

I'm using a Pi 2B and switch all USB ports off (no other devices connected except the printer) but this should also work for single ports, maybe depends on the Pi model.

So if it's only about the back feeding (LCD stays lit and board running), I'm wondering why one would need to switch USB power together with the printer...


#25

I'm linking this over on one of the more popular threads where people are suffering undervoltage. Good idea.


#26

To be honest I figured this out just that day and was somehow concerned now that I made this statement without real testing.
So I just checked and can confirm it works.

Being at work, I tested remotely using the TP-Link app to switch the smart plug and CURLed the REST API of Octoprint via ssh.

TP-Link OFF:

GET /api/printer (checking the printer status)
HTTP/1.1 409 CONFLICT
Printer is not operational

TP-Link ON:

POST /api/connection (connecting to printer)
GET /api/printer (checking the printer status)
"state": {
...
"operational": true,
...
"ready": true,
},
"text": "Operational"
},
"temperature": {
"bed": {
"actual": 16.6,
...
}

You can also use hub-ctrl to switch on/off USB power while Octoprint is connected to the printer. It will not break the connection.


#27

That's amazing. Who'd have thought that toggling the USB would be just toggling the 5V power (only)?


#28

Switching USB Power is what the author actually promises on the hub-ctrl github. :smile:


#29

@kb-1 and everyone:

I've been playing with this and will continue to research the topic of removing the 5V line from USB ports.

5V power versus discovery

If the 5V line is turned off before the printer is plugged in via its USB connection, the /dev/ttyAMA0 device will be seen in the devices folder itself but is not immediately seen in the OctoPrint Connection side panel. Pressing the refresh button will bring it up and it does work by pressing the Connect button with the AUTO serial port selection.

40%20AM

38%20AM

Port ordering

Technically on the Raspberry Pi 3B, the first port is the microUSB connector we normally think of as the power connection. The next four ports by ordinal are 2 through 5.

I've not been able to get a clear sense of which USB port would be connected behind-the-scenes to the port ordinal (2 through 5) on the bus.

It's likely that port numbers 2 through 5 are issued at bootup by idVendor/idProduct number rather than by physical location in the four-port collection of connectors.

Power-only devices without IDs

Powered devices (LEDs, fans) which do not respond with an idVendor/idProduct are ALL lumped together and may not be individually turned ON/OFF via this program. The only way to toggle them is as a group and via PORT 2. This should then also have a side effect of toggling the main printer's serial port as well though in most cases.

Communication Error

Having connected and then toggled off the power to this port, I now see this after a few minutes of doing nothing:

37%20AM

And now trying to reconnect, I see this:

24%20AM

Toggling the USB port on again, it will now immediately connect. I then toggle the USB port back off and start a print job.

And now again, I see a Communication Error as before.

Summary

I'm not yet convinced that this is a workable solution for preventing the Raspberry Pi from sinking power over to the controller board and yet have everything work out.


#30

@OutsourcedGuru, was your research also related to the "USB power permanently off" approach using hub-ctrl?
I just checked again (REST) and could not see a connection loss during one hour of idling. Also no problems during some hours of printing.
I was actually thinking about upgrading the Pi 2B I use for octoprint to a 3B or 3B+, but if these models behave differently regarding that USB power switching, I would rather stay with the 2B.

Or maybe the behavior depends not (or not only) on the Pi model but also on the USB-Serial chip used on the controller board?

That's what my CR-10S shows up as:

Bus 001 Device 007: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

T:  Bus=01 Lev=02 Prnt=02 Port=04 Cnt=02 Dev#=  7 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0403 ProdID=6001 Rev=06.00
S:  Manufacturer=FTDI
S:  Product=FT232R USB UART
S:  SerialNumber=A107FR7L

#31

Now that you ask, my research was related to the development of this new plugin which I've just created. Jump to the repository and scroll down to the Complications section to read the anecdotal case in question. My rig is using a Robo controller board which is based on the Mega 2560 to the best of my knowledge. I can snag you the USB particulars for that board if you'd like.

You might make a good candidate for testing the plugin since you've had success in this area.


#32

I will give it a try as soon as I have some time.