[BUG] Interferes with restarting hardware serial port

[jbkuma]

Description of the bug
If the printer is powered off or stopped due to a fault, octoprint is unable to reestablish the serial connection on the Pi's hardware serial port. In order to reinitialize the serial connection, the raspberry pi has to be rebooted. Deactivating the plugin returned the expected behavior. I do not use a USB connection and my current setup doesn't allow testing that configuration.

Steps to reproduce

1. Connect to printer via hardware serial.
2. Power down printer
3. Power up printer.
4. Attempt to reconnect serial. Connection fails.

What did you expect to happen
Serial should reconnect as normal.

Logs and screenshots
Connection closed, closing down monitor
Changing monitoring state from "Operational" to "Offline"
Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyS0, baudrate 250000
Changing monitoring state from "Opening serial connection" to "Error: Connection error, see Terminal tab"
Changing monitoring state from "Error: Connection error, see Terminal tab" to "Offline (Error: Connection error, see Terminal tab)"
Unexpected error while connecting to serial port /dev/ttyS0, baudrate 250000 from hook default: SerialException: '[Errno 11] Could not exclusively lock port /dev/ttyS0: [Errno 11] Resource temporarily unavailable' @ comm.py:_open_serial:2784

[2020-08-07 02:13:58,774] INFO: Kill message recieved, Bye!
[2020-08-07 17:11:02,827] INFO: Initialising LED strip
[2020-08-07 17:11:02,830] INFO: Strip object successfully initialised
[2020-08-07 17:11:02,831] INFO: On message recieved, turning on LEDs

octoprint (1).log

Version of plugin and OctoPrint
OctoPrint 1.4.2
Plugin 0.4.0

[cp2004]

Could you just give me a few more details of how your printer is connected? It could be that it is conflicting with the plugin using SPI. Is it via the GPIO header?

[cp2004]

I can't find anything relating to hardware serial vs. SPI, on my search through the internet. I am considering that it might be something outside my control, and actually in the hands of the library that it's using, https://github.com/jgarff/rpi_ws281x
The plugin doesn't do the SPI comm itself, that is all done deep down in the library. Note I'm using the Python wrapper if you go digging.

[jbkuma]

The printer is connected directly via the pin serial pins on the GPIO header.

All of the other changes are still in place, the only thing I need to do to get things working properly again is disable the plugin. It could be what ever way the library is abusing the pi to get the pixel timing makes trouble for the serial port.

I will try running some examples from the library and report what happens as soon as I get a chance.

[cp2004]

@jbkuma Any update on this? Unfortunately this is not something I can test, and I am considering raising it upstream if you can confirm it is a library issue.

However, if I was to raise it upstream it sounds like something that may be conflicting at a hardware level. The other thought is that the library does not see much more than bug fixes / new hardware support, and so it may not get solved, and as far as I know there is nothing else that exists to control these LEDs.

Lastly, the only way I can see you getting around this, is to use the PWM pin for the LEDs. However I can not recommend to do this as it requires running OctoPrint as root, which is a bad idea. Think it even aborts if you do.

I do not say this lightly, but I think we may have to accept defeat on this one - they simply aren't compatible

[jbkuma]

Apologies, I have dealing with an emergency situation and haven't had a chance to explore this. In a perhaps related note, I read last night that pixel libraries can interfere with audio output. It seems whatever is under the hood to make the pixels work makes everything else screwy. I have an 1800 pixel matrix I use as a display and so far the most reliable thing I've found to drive it is a Nano 33 IoT. No matter what pi I've tried, It won't light up more than 1200 or so pixels reliably. I think it relates to interrupts, but I'm not sure. Another thing to consider, maybe, when time allows. I have a display that uses a ESP8266, RTC, and pixel matrix to make a clock that automatically switches over to clock, auto-scaled countdown timer, and meters for the tool, bed, and progress via MQTT that works well. I will clean that up and post it when time allows. Thanks again for looking into this and following up. Jason "Kuma" Brinkerhoff *Mad Science Workshoppe, *proprietor http://jbkuma.com/workshoppe

