[3.4.1] Need to issue G90 to force absolute positioning

[JimF42]

Application Version

3.4.1

Platform

Windows 10

Printer

Custom FDM printer (Anet A6)

Steps to Reproduce

Create a printer profile and go into Machine Settings and add some code to the "Start G-code" section which includes a G91 command to switch to relative positioning. Generate the G-code and open in something like OctoPrint. Odds are the print will be off the bed. OctoPrint will usually fuss about it "too large" for the machine.

Actual Results

Generate the G-code and open in something like OctoPrint. Odds are the print will be off the bed. OctoPrint will usually fuss about it "too large" for the machine.

Add a G91 command to the end of the "Start G-code" section, and it renders and prints just fine.

Expected results

The part should render and print just fine in 3D controller software, like OctoPrint regardless of the user added G-code leaving the workspace in relative mode.

Additional Information

Please add any needed commands to make sure the workspace is set correctly for the style of G-code you will be generating after the user editable "Start G-code" section is inserted.

I am using a probe that needs Z movement to make sure its probe pin is retracted properly (HallON model probe) and I felt more comfortable using relative commands and did not put it back to absolute commands (G90) not knowing that you required absolute positioning and did not enforce it yourself. Took me several days to figure this one out while trying to learn Slic3r which does not exhibit this behavior.

[smartavionics]

The part should render and print just fine in 3D controller software, like OctoPrint regardless of the user added G-code leaving the workspace in relative mode.

Personally, I think that if you change to relative positioning within the start gcode then it's your responsibility to change back to absolute mode at the end.

[alekseisasin]

I agree with @smartavionics , "Custom" means a user has an option to create a new printer with other/own configurations. If we will add special constraints to it then it is not a Custom. I am not sure that we can dedicate extra time to implement this functionality. It will not work for other use cases.

[smartavionics]

Well it's not a big job for Cura to output a G90 after the start gcode but my point is that it's the user's responsibility to preserve the state.

[fieldOfView]

Start gcode sequence is meant to put/leave the machine in an expected state: homed, primed, preheated, units in mm, etc. If the user changes that state in the start gcode, it is up to the user to also change it back.

[JimF42]

OK, let me rephrase this a bit...

Personally, I think that if you change to relative positioning within the start gcode then it's your responsibility to change back to absolute mode at the end.

I explicitly changed it to relative because I had no idea what the current state was nor if Cura generates relative g-code or absolute g-code. (now I know it's absolute g-code). If that was that documented somewhere, then I missed it. I even tried to query Merlin directly, but apparently absolute/relative is not a state that can be queried for.

I'm sorry, but I really wasn't trying to be malicious by doing this...

Thanks for listening.

[BagelOrb]

I didn't think you were malicious. :) There is a setting to swtich Cura between relative and absolute positioning, so it's up to the user.

…

On Mon, Aug 13, 2018 at 2:42 PM, Jim Foster ***@***.***> wrote: OK, let me rephrase this a bit... Personally, I think that if you change to relative positioning within the start gcode then it's your responsibility to change back to absolute mode at the end. I explicitly changed it to relative because I had *no idea* what the current state was nor if Cura generates relative g-code or absolute g-code. (now I know it's absolute g-code). If that was that documented somewhere, then I missed it. I even tried to query Merlin directly, but apparently absolute/relative is not a state that can be queried for. I'm sorry, but I really wasn't trying to be malicious by doing this... Thanks for listening. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#4230 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIe9ETr33bO_hkjr-emq_HIJijGK9nklks5uQXRAgaJpZM4V5yPG> .

-- Kind regards, Tim Kuipers Ultimaker BV www.ultimaker.com

[smartavionics]

Hi Jim, nobody will think you are malicious and, yes, Cura could be better documented. I'm afraid that at the end of the day, the answer can often only be found by looking at the code. Of course, not everyone is a coder so it's not always straightforward to find an answer.

As a general rule, when scripts finish, Cura doesn't restore the state. As always, there are exceptions to the rule which is that scripts are always entered with the extrusion mode set to absolute. This is even true when the user has asked for relative extrusion mode. When the script has finished, the extrusion mode will be set back to relative if that is what the user has asked for. Personally, I think that behaviour is completely bonkers but the Cura devs insisted that it works that way.

[smartavionics]

There is a setting to swtich Cura between relative and absolute positioning, so it's up to the user.

That setting is for the extrusion mode, not the X/Y coordinates.

[BagelOrb]

D'oh. You're right.

…

On Mon, Aug 13, 2018 at 2:53 PM, Mark Burton ***@***.***> wrote: There is a setting to swtich Cura between relative and absolute positioning, so it's up to the user. That setting is for the extrusion mode, not the X/Y coordinates. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#4230 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIe9ERp1bOMnkmRYr3MU15P4WRRaJKG8ks5uQXbFgaJpZM4V5yPG> .

-- Kind regards, Tim Kuipers Ultimaker BV www.ultimaker.com