Octoprint GRBL plugin is unstable

[JensDyvik]

I have successfully tested the Octopi image on a raspberry pi controlling GRBL on an Arduino Nano. I followed the instructions on the fabricatable machines repository to install and set up.

I am able to load and run jobs. But octoprint with the grbl support plugin behaves unstable and freezes often. After a freeze the octoprint servers needs to be restarted. We need to find a way to improve the plugin. It could be great if our fixed could be sent as a pull request to the plugin repo

Issues to fix

• GRBL alarm commands are not well handled and "freezes" octoprint so that a restart is required. It would be super if Octoprint could automatically disconnect and reconnect or send a "clear alarm" command after an alarm.
• It could also be great to map the error codes to the official descriptions to help users troubleshoot.
• Octoprints sends unnecessary marlin commands that seem to sometime make GRBL go to an alarm state. Typically (M1xx).
• After a few minutes of being idle Octoprint seems go into a time out error because it expected a response from GRBL
• Pressing the "Stop" button in the octoprint interface stops the machine movements but not the spindle.

Tweaks I have made to make Ocoprint work on GRBL

Turn off "Send a checksum with a command" (This is also mentioned in the GRBL plugin repo)

Set the error Handling to "Cancel any ongoing prints". I think ignoring them entirely might be risky.

Set the temperature query interval to daily. If this one is to frequent it impacts the streaming of coordinates and creates an error response. This solution is mentioned in this issue in the plugin repo.

[JensDyvik]

Update:

It seems like the the communication timeout can be disabled with the following settings. Testing so far is promising. (Not sure if there is ant risk involved in disabling the communication timeout):

[synman]

I'm working through this myself with an Eleksmaker A3. I am periodically getting grbl error 9, 11, and 24.

I'll check my intervals tonight (they are currently set to 2 seconds) and see what I have for consecutive timeouts ( I think I already have them at zero)..

I did create a plug-in of my own for handling soft reset 0x18 and eating the hardcoded M115 Gina sends in comms.py. I'm not sure why she didn't bundle it within the printer safety plug-in itself.

[JensDyvik]

Great to hear that there are more minds working on this. Thank you for sharing and please keep us posted on your progress!

[synman]

killing the temperature polling solved my problems. I do find it a little annoying that I can't (inherently) get position updates / etc while executing, but all other benefits (I have been using Octoprint on my 3d printer for years) far outweigh that and I can probably figure some way around it.

I've disabled the temperature and gcode tabs completely and am considering doing the same for the Control tab. I'm currently undecided on whether I should work with the exiting control tab or create my own.

A couple other items I'm looking into:

• GCode Viewer (while it is typically just one layer I should be able to plot progress
• Framing (this is a must have for me... I need something to evaluate loaded gcode, determination min / max x and y, turn the laser on weak mode and draw the boundaries)