Every 2 seconds or so, I get another "Recv: wait" and octoprint sends the next command from the G-code file. This is occurring while the bed is warming up. (The T: messages are also being received)
Eventually, when everything warms up:
Send: N76 G1 X83.18 Y84.289 E1.8856*92
Recv: T:216 E:0 B:61
Recv: ok N:9
Recv: ok N:76
There's a gap in the "ok" sequence, and the printer is not performing the actions that were in that range. One of those lost is the command to lower the Z-axis, so it prints in mid-air giving me a bunch of noodles.
I can work around this by either making sure I preheat before printing, or spamming a few hundred extra lines in my startup G-Code (like repeating M109) so that there is no harm when the commands are lost.
Adding M109 to the "Long running commands" didn't seem to help.
Is there a setting I could change to help with this, or do I just need to keep my workaround?
Your printer's firmware is broken. It should not be sending a wait if it's busy doing something and not accepting new commands. It should send wait if it's waiting for OctoPrint to send the next command.
Whoever wrote that firmware didn't have a clue about what they were doing and should fix their stuff ASAP.
Some Anycubic printers appear to be similarily broken (judging by your serial.log snippets, it might actually be the same FUBAR'd firmware - please share a full serial.log to confirm) and I put together two plugins to work around the worst issues a while back in the corresponding ticket. Maybe that helps you too. Try this. Please report back on your success with these.
That was it! Here's the log before the plugins: serial_cold.log (50.9 KB)
After installing the plugins, everything worked correctly. Thanks!
Would you happen to have a link to a protocol spec or similar, that documents the correct behavior? I'd like to follow up with the vendor, but didn't manage to find any documentation beyond a few comments in the Marlin source code.
The de facto standard however is how pretty much all the major GCODE based open source firmwares work currently, and vendors would do good in flashing that somewhere and looking how they divert from it.
You can also tell them that I'll be happy to consult them on this stuff (I've had to dig through a multitude of firmwares and logs to extract all this information over the years that is now reflected in the implementation OctoPrint's comm layer).
I've been meaning to document at least what kind of protocol OctoPrint expects, however I have my hands full with too much other stuff. And my attempt to create a standardized well defined protocol definition document for everyone wa met with too much resistance a couple years ago to proof viable.
@foosel@frankr Hi there, do you know if this is still the solution for this issue? If so how did you input the plugins? I tried copying the URL into the Plugin manager in Octoprint, but this didn't work. It gave me an error. Thanks for the help
@OutsourcedGuru Not sure if I am doing something wrong here or what. Am I able to install these only through SSH? If so, could you please tell me exactly how to do that. I have already attempted that as well, but when I put the links in, nothing happened.
I'd say that you'd need to follow the instructions that foosel gave. From my take of it, she wanted you to ssh into the Raspberry Pi and do it as instructed.
Hahahah That is exactly how I am feeling right now. But okay, I was just seeing if the 2 plugins may have been published into the repository yet or not.
@OutsourcedGuru Ya I get it. . I gotta stop looking for the easy way out haha Okay so I put the plugins in through ssh, but how do I know they took. Dumb questions I know, but also when I sudo service octoprint restart, nothing happens at all.
Reboot. Then check the octoprint.log to see if the two new plugins have loaded. You could also go into the Plugin Manager and see if they exist there by name.
I looked them over. They appear to be of the quick-and-dirty type. But they still should show up in the Plugin Manager.
I have this same printer, and thus I would assume the same "wonky firmware" :] . should I implement this patch from the get-go or should I wait and see if I encounter the error?
I'd apply the patches right from the start. Otherwise, the first time you forget to preheat the printer you're going to be printing noodles. The plugin is really simple and I've had no problems with it.
Qidi had no interest in trying to fix USB, their response was "Yeah, it doesn't work right, use the SD card instead".
TY! Not trying to hijack the thread, but can you tell me how you hooked the Pi up to the X-one2? Picture would be amazing. No hurry, as I haven't even gotten the image on my Pi yet. LMK if I should just start a different thread, like "Qidi X-one2 Start Up and Configuration". Thanks again. -Mike
