Octoprint Serial Exceptions

sinned6915

I am using Octoprint to talk to my controller running 2.03Beta1.

I consistently get disconnects very soon after connecting.
"SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)"

I don't remember getting these when running Marlin with the same hardware.

The raspi is connected to the +5VFSB on an ATX PSU, the controller switches the PSU on via PS_ON pin.

The webcam and controller are plugged into the USB ports on the raspi.

I have tried the things in the octoprint faq- https://faq.octoprint.org/serialerror

Here are my logs -
Octoprint
https://pastebin.com/2iMmYxSJ

Serial Log-
https://pastebin.com/dYb1Dg37

Will using M555: Set compatibility help me?

M555 P2

to force Marlin input and output?

There are some options that I can configure for communication with the controller. I am tryng to RTFM but its slow going.
The only RRF specific one is SD card relative file selection, but it does not apply to me.

Do any of these settings or GCODES look like they can help?

Thanks in advance

Dennis

dc42

The firmware defaults to Marlin compatibility for responses sent to the USB port; so unless you have a different M555 command in config.g, adding M555 P2 is unlikely to help.

You don't need to flag M0 or M1 as commands to block or pause on, but you may wish to specify them as long-running.

We're sending Gina (the creator of Octoprint) a Duet, so she may be able to help soon.

dc42

PS - I know that we have a number of users running Duet + Octoprint with no problem; but from the logs I see that you are using the LPC1769 port. So I think this issue may be specific to that port.

sinned6915

I realize that I am pretty much on my own with the bleeding edge LPC port, and there is a high likelihood there might be an issue there. But the issue only happens when I am trying to print via Octoprint.

The various options in the screenshots I posted are the default settings from Octoprint.

If the issue IS the LPC port, I feel it would be appropriate for me to do my best to try and identify the issue and contribute that way.

Part of my reason to try the LPC port was there were many times I felt that Octoprint was bottlenecking things. The printer would stutter while printing like it was waiting for a command and I'd get oozing / warts on prints. If I ran the same gcode from SD card - I'd get perfect prints. This happened when sending prints both under Marlin 1.1.x, 2.0 and now with the LPC port. I have tried all the recommended fixes but no luck I have even swapped out cables, raspi's and SD cards.

Where might I network with the folks using Octoptint + Duet? I'd be curious to see what their experiences were, both good and bad. I am also interested how DWC and Octoprint play together.

Best regards,

Dennis

Phaedrux

I think most people end up switching to using the DWC completely.

What exactly are you getting from Octoprint that you can't get from the DWC or through some other implementation?

Streaming a print over USB is always going to be problematic.

Veti

@phaedrux
the problem with the lpc port is that most boards do not have a network connection. hence him trying to use octoprint.

dc42

The Octoprint logs indicate that the USB CDC port driver reported that data was available, yet when Octoprint asked to read that data, none was provided. I am not familiar with the LPC code, but I can think of a few possible reasons:

A bug in the low-level USB/CDC driver used in the LPC port. If that same driver is being used for other firmwares, this seems unlikely.
A bug in how the LPC port of RRF uses the API to that driver.
It could be that when Octoprint asks whether data is available, there is some; but by the time Octoprint asks for the data, RRF has timed out the buffer because it has been sitting around not being fetched for too long (perhaps it was about to time out when Octoprint asked whether data is available). RRF times out buffers of data destined for USB, because otherwise the printer would stall when there is no USB client or the client isn't reading messages fast enough. The code that does this is in function Platform::FlushMessages(). You might want to try increasing the value of SERIAL_MAIN_TIMEOUT, which is currently 1000ms.

However, unless the LPC port does things differently, then there is another buffer in the USB driver itself. The status returned by the driver should indicate whether there is data in that buffer, regardless of whether or not the main RepRapFirmware code has any buffers of data ready to send to USB.

PaulHew

We're sending Gina (the creator of Octoprint) a Duet, so she may be able to help soon.

Brill, I cannot wait.
Struggled trying to setup a timelapse on my Pi, but I appreciate the info the person who did the write up on this forum.

Hopefuly they will be able to interrogate the Duet over TCP/IP as opposed to USB!
I do like the DWC and my Panel Due, but OctoPrint is handy for other things too.

dragonn

@paulhew I think on linux you can create virtual serial port from TCP via socat

PaulHew

@dragonn I am sure someone could!!! I am not a Linux pro, it took me 2-3 days just trying to get Stretch working with a Pi camera and then installing Python3 etc.
I would rather donate to someone or buy, at least it will work and take the head scratching element out of it!

sinned6915

@dc42 THANK YOU for the lead! I will bang away at it and communicate this with sdavi too.

I know that the LPC port is teetering on the bleeding edge. I know that its challenged for memory and processes. But I am hopefull that it can be figured out. I know that it has reduced MTU/MSS/buffers and only supports one client at a time, no sliding windows, all this from sdavi.

@Phaedrux yes, I am still w/o network still. trying to get my hands on Ethernet module for ReArm in the meantime. alternative is generic LAN8720 module to try. To my knowledge, the ReArm has a daughter board, X5 has wifi built in, the SKR, MKS boards only have TX/RX on UARTs. So they need a host via USB or an LCD to be functional.

Octoprint to me is more about printer management. I think of DWC as printer control- and I will freely admit that I have only witnessed it on a friend's printer and don't claim much first hand knowledge.
The things I like about it are the plugins for Tempgraphing over time, Heater timeout plugin (not sure if the idle timeout will control heaters yet), PSU control with ATX power supply which give me +5VFSB to power controller and Pi and then turn on the 12V main power via gcode or the LCD panel. Filament managment and inventory by print is nice too.

Please don't take this as me complaining for features, I acknowledge and respect that RRF was not built for some of these tasks, and that some of them need a proper, full blown processor and subsystem to function. To my knowledge, Duet and RRF were not built to provide those things, and that is OK.

Thanks to all for your help so far.

Phaedrux

@sinned6915 said in Octoprint Serial Exceptions:

Ethernet module for ReArm in the meantime.

Ah, sorry about that. Didn't click for me that you were on ReArm. My bad.

I was just genuinely curious what you find missing from DWC that Octoprint does. When I switched over I missed a few plugins too, but generally they weren't all that important. So thanks for your breakdown.

I hope that Octoprint and the Duet can begin to function together more effectively. A lot of the power of Octoprint comes from the fact it's running on more fully featured hardware. The future looks bright in that regard.

antlestxp

@phaedrux timelapse, spaghetti detector, and the ability to cancel individual items during a print are my top 3 reasons for using octoprint with my duet.

Phaedrux

@antlestxp cool. Makes sense. The only reason I use it now is for the Pallette 2