I came across several post related to this, but they didn't quite solve my problem.
My usecase is that I have octoprint running on a raspberry pi 2B, which is running continuously.It is connected via USB to my prusa i3 mk3. I would like to just flip the power switch on my printer, and then be able to send jobs directly from PrusaSlicer to octoprint, which in turn sends them to my printer. All without having to go through the octoprint web interface.
But for this I need to find a way to have octoprint automatically connect to the printer.
I found 2 methods when googling:
the PortLister plugin
a udev rule and script.
Both of them don't work here. I think the problem is that both Portlister and udev wait for a usb device open event. But I noticed the prusa usb device stays visible when I power down the printer. Maybe the connection electronics are powered from the USB port of the raspberry pi. but an lsusb keeps showing the device id. And I tested that when I unplug the USB cable and reinsert it, the autodetection works like a charm.
Has anyone found a trick to doing this?
Is there a way to monitor if the port is live from the commandline? Because then I can integrate it in a script. I already have the script part to make octoprint connect to the printer.
Or is it possible to have octoprint continuously poll the port? It sends regular M105 commands when it is connected and detects the printer disapearing by the unanswered commands. If it would regularly keep polling, it would also notice the printer is back and could connect to it.
Any thoughts, advice and of course solutions are welcome!
Just installed 1.5 and was wondering if there is already a solution/workaround to this problem.
I still haven't been able to get my prusa to be detected automatically by octoprint when I power on the printer( octoprint is running 24x7 on a rpi2)
The underlying problem I see is: the USB remains visible, as it is powered from the pi. So all detection on udev fails, as it remains up. Really polling the printer seems the only way I can see to get it to work.
Does anyone know how to set this up? a script of some sort? Any pointer is welcome.
I have been looking for a way to get Octoprint to automatically connect to my printer when I switch it on for some time. For me though it is just because I am lazy! I too leave my Pi3B+ on all the time and switch my printer on just when I need to print.
I too found the PortLister plugin and it works perfectly for me.
I think you need to do what I did with my Ender 3 printer and modify a USB cable to cut the USB power line. There is lots of info on this forum and in other places on how to do that. When I first got Octoprint and my Ender 3 I was unhappy that the printer board and display was being powered from the Pi even when I switched the printer off. So modifying the USB cable was one of the first things I did - and it has worked without problems for 2 years.
Also on some printers (not mine) there is a hardware option (dip switch or link) on the printer controller board which will disable power from the USB. Maybe your Prusa has that option?
Thanks for your suggestion.
I hadn't considered that hardware hack.
But with a quick search I found USB not resetting when powering off Printer (Prusa I3 Mk3). This a) is exactly my problem, with the identical printer the Prusa i3 Mk3. but b) from the last comment there, it looks like removing the 5V connection doesn't work on this printer.
I am happy to hear otherwise and some good news on this way forward.
But more generally, I would prefer a software solution. It should be simple enough to poll the printer every 30 or 60 seconds and see if it replies. This is already done while the printer is connected. So when I switch the printer off, octoprint automatically detects it. I just want it the other way arround as well!
I hadn't seen that other thread but from that it looks like @foosel herself has exactly the same issue with her Mk3.
So to confirm, when you switch the printer off you get a message in the State panel similar to:
Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:3831)
But the port is still shown in the Serial port list?
I have spoken to @foosel (in an Octoprint on air chat) about adding an autoconnect feature. She is not keen as it could break things for people who use a single (via a hub I guess) or multiple USB ports for driving multiple printers.
Just for fun. If I log into my Pi3B+ console and do an lsusb, with the printer switched off I see four "Bus 001" devices. When I switch the printer on I see an extra device at the top of the list: Bus 001 Device 008: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
When I switch the printer off that Device 008 goes away. Do you see something similar?
Hi welshjohn,
Thanks for your comment, and I was already wondering where I had seen the name @foolsel before . I'm not that familiar with the community here. But this is Gina herself of course!
Below is the outcome from lsusb in my case:
1st is when the printer is turned off
2nd is when the printer is turned on
third is when the USB cable is removed from the printer:
root@octopi:/home/bert# lsusb
Bus 001 Device 006: ID 2c99:0002
Bus 001 Device 005: ID 046d:0804 Logitech, Inc. Webcam C250
Bus 001 Device 004: ID 0b05:1706 ASUSTek Computer, Inc. WL-167G v1 802.11g Adapter [Ralink RT2571]
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@octopi:/home/bert# lsusb
Bus 001 Device 006: ID 2c99:0002
Bus 001 Device 005: ID 046d:0804 Logitech, Inc. Webcam C250
Bus 001 Device 004: ID 0b05:1706 ASUSTek Computer, Inc. WL-167G v1 802.11g Adapter [Ralink RT2571]
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@octopi:/home/bert# lsusb
Bus 001 Device 005: ID 046d:0804 Logitech, Inc. Webcam C250
Bus 001 Device 004: ID 0b05:1706 ASUSTek Computer, Inc. WL-167G v1 802.11g Adapter [Ralink RT2571]
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
As you can see, there is no change between having the printer turned on vs off. Only after I disconnect the cable 2c99:0002 disappears.
When the printer is connected, I see in the terminal that at regular intervals the M105 command is sent. When the printer doesn't reply anymore, The printer is automatically disconnected. What I am looking/hoping for is the reverse: M105 keeps being sent and when a reaction pops up, the printer is put in operational state again.
Send: M105
Recv: ok T:14.8 /0.0 B:15.4 /0.0 T0:14.8 /0.0 @:0 B@:0 P:15.5 A:21.2
Send: M105
Recv: ok T:14.8 /0.0 B:15.2 /0.0 T0:14.8 /0.0 @:0 B@:0 P:15.5 A:21.1
Send: M105
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: M105
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: M105
No response from printer after 3 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Changing monitoring state from "Operational" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"
Connection closed, closing down monitor
I saw @foosel has also reacted on the feature request. She thinks this feature might be breaking things for other usecases . I'm not clear what the risk of breaking other things with this behaviour would be. Maybe there is still a misunderstanding on the scope of this request. I am not looking for an "autoconnect", more than an "auto-reconnect".. I would like octoprint just be a bit more patient (24x7 patient:-) to see if the printer comes back on. But I might be overlooking a usecase here.
I'll leave a note there too, to keep that thread sane.
USB hubs use resistors initially to test whether a device is connected. Both the data lines are normally (no cable plugged in) pulled low via a 15k resistor. When a device is plugged in it pulls one of the data lines high via a 1k5 resistor and the hub starts trying to talk to the device and add it to the list.
So maybe the Prusa is maintaining that 1k5 pullup and the USB hub therefore stays in a connected state. When you switch off a normal device it removes the pullup and the hub resets the port ready for the next connection - but not the Prusa.
So maybe you could fix it by resetting the Pi USB port with a script - but how would you detect that the printer isn't switched on and printing? I don't know. Utilities exist to reset the ports but maybe the plugin is the best way forward.
well, I think the only good solution would be to cut of the USB power cable. Then you can work with udev rules.
The printer surly has it's own connection to the power supply.
When you take this into account, to me it's actually a bug of printer hardware to consume power over USB.
You can be lucky, that this behaviour of printer hardware doesn't do any more problems.
It's not hard to prepare a small (15 cm) USB cable by open it, cut off the red cable, do some isolation and close the cable with a good tape - and add it as extension cable into the line.
There are lots of how-tos available by internet.
Only real difficulty might be the eyes - it's very small and a bit fiddly.
I just took a quick look at the schematic for the Einsy Rambo board that the Prusa MK3(S)(+) uses.
Sheet 4 is the USB interface. According to this schematic the USB power supplies power to an Atmega32u2 who's only apparent function is to provide USB support to the main MCU of the board (an Atmega2560 on sheet3, the same MCU as on an ArduinoMega). There is an ICSP connector, but I think that is only for updating the firmware on the 32u2. There is another chip on that sheet (U10, an ADUM7441) that provides isolation on the 4 data lines that connect this 32u2 to the rest of the board.
The only way for the USB on a Prusa to disappear when power is off (and also the only way for the USB on a Prusa to work with the power line on the USB disabled) is for the end user to modify their Rambo board by jumpering JP3. Do we really want to advise people to make hardware modifications to their printers to get this functionality to work? Hmmm. Also JP4 will also need to be jumpered (if it isn't already, but I suspect not) to remove the isolation between the grounds. But that would allow noise on the USB ground to infect the rest of the Rambo board...
Looking at the Rambo schematic with a mind towards how to provide some sort of feedback, there are a couple places on the Rambo board to pull the VCC of the main MCU to use as a signal. The easiest to find (and thus probably easiest to implement) is the J7 connector. The user would then need to construct a cable to communicate the presense of the +5VDC on that connector to a 3.3VDC signal for the GPIO pins on the RPi. For something this simple, a voltage divider built into a jumper cable would probably be sufficient. Something like this:
When the printer is powered on then there should be a 3.3VDC level on the RPi end. When the printer is off then R2 should pull the RPi end to ground. The whole voltage divider circuit with these provided values should only pull about 0.02mA (0.09mW) from the Rambo board, so shouldn't even show in the power budget of the Rambo board.
Then the "hard" part (well hard for me, not being a software jockey) would be writing the plugin for Octoprint to watch for a logic high on a GPIO pin to indicate that the printer is on.
Thanks for diving in. But just to be sure, why go the hardware way in this case. It will be a much biger barrier than a software only solution. And by regularly polling the prusa with an M105 message, we would achieve the same thing.
In principle octoprint is already doing this when the printer is conneted. And it perfectly detects that the printer gets disconnected. So the opposite should be possible as well.
well, I don't have a Prusa, because of this I can't test and don't know the defaults either if JP3 JP4 are real pins / jumpers or pads only. Is there build in an optional wake up on USB feature?
At all I'm wondering about JP4. GND should ever be set to same level and problems with "bad ground" need other solutions then just put connected hardware parts by not connected GND into "ground isles".
And what's the problem? Set JP3 (JP4 should be set ever expect some very special cases) and don't input V+ by USB? That should be factory settings.
Not only because it's clear to the Pi if printer is on / off then, it also will protect the PI (and others) from being backpowered by the printer.
My fortune teller glass ball tells, that the designer of that part just took a USB reverence design without thinking about the differences between a device with mandatory own power supply and e.g. an USB memory stick. But this is speculation only and more off topic.
hmmm .... that's a good question. But if one plays around with PI's udev rools, it can't be a problem to change jumper settings to him. Unless he doesn't know what he's doing. What results in: don't touch it and use it as it is.
.
Last ditch suggestion. It seems that the Prusa logic board (as mentioned above) is the Einsy Rambo 1.1. But the are at least 2 versions of that board (a and b) and I can't find anything on the difference between a and b.
If it is a version b then there is a jumper at the back of the USB connector to select power in from either the USB or the PSU. The image below is from the board manual and shows the jumper in the PSU position - which is where I would expect it to be. It would be interesting to see the jumper position on your board.
To be honest, I'm more of a hardware jockey than a software jockey. Thus I see hardware solutions before I see software solutions. But, also, because I know something about hardware I'm developing and sharing the arguments against people making guesses about hardware fixes. The "disconnect the 5V USB wire" that is often needed for some printers is more of a hardware kludge to get around a design error of the boards they use.
I do agree with you on this point, and at the end of the day think that this should be the solution. The big question is the cadence. Should the M105 polling be at the same speed as the during operation polling which may not show connection "right away". (Which seems to be important with the ever shortening immediate gratification of society in general, I remember when 9600baud seemed blazingly fast and didn't see a need for faster. Now I grumble when Arduino tutorials teach using 9600baud...) Maybe increase the M105 cadence to 1/sec once a disconnect event has happened? Should(?) be fast enough to seem nearly immediate but shouldn't tie up the Pi (or what ever host computer it is) with flooding the Software Serial over USB driver.
. I'm not that familiar with the community here. But this is Gina herself of course!
