[Request] More resilience against arbitrarily cased protocol messages from the firmware

[ghost]

What were you doing?

Connecting to my 3D printer

What did you expect to happen?

OctoPrint connects to the printer. Status = Connected.

What happened instead?

Status remains at 'Connecting' for ever.

Branch & Commit or Version of OctoPrint

Version 1.2.11 (master branch)

Printer model & used firmware incl. version

Renkforce RF1000

Browser and Version of Browser, Operating System running Browser

Firefox 46.0.1, Windows 7 64-Bit

Link to octoprint.log

Octoprint Log: http://pastebin.com/C6j507ZU

Link to contents of terminal tab or serial.log

Terminal: http://pastebin.com/7FVfVn7H
serial.log: http://pastebin.com/5tLdp0bt

Link to contents of Javascript console in the browser

Screenshot(s) showing the problem:

http://s32.postimg.org/tr6axf85h/Octoprint.png

I have read the FAQ.

[markwal]

From Google, it appears that your printer runs a variant of Repetier. Make sure you've checked all the Repetier checkboxes under "Settings->Features". Your serial.log shows exactly what your title says: The printer is saying "wait". OctoPrint wants it to say "ok". It choosing to say "wait" seems like it means "wait" which OctoPrint is obediently doing. You said you expected OctoPrint to connect to the printer, but I wouldn't. If the printer doesn't want to accepted commands, you aren't really connected, so it seems better that it indicate that it is still waiting for your printer to connect, no?

[ntoff]

@markwal I have a feeling that isn't the issue. Mine would connect just fine even with all the wait's being spammed to the console. In my case the connection issue seemed to be related to the auto-reset on the atmega chip that for some reason caused octoprint to hang on connect and just sit there at "connecting...". Once connected though, the wait's didn't affect anything.

Repetier firmware has the ability to spam wait to the console. I guess it's meant to act like an anti-idle thing so the print host knows there's still something connected. If you have the firmware source you can disable it, if not you might have to ask the creator to turn it off (or you can go straight to repetier's website and get the stock firmware) https://www.repetier.com/firmware/v092/ go to the "features" tab and you'll see the option I'm talking about about in the middle of all the options.

[repetier]

RF1000 use a own firmware based on older repetier firmware and from there developed independently.

"wait" is important to detect communication issues fast and as far as I know octoprint also knows about this.

[foosel]

The wait indeed is not a problem for OctoPrint and in fact will make communication take up again in case of a missed ok while printing.

The issue from the looks of the log here is rather that there's no ok received for the initial M110 sent at the very beginning, so the connection handshake never finishes. Normally OctoPrint will either get an ok reply to the first M110 it sends or get the start message block from the firmware and on receiving this will send another M110 to get comms going, which then will actually be responded to by the firmware with an ok and have the connection state properly switch to "connected". Here that doesn't work because of this:

Recv: Start

That's supposed to be a lower case start, not Start. Apparently whoever adjusted that firmware decided that changing core protocol messages to upper case would be a funny idea. I can make OctoPrint more resilient there (yet again adding more complexity to get around broken firmware versions in the wild) but that will take a while.

In the meantime, this should be reported to the firmware vendor, since they broke stuff (and if they broke start, there might be more protocol messages they just happily adjusted without thinking about consequences).

[repetier]

Just wrote the author a mail about this. I think it is a clear violation of existing protocols and should be fixed in firmware and not in all existing host. As you said it makes parsing slower with each exception.

[ghost]

@foosel Thank you for your clear explanation of the problem. I now understand the main issue is because of the upper case Start. I also will contact the firmware developer, so they can fix it in the upcoming Firmware. In the meantime I'm going to look into the firmware code an try to fix the problem by myself. Thank you very much for your help!

[repetier]

I have already feedback from developer and he admitted the error and will fix it soon.

Search printer.cpp for the string "Start", should be easy to fix yourself.

[ghost]

Just checked the firmware files. The Start command is located at Communication.cpp. I will test the new firmware as soon as the printer has finished the processing print.

[ghost]

The author already released a new firmware, where the problem is fixed. Now everything works as expected!