Gcode execution hangs during print on Gigabot

[amorphic]

Occasionally when printing on a re:3d Gigabot execution will halt without any user input. The interface indicates that OpenGB is still in a PRINTING state but execution never resumes.

This is difficult to reproduce but seems to occur after several successful prints have been completed.

Note: This problem was encountered in the past on a Gigabot but could not be reproduced on a Prusa i3. It was ultimately solved using USB noise filters and it was thus determined that a combination of the length of the Gigabot's USB cable and noise from the Gigabot's electronics was the problem. However this has since been reported on a Gigabot with USB noise filters in place and additional noise filtering installed.

[3D-me]

It seems a bit odd to me that if the issue is related to the noise filters that the issue presents with the USB connected to the Raspberry Pi but not while the USB is connected to a 10 foot USB extension from my desktop workstation.

[amorphic]

Hello @3D-me :smile: Are you experiencing this issue?

[3D-me]

Only the once, unfortunately without information such as a log to examine, I ended up resorting to using Pronterface off my Windows workstation again. if there is anything I can pull for you to examine, I would be glad to help.

Cheers, Shawn

[amorphic]

@3D-me opengb does keep a log. By default it is written to /var/log/opengb/opengb.log and you can increase the loglevel in /etc/opengb/opengb.conf:

logging = "debug"
##logging = "info"

Thanks for offering to help debug. If I make any changes in pursuit of this I'll let you know when they're available so you can see if they make a difference.

[amorphic]

I'm convinced that this is related to printer.Marlin's _serial_buffer. This is a Queue object which limits the number of serial commands sent to Marlin such that Marlin's own serial buffer is not overrrun.

The Queue has built-in locking but I suspect that there's some rare race condition that's occasionally triggered. As this is so rare the best course of action is probably to add additional logging to show the queue state and then analyze these logs when the problem occurs.

[amorphic]

Example logs from one of these hangs:

[D 160701 19:05:56 server:672] Sending command: b'G1 F6600 E810.53346'
[D 160701 19:05:56 server:672] Parsed response: ok
[D 160701 19:05:56 server:672] Sending command: b'G1 Z26.075'
[D 160701 19:05:56 server:672] Parsed response: ok
[D 160701 19:05:56 server:672] Sending command: b'G0 F10200 X98.429 Y111.031'
[D 160701 19:05:56 server:672] Parsed response: ok
[D 160701 19:05:56 server:672] Sending command: b'G1 Z26.000'
[D 160701 19:05:56 server:672] Parsed response: ok
[D 160701 19:05:56 server:672] Sending command: b'G1 F6600 E816.53346'
[D 160701 19:05:56 server:672] Parsed response: ok
[D 160701 19:05:57 server:672] Requesting printer temperature
[D 160701 19:06:02 server:672] Requesting printer temperature
[D 160701 19:06:02 server:672] Deduplicated queued command: b'M105'
[D 160701 19:06:07 server:672] Requesting printer temperature
[D 160701 19:06:07 server:672] Deduplicated queued command: b'M105'

Seems that for whatever reason opengb stops sending gcode. This could be because:

• The queue is full (though the last serial communication at 19:05:56 is parsing an Ok response so this shouldn't be the case).
• The queue is empty and no longer being populated.
• Something else...

[amorphic]

I've just released OpenGB 0.22.3. It includes some performance improvements as well as additional logging in DEBUG mode. Using this version I've not been able to replicate a hang during gcode execution.

@3D-me could you upgrade your installation as per the docs and try running a few prints? Be sure to set logging to debug in /etc/opengb/opengb.conf so if you do still experience this bug I'll have more information to work with.

Many thanks! J.

[amorphic]

@3D-me any chance you were able to upgrade and try this?

[amorphic]

Fixed in v0.23.0.