Ultimaker S line G-code Header GENERATOR.VERSION ER999 bug

[ansonl 19]

When adding the Ultimaker header to a gcode file so the Ultimaker S printer will let you print gcode files sliced in another slicer, the GENERATOR.VERSION needs to be of the format X.X.X

 

When the GENERATOR.VERSION is missing the third version number like 1.0 vs 1.0.1, the printer will home and error with ER999 which only lets you reboot the printer to continue using it. 

 

GENERATOR.VERSION:2.2.2 <- good

GENERATOR.VERSION:2.1 <- bad

I needed to slice a manifold model with PrusaSlicer that the latest versions of Cura had an error on and created a working profile for the Ultimaker S line printer. I was able to use the linked post to get some information on the newer Ultimaker's expected format but it would be great if the Ultimaker Griffin gcode format and header had more up to date documentation.

 

I did not see a way to report a bug with the Ultimaker printer firmware/software itself so I hope that Ultimaker team sees it here. I tested this GENERATOR.VERSION bug on an Ultimaker S3 (3?) and S7 and both printers had the same issue and solution. 

[ansonl 19]

The issue was due to a implicit type conversion in the Ultimaker firmware.

 

My write up can be found at https://ansonliu.com/2024/03/ultimaker-gcode-footprint-halt/

Edited March 2 by ansonl
solved

[robinmdh 100]

nice write up, added a comment there as well that you can skip the footprint probing problem b adding:

Quote

;PRINT.GROUPS:2

To the header. This was done so no footprint probing was attempted when there are multiple layer 1's as with print "one at a time" print-sequence option in Cura.

We could do a updated header documentation and other new things, as a lot has changed since the UM3.
We have a few more API's on the printer, as well as the cloud API. for starters.

Also thanks for the bug report! I added a small fix, don't expect it on a printer anytime soon though.

Edited March 5 by robinmdh