Octoprint: [Request] Make GCODE viewer gracefully handle GCODE subcodes (even if they are just an error in the slicer)

[blind-coder]

What were you doing?

Creating a GCode file with ScotchBunny's "Move to X/Y for layer change" (https://github.com/ScotchBunny/timelapseplugin, my fork: https://github.com/blind-coder/timelapseplugin) plugin in Cura 2.7 results in a wrongly parsed GCode file.
I had the following settings:
X coordinate 200
Y coordinate 110
Travel Speed 80 mm/s
Pause Before Frame 1 sec
Use M400 GCode Yes
Retract on move Yes
Retraction length 5mm
Retraction speed 55 mm/s
Z-Hop height on retraction: 0.32 mm
Z-Hop on retraction Yes
Buffer size 20 lines

Actual GCode file triggering the behaviour is available here: http://sprunge.us/MFDU
Source STL is: https://www.thingiverse.com/thing:1776425

What did you expect to happen?

GCode visualiser should show all 405 layers.

What happened instead?

GCode got compacted into 5 layers, visualisation is not possible.

Did the same happen when running OctoPrint in safe mode?

Untested, print is corrently running.

Version of OctoPrint

 OctoPrint 1.3.6 running on OctoPi 0.13.0

Operating System running OctoPrint

OctoPi

Browser and Version of Browser, Operating System running Browser

FireFox 57.0.3 on Debian GNU/Linux
Version 63.0.3239.108 (Official Build) (64-bit) on Debian GNU/Linux

Link to octoprint.log

http://sprunge.us/iKij

Link to contents of Javascript console in the browser

http://sprunge.us/jKaj

[blind-coder]

NB: The print itself is coming out fine, Timelapse video using Z change is also working as expected. Just the GCode visualiser seems to have an issue with that file.

[blind-coder]

FWIW, gcode.ws has the same issue detecting layer changes on this file.

[blind-coder]

I just figured out what's throwing the parser off.
The Cura plugins creates GCodes G0.000000 instead of G0. Funny enough, Marlin processes that just fine as a G0 code, but the parser does not seem to recognize this correctly.
I'm halfway of the opinion that that's a bug in https://github.com/ScotchBunny/timelapseplugin and not OctoPrint's GCode visualiser, but I'll leave the verdict to people knowing more about this than me.

[foosel]

Yeah, that's definitely an issue caused by that plugin, see lines 213, 221, 227 and 240 in https://github.com/ScotchBunny/timelapseplugin/blob/master/MoveToXYForTimelapse.py. That should be G%d instead of G%f. A gcode of G0.00000000 doesn't make sense (G0.0 maybe would since that is subcode format, but there's no subcode for G0 and G1 as far as I'm aware). My guess would be that the firmware not hiccuping on that is more a happy accident than intentional.

In any case that plugin should be fixed to not create floating point renditions of the gcode integer here. I'll nevertheless take a look at making the parser in the viewer support/ignore subcodes, which would also take care of this.

[blind-coder]

Thank you for that information, I'll fix that in the plugin locally and create a pull request to the upstream plugin.

[foosel]

No more hiccups on subcodes thanks to the above commit. Available on maintenance, soon devel, to be rolled out with 1.3.7

[foosel]

Closing as 1.3.7 was just released.