@orrious@Dunstkreis Perhaps you can share your solution in the above post. I am not sure if you changed Python code manually. Is it commited to the master branch?
What is the problem?
After PSU Control plugin switched on the printer Octoprint cannot connect to Klipper. It runs into an error connecting to the MCU.
Changing monitoring state from "Offline" to "Detecting serial connection"
Performing autodetection with 3 port/baudrate candidates: /dev/ttyUSB1@250000, /tmp/printer@250000, VIRTUAL@250000
Trying port /dev/ttyUSB1, baudrate 250000
Connecting to port /dev/ttyUSB1, baudrate 250000
Handshake attempt #1 with timeout 2.0s
Connected to: Serial<id=0x9ede9e08, open=True>(port='/dev/ttyUSB1', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Send: N0 M110 N0*125
Handshake attempt #2 with timeout 2.0s
Send: N0 M110 N0*125
Handshake attempt #3 with timeout 2.0s
Send: N0 M110 N0*125
Recv: \x06\x10]ó\x1b~\x05\x10\x9e\x81~
\x10`3\x81\x91
Trying port /tmp/printer, baudrate 250000
Connecting to port /tmp/printer, baudrate 250000
Handshake attempt #1 with timeout 2.0s
Send: N0 M110 N0*125
Recv: // Lost communication with MCU 'mcu'
Recv: // Once the underlying issue is corrected, use the
Recv: // "FIRMWARE_RESTART" command to reset the firmware, reload the
Recv: // config, and restart the host software.
Changing monitoring state from "Detecting serial connection" to "Operational"
Recv: // Printer is shutdown
Recv: !! Lost communication with MCU 'mcu'
Send: N0 M110 N0*125
Changing monitoring state from "Operational" to "Error"
Send: M112
Send: N1 M112*32
Send: N2 M104 T0 S0*35
Send: N3 M140 S0*102
Changing monitoring state from "Error" to "Offline after error"
Connection closed, closing down monitor
What did you already try to solve it?
I put it in Delay of 20s and also a FIRMWARE_RESTART command like mentioned in the above discussion but it does not work.
You are right. Klipper via virtual port and MCU via USB (Serial). If I do it manually (Connect and then FIRMWARE_RESTART) it works fine. It has something to do with the handling from PSU Control .
If I do not use PSU Control auto-Connect handling everything is fine. So seems really related to the handling. I bet it is the missing timeout. Do you know this error?
PSU control auto-connect controls the USB port of OctoPrint. OctoPrint can connect via USB to a Marlin printer or via a virtual USB port to Klipper. Not more.
When you run Klipper, Klipper overtakes the control of the USB port that is dedicated for the connection to the printer. OctoPrint does not have no access any more to the USB port. This is a logical conclusion on how it works. (See the link in my second post).
I think @kantlivelong can confirm that.
That is right, but I do not understand why that explains why it should not work with Klipper.
USB port is not important, as it is a emulated serial port in case of Marlin. As Klipper provides a second virtual serial port (/tmp/printer) OctoPrint connects there and Klipper connects to the USB port (emulated serial). So there is no difference to OctoPrint as it connects to a serial port. But as I understood the first command could be send only after Klipper connects to the printer and there a timeout has to be set. That timeout is there if I do everything manually. I think that is the reason why it is working fine then.
PSUControl will just call connect for the last used connection. Shouldn't care about method.
OctoPrint should always be connected to Klipper though so I don't see why you would need a connect. TBH if you've already got that I don't see the point of using PSUControl.
Keep your OctoPrint/Klipper instance and MCU always on and just switch power required for motors and heaters with Klipper.
Didnt wanna leave this unanswered. But as its quite some time since then I cant completely recall, what I did, but yes, I changed some lines on my instance and put everything up here:
Cant add anything else to this topic as I dont got the time at the moment to dig into it again ...