Cura assumes gcode settings

[mrx23dot]

Cura doesn't set printer modes explicitly (eg. absolute coordinate mode). E.g. if someone sets relative coordinate mode manually, then I load my sliced gcode, the file will assume absolute coordinate and possibly crash something.

There is no gcode command in Marlin to reset volatile settings, and I do not want to restart the printer between prints. So Cura must explicitly set the environment, // I only noticed the coordinate modes but there could be other settings too.

(think uninitialised variables analogy)

Application version 4.7.1

Platform win7

Printer marlin, printer independent

Reproduction steps

1. set relative mode G91
2. start print

Screenshot(s) CE3_small_enc_lid.txt

Actual results gcode assumes absolute mode active

Expected results gcode should set everything explicitly, and not assume

Project file Log file Additional information

[wblake0000]

This bug has bitten me several times as my end gcode script uses relative move mode. Therefore the next print goes haywire. If I forget to set it make to absolute mode.

[GregValiant]

I put a G90, M220 S100, M221 S100 in my Start Gcode.

[mrx23dot]

Sure experts can fix it, but it won't help 3D printing becoming mainstream (so grandma can using it).

[fvrmr]

Will discuss this with the team. Keep you posted!

[fvrmr]

We can't maintain all different kinds of interface on all the 3D-printer out there. So we are depended on the community contributions, so if we want to make it more accessible for our elderly grandmothers we request that this is done per-printer basis.

[wblake0000]

I don't think you fully understood the issue because "We can't maintain all different kinds of interface on all the 3D-printer out there." This issue affects Ultimaker printers also if you follow the reproduction steps. The suggestion was simply to specify that Cura should put G90 at the beginning of the gcode that Cura generates. Because if the user has added start gcode with G91 and M83 and draws some sort of prime line etc, then the rest of the gcode generated by Cura will run in relative position mode and relative extrusion mode, incorrectly, since G90/M82 (which the Cura code assumes) is not specified at the beginning of the Cura code. It's a bug, a very simple one to fix and best practices dictate that it should be done. The suggestion would be that at the beginning of the gcode that cura generates (after it inserts the Start G-code) that it specifies G90 and M82.

[jellespijker]

As @fvrmr correctly states we simply don't have the resources to test and implement this for all strange and wonderful printers that the community uses. This simply has to be done on a per printer basis. As @GregValiant said the G90 and M82 can be added to the start code. If you think it should be added to your specific printer, I ask you to make a Pull Request with the suggested change in the beginning GCode.

[mrx23dot]

But this has nothing to do with printer type.

If slicer wants to use relative coordinates, then it should explicitly say then we are switching over to relative coordinates. Otherwise there could have been an aborted gcode in the system, and there is 50% chance of coordinate system is relative. Only way to test it is to crash the HW.

Again nothing to do with the printer types. https://en.wikipedia.org/wiki/Defensive_programming

I would love to add those 2 missing lines, but I have 0 knowledge of the code base and test process. (at least keep the ticket open for another user who can fix this in 2minutes) There is no point adding new features if the foundation is not rock solid.

[wblake0000]

Just to be clear the suggestion is not printer specific. @mrx23dot beat me to this. However a little more detail. The format is:

• Start GCode (Printer Specific)
• Main GCode (Prints the model but this code assumes G90/M82 which is not guaranteed)
• End GCode (Printer Specific)

The suggestion is at the beginning of the Main GCode above (not the Start GCode) G90 and M82 should clearly be specified as they are assumed by the Main GCode. This prevents an issue where the user has made modifications to the Start GCode and executed G91/M83 without resetting it back to G90/M82 erroneously.

[jellespijker]

@mrx23dot and @wblake0000 Thank you for arguing your cases. I think it has merit indeed. Since this is the first time in 7 years that somebody raises this issue we were unaware of the impact it might have. Because our own printers are per default in absolute mode.

I do think that the statement of a 50% change of it being in a relative state, is exaggerated. Just because the outcome is binary doesn't mean the probability is.

I will reopen the issue and we'll looking into any related PR that handles the proposal gracefully. Provided that the the won't introduce breaking changes for the existing printers of course.

[mrx23dot]

Appreciate it!

[Ghostkeeper]

Cura necessarily needs to make assumptions on the state of the printer. You could see these assumptions as lack of defensive programming. But you could also see these assumptions as contracts between the printer and Cura. For instance Cura will assume that at the end of the start g-code, the material is molten at the nozzle tip, ready to go.

Defensive programming in this case can also be dangerous. For instance, Cura currently defensively outputs a T# to make sure the printer is on the starting extruder. But this T# can generate errors on some printers. So if we start adding such defensive programming things for all printers we'll almost certainly break Cura for some printers, meaning we'd disable it by default. But then you might as well add it to your start g-code.