OctoPrint-USBControl

Great idea!
You could add the device name as reported by uhubctl next to the switches. Some have a recognizable name, some unfortunately not:

Current status for hub 1-1.1 [0424:2514, USB 2.00, 3 ports]
Port 1: 0503 power highspeed enable connect [0424:7800]
Port 2: 0103 power enable connect [1209:8087 MisfitTech.net Nano Zero] (closed loop stepper #1)
Port 3: 0103 power enable connect [1209:8087 MisfitTech.net Nano Zero] (closed loop stepper #2)
Current status for hub 1-1 [0424:2514, USB 2.00, 4 ports]
Port 1: 0503 power highspeed enable connect [0424:2514, USB 2.00, 3 ports]
Port 2: 0103 power enable connect [2341:0042 Arduino (www.arduino.cc) 85334333931351612251] (MEGA2560)
Port 3: 0503 power highspeed enable connect [046d:0825 13DECCE0 (a webcam)
Port 4: 0100 power

I was using uart/usart interchangeably. Didn't you say serial/USB should happen with one chip over another?

Yes, the Pi has two UARTs (one good, one cheap). In the case where you're trying to GPIO something serially, doing serial-over-console or Bluetooth it's bound to a question of "are you feeling lucky, punk?" on the two available UARTs.

I've heard some strong opinion that none of the serial-over-USB ports as seen here use either UART.

The next version will attempt to determine the state and IDs of the four ports and to present this in some way in the Settings menu. At this point, you could then offer options which stop saying "port 3" and just say "the port with the Mega 2560 on it" in some way.

I'll also do some work by plugging in an external USB hub and then see what the interface looks like. In theory, you can toggle ON/OFF those as well if it's a smart hub.

Bummer. He's got a couple of issues on his repository in which he's indicating that the 2B/3B have internal problems that prevent the ports from being toggled individually. Technically, the 3B+ can be individually toggled but there's like two internal buses or something like that.

In order for this to truly be useful, you'd need to attach an external smart USB hub and then toggle things that are attached to that. But as we've heard, external USB buses cause latency problems on the serial printer communications.

OctoPrint-USBControl v1.0.3

This version will now read the model of the Raspberry Pi and make some determinations as required to let the user know what they can and cannot do.

1 Like

@OutsourcedGuru Tried your plugin on RPI 3B+. Works as advertised, but I got one strange side-effect, which took me quite some time to link to USBControl. When plugin is enabled Feed rate and Flow rate sliders move to the top-left corner of the window. When I disable or uninstall the plugin, they return to their original place. Observed this behavior on 2 different RPIs under OctoPrint 1.3.10 running on OctoPi 0.15.1.

Thanks.

:facepalm:

That's my styling of the sliders in the Settings page that's too promiscuous. Thanks for catching that.

I tested with Klipper on RPI 3B+ and observed the following behavior:
USB2 - switches on and off LCD.
USB5 - switches on and off serial connection between OctoPrint and Klipper.

Considering this, would be nice to have some kind of grouping option and in one click be able to switch on/off pre-configured set of 2 or more ports. Also, my personal preference would prefer to have USB controls somewhere "closer" - in navbar drop-down menu, or under Control tab.

Thanks

Since I don't have a Raspi3B+ at the moment, what I could use from you is the output of sudo lsusb -t and a quick analysis from you which port you'd guess your printer and LCD are plugged into.

The author of uhubctl suggests that The Raspi3B+ has some sort of odd-yet-possibly-functional split hub thing going on.

I'll get the CSS sorted out this evening.

By the way, I've included the REST API in the instructions. Once we get your 3B+ working from the Settings screen, it should be easy enough to add custom controls which talk to the API.

I'm having a different experience with the Pi 3B+. The only odd behavior happens when I disable Port 2 on 1-1, which switches off all 4 USB ports (they're not powered anymore, without showing up as off with uhubctl). The other ports can be switched off individually (0 bold in the table; 1 means ON and functional; 0 unexpectedly OFF)

NZS1 NZS2 Arduino Webcam
1-1.1 port 2 1-1.1 port 3 1-1 Port 2 1-1 port 3
NZS1 1-1.1 port 2 0 1 1 1
NZS2 1-1.1 port 3 1 0 1 1
Arduino 1-1 Port 2 0 0 0 0
Webcam 1-1 port 3 1 1 1 0

My peripherals as reported by sudo uhubctl:

Current status for hub 1-1.1 [0424:2514, USB 2.00, 3 ports]
Port 1: 0503 power highspeed enable connect [0424:7800]
Port 2: 0103 power enable connect [1209:8087 MisfitTech.net Nano Zero]
Port 3: 0103 power enable connect [1209:8087 MisfitTech.net Nano Zero]
Current status for hub 1-1 [0424:2514, USB 2.00, 4 ports]
Port 1: 0503 power highspeed enable connect [0424:2514, USB 2.00, 3 ports]
Port 2: 0103 power enable connect [2341:0042 Arduino (www.arduino.cc) 85334333931351612251]
Port 3: 0503 power highspeed enable connect [046d:0825 13DECCE0]
Port 4: 0100 power

What happens when disabling Port 2 on 1-1 with sudo uhubctl -a 0 -p 2 -l 1-1

Current status for hub 1-1.1 [0424:2514, USB 2.00, 3 ports]
Port 1: 0503 power highspeed enable connect [0424:7800]
Port 2: 0100 power
Port 3: 0100 power
Current status for hub 1-1 [0424:2514, USB 2.00, 4 ports]
Port 1: 0503 power highspeed enable connect [0424:2514, USB 2.00, 3 ports]
Port 2: 0000 off
Port 3: 0100 power
Port 4: 0100 power

That's a very cool table but I'm missing the which-slider-did-you-exercise.

For your Raspi3B+, your screen should be different. It should allow all four ports to be exercised. If this is not the case, let me know.

Big caveat: The uhubctl program (on the Raspi3B) is guilty of what are called "false positives". It will lie to me and suggest that Port 5 is toggled OFF, for example, but there will be no affect whatsoever; the Raspi3B can't individually control the ports. If I were the author, I would detect that the hardware returns "ganged" for the type and then simply do nothing for any port other than one or two. What he's doing is sending the command to the USB hub, it's toggling the state and yet not adjusting the power. It then (earlier) gave me a false sense that I was actually doing something.

I was directly experimenting withsudo uhubctl -a 0 -p 2 -l 1-1.1 etc, not the plugin

Oh. Ummm....

Behind-the-scenes, the current plugin runs commands like:

USB2:

sudo ./uhubctl --loc=1-1 --ports=2 --action=on

The remaining USB3, USB4, USB5 then would directly change that argument to ports. What this means for me is that I'd need to know what location decoration is required for a Raspi3B+ in order to make this happy.

If you're suggesting that the plugin for you toggles OFF all four ports when sliding USB2, that means—I'd guess—that the location of 1-1 is too promiscuous and needs to be brought down to the 1-1.1 level.

It's entirely possible that the chipset on your hub 1-1 is the "ganged" variety like on the Raspi3B and then the hub 1-1.1 is the better variety that allows control.

If you're patient, I can order a Raspi3B+ and do the analysis locally.

If it can help, I added the commands I used to the table:

NZS1 NZS2 Arduino Webcam
1-1.1 port 2 1-1.1 port 3 1-1 Port 2 1-1 port 3
NZS1 1-1.1 port 2 sudo uhubctl -a 0 -p 2 -l 1-1.1 0 1 1 1
NZS2 1-1.1 port 3 sudo uhubctl -a 0 -p 3 -l 1-1.1 1 0 1 1
Arduino 1-1 Port 2 sudo uhubctl -a 0 -p 2 -l 1-1 0 0 0 0
Webcam 1-1 port 3 sudo uhubctl -a 0 -p 3 -l 1-1 1 1 1 0

So 1-1 is working on port 3 but not 1-1 port 2. Do you need any other information?

So... can you confirm that all of these combinations definitively work for you (at the command line) without unwanted side-effects?

NZS1 on: sudo uhubctl --loc=1-1.1 --ports=2 --action=on
NZS1 off: sudo uhubctl --loc=1-1.1 --ports=2 --action=off
NZS2 on: sudo uhubctl --loc=1-1.1 --ports=3 --action=on
NZS2 off: sudo uhubctl --loc=1-1.1 --ports=3 --action=off
Arduino on: Probably not do-able
Arduino off: sudo uhubctl --loc=1-1 --ports=2 --action=off
Webcam on: sudo uhubctl --loc=1-1 --ports=3 --action=on
Webcam off: sudo uhubctl --loc=1-1 --ports=3 --action=off

Ultimately, you could run sudo lsusb -vvv and search for the word "ganged". This will tell you a lot about how things are going to work on one of the hubs.

From what I see, that port that you've got the Arduino plugged into is on a ganged set of four ports and it's behaving like the Raspi3B. You might ultimately re-arrange things so that the Arduino can be better controlled. It could be the limitation that this author was referring to.

So in the same order I get:

NZS1 on: sudo uhubctl --loc=1-1.1 --ports=2 --action=on OK
NZS1 off: sudo uhubctl --loc=1-1.1 --ports=2 --action=off OK
NZS2 on: sudo uhubctl --loc=1-1.1 --ports=3 --action=on OK
NZS2 off: sudo uhubctl --loc=1-1.1 --ports=3 --action=off OK
Arduino on: sudo uhubctl --loc=1-1 --ports=2 --action=on Arduino on, Webcam on, NZS1 still off, NZS2 still off
Arduino off: sudo uhubctl --loc=1-1 --ports=2 --action=off all OFF
Webcam on: sudo uhubctl --loc=1-1 --ports=3 --action=on Webcam still OFF despite reporting power
Webcam off: sudo uhubctl --loc=1-1 --ports=3 --action=off OK

And in this order I get:

NZS1 off: sudo uhubctl --loc=1-1.1 --ports=2 --action=off OK
NZS1 on: sudo uhubctl --loc=1-1.1 --ports=2 --action=on OK
NZS2 off: sudo uhubctl --loc=1-1.1 --ports=3 --action=off OK
NZS2 on: sudo uhubctl --loc=1-1.1 --ports=3 --action=on OK
Arduino off: sudo uhubctl --loc=1-1 --ports=2 --action=off all OFF
Arduino on: sudo uhubctl --loc=1-1 --ports=2 --action=on all ON
Webcam off: sudo uhubctl --loc=1-1 --ports=3 --action=off OK
Webcam on: sudo uhubctl --loc=1-1 --ports=3 --action=on OK

So the odd behaviou is sudo uhubctl --loc=1-1 --ports=2 --action=off. It can't switch off this port individually.
For the 3B+ I would:

  • Remove the slider corresponding to sudo uhubctl --loc=1-1 --ports=2 --action=off / on
  • Add a slider to disable/enable all by running all of the 4 commands.
1 Like

I see ganged but I don't see a reference to 1-1 port 2 in that section of the log (or the matching device ID)

lsusb vvv.zip (6.3 KB)

Displaying a combination of iManufacturer, idVendor, iProduct and idProduct next to the sliders would give useful info about what's connected!

Here is the output of

sudo lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
        |__ Port 5: Dev 5, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M

And here is where the printer's MCU is connected.
USB_port_used

After running few more tests I need to take back part of my earlier statement. Disabling either port 2 or 5 terminates connectivity between RPI and MCU. The difference is - LCD goes off only when USB2 is powered off and UI switches from Connected to Disconnected state in sync with port 5.

Thanks