…

On Thu, Aug 13, 2020 at 5:22 AM cp2004 ***@***.***> wrote: @jbkuma <https://github.com/jbkuma> Any update on this? Unfortunately this is not something I can test, and I am considering raising it upstream if you can confirm it is a library issue. However, if I was to raise it upstream it sounds like something that may be conflicting at a hardware level. The other thought is that the library does not see much more than bug fixes / new hardware support, and so it may not get solved, and as far as I know there is nothing else that exists to control these LEDs. Lastly, the only way I can see you getting around this, is to use the PWM pin for the LEDs. *However I can not recommend to do this* as it requires running OctoPrint as root, which is a bad idea. Think it even aborts if you do. I do not say this lightly, but I think we may have to accept defeat on this one - they simply aren't compatible — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE3UEMB7ENJMRCM64CDFH7DSAOWFLANCNFSM4PX22IZA> .

[cp2004]

@jbkuma No problem, thanks for getting back! Hope everything is well.

Your other projects sound interesting, and I agree the Pi is not built to drive the precise timing of the LEDs, micro controllers are much better suited. But they don't run OctoPrint, so hey.

I found something that you could try in OctoPrint - there is a setting 'Request exclusive access to serial port', that you could untick, maybe it will maybe get around the issue 'cannot get exclusive access' in your logs - we might get a different one, but it's something. Warning: I do not know if there are downsides to not getting exclusive access, such as interrupted prints. Proceed with caution...

[jbkuma]

unchecking "Request exclusive access to serial port" did let me connect. I guess the potential is that during a print something will mess with the serial connection. I am running some gcode unloaded and with the heaters off and so far so good. This may be a good fix. I guess we won't know until I try running it properly and make sure it looks good. Thanks again for your help Jason "Kuma" Brinkerhoff *Mad Science Workshoppe, *proprietor http://jbkuma.com/workshoppe

…

On Thu, Aug 13, 2020 at 12:35 PM cp2004 ***@***.***> wrote: @jbkuma <https://github.com/jbkuma> No problem, thanks for getting back! Hope everything is well. Your other projects sound interesting, and I agree the Pi is not built to drive the precise timing of the LEDs, micro controllers are much better suited. But they don't run OctoPrint, so hey. I found something that you could try in OctoPrint - there is a setting 'Request exclusive access to serial port', that you could untick, maybe it will maybe get around the issue 'cannot get exclusive access' in your logs - we might get a different one, but it's something. *Warning: I do not know if there are downsides to not getting exclusive access, such as interrupted prints. Proceed with caution...* — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE3UEMFYBJ4DUYH6224OA6LSAQI4VANCNFSM4PX22IZA> .

[cp2004]

Cool, I asked on the OctoPrint discord, and the issue is other devices could intercept the serial comm, which could cause issues with prints. Let's see how it goes, if you don't mind.

[cp2004]

Hey @jbkuma!
Hope all is well.
At the weekend/next week, I will be redoing the documentation of the plugin, as it could do with an update. If you can confirm that this has solved your issue, I think it would be worth me mentioning it in the setup guide.
Let me know if there was anything else you noticed, or something else.
Thanks.

[jbkuma]

The motion looks ok, but the extrusion ends up stopping if I leave the plugin enabled. I haven't had time to test this thoroughly, but I tried to print 4 times with the plugin enabled and it failed each time. I turned the plugin off and it printed fine.

As I was writing this the spool suddenly sprung several coils loose. I'm wondering now if it was just a section of badly spooled filament and not the plugin. I will report further when I get a chance.

[cp2004]

Cool, thanks for keeping me posted!

[jbkuma]

I just had a 4 hour print and it came out fine. That other filament was garbage, it was expanding in the cold end and binding. Not sure what's up with that. I took some measurements and it only gets up to 40C..

[corbolais]

@cp2004, chiming in upon your comment OctoPrint/OctoPrint#3212 (comment) .

I do not use plain serial to connect to RAMPS, using serial over USB instead (standard way IIMSS).

Also, a raspberry pi reboot is not required to gain access again. Just restarting octoprint is sufficient.

[jbkuma]

@cp2004, chiming in upon your comment OctoPrint/OctoPrint#3212 (comment) .

I do not use plain serial to connect to RAMPS, using serial over USB instead (standard way IIMSS).

Also, a raspberry pi reboot is not required to gain access again. Just restarting octoprint is sufficient.

This has not been my experience with the serial pins. The reason I use the hardware pins is that it is faster, more reliable, and allows a cleaner install. It might not always be apparent, but if the gcode is particularly complex the serial over USB can stutter where as it will work fine over the serial pins. This effect is particularly evident with standard Cura settings. The most common way to do things isn't always the best way.

[corbolais]

@cp2004, chiming in upon your comment OctoPrint/OctoPrint#3212 (comment) .
I do not use plain serial to connect to RAMPS, using serial over USB instead (standard way IIMSS).
Also, a raspberry pi reboot is not required to gain access again. Just restarting octoprint is sufficient.

This has not been my experience with the serial pins.

My XP just references serial over USB (/dev/ttyUSB?). Restarting octoprint is sufficient, in this case. Your mileage regarding /dev/ttyS? may of course vary.

The reason I use the hardware pins is that it is faster, more reliable, and allows a cleaner install. It might not always be apparent, but if the gcode is particularly complex the serial over USB can stutter where as it will work fine over the serial pins. This effect is particularly evident with standard Cura settings.

ACK

The most common way to do things isn't always the best way.

ACK

[cp2004]

@corbolais Can you let me know if this is solved with unchecking 'request exclusive access to serial port', and what Pi model / OctoPi (if using) version please. Also a log where you have to restart to get serial back would be nice.

[corbolais]

@cp2004 I just had had the WS281x LED Status plugin installed, not yet configured. That was when I noticed this connection issue and I immediately uninstalled the plugin again. No logs/testing for the time being. In a couple of weeks I might retry the plugin. Also, I would not want to yield control over the serial port by unchecking the tick box.

[cp2004]

@corbolais Seems it may be an isolated issue, as you're the first to report this.

Would like to get to the bottom of it, maybe I can ask around for some info into PySerial etc. but would need some info, what Pi model & OS version number (OctoPi?) Are you running? Thanks.

[corbolais]

Pi model & OS version number (OctoPi?)

Pi 3B running Linux octopi 4.14.98-v7+ and octopi 1.4.2.

[corbolais]

@cp2004 Just found https://github.com/OctoPrint/OctoPrint-Remove-ttyS-Ports but hadn't had the opportunity to test it. Maybe this helps? Not exactly sure it's about the same underlying issue.

[cp2004]

@corbolais Given you didn't provide logs or any other information, I have no idea what your actual problem is, whether it is even related to the issue here.

No logs/testing for the time being.

To me, that plugin you linked is completely unrelated to the problem in this issue, but again because I haven't been given any information here, I actually have no idea so I can't say.

[mvolli]

I was running into the same issue.
But my printer is connected over USB.

Unchecking 'request exclusive access to serial port' i thought fixed it for me, but i am still getting disconnects.

Raspberry Pi 4 Model B Rev 1.2
octopi_version: 0.18.0
env.python.pip: 20.3.3
env.python.version: 3.7.3
env.python.virtualenv: true
octoprint.safe_mode: false
octoprint.version: 1.6.1

octoprint.log

Let me know if you need anything else...

[gagregrog]

Dunno if there has been any progress on this, but I am having a similar (maybe the same) issue. I am on a pi4 connected over USB. When the plugin is enabled octoprint can only connect to my printer when it first boots (or when you restart octoprint). When the plugin is disabled I have no connectivity issues.

It's a bit of a bummer, as I'd like to be able to leave octoprint running and turn my printer on/off without needing to restart octoprint to connect again. However, having the LEDs outweighs the burden of restarting octoprint, so I've just been restarting as needed.

I was wondering, is it possible to disable the package entirely when the lights are turned off so that the connection could go through and then the lights turned back on?