Why is print head moving to MAXX and MAXY before printing

[FritzGerald 1]

Hello everyone.

 

Cura3D and my printing jobs worked fine for years. I do 3d printing for hobby, so probably a part a month. Unfortunately a couple of month ago all my newly created print jobs contain a fast G0 movement to MAXX and MAXY prior to printing, which I do not want. This is caused by a line inserted between the layer count output:

....

;LAYER_COUNT:26
G0 F7200 X210.575 Y162.575
;LAYER:0

....

 

Therefore it is NOT caused by my custom printer specific "Start-G-Code" or "Start-G-Code". I cannot identify how and why this code is inserted. Anyone has any ideas? I am not even sure if it was inserted after an software update. I think I did not change anything in the settings. Prime Tower is disabled to my knowledge.

 

Kind regards,

 

Fritz

 

Example G-Code:

;FLAVOR:Marlin
;TIME:946
;Filament used: 0.868348m, 0m
;Layer height: 0.2
;MINX:45.064
;MINY:76.301
;MINZ:0.25
;MAXX:210.575
;MAXY:162.575
;MAXZ:20.001
;TARGET_MACHINE.NAME:BIBO2 
;Generated with Cura_SteamEngine 5.8.1
T0
M140 S80
M105
M190 S80
M82 ;absolute extrusion mode
M109 T0 S265.0
G21                     ;metric values
G90                     ;absolute positioning
M107                    ;start with the fan off
G28 X0 Y0               ;move X/Y to min endstops
G28 Z0                  ;move Z to min endstops
G1 Z2.0 F400            ;move the platform down 2mm
T0
G92 E0
M75                     ; Start Print Job Timer
M117 BIBO Printing...
G92 E0
G92 E0
G1 F1500 E-6.5
;LAYER_COUNT:26
G0 F7200 X210.575 Y162.575
;LAYER:0
M107
G0 F3600 X76.761 Y100.346 Z0.25
;TYPE:SKIRT
...
...

 

[Slashee_the_Cow 480]

If you could post your startup gcode that might help (and if the extruder has any startup gcode of its own, that too) - sometimes Cura adds things if it thinks something important is missing.

 

One thing that stands out to me is your homing commands:

1 hour ago, FritzGerald said:

G28 X0 Y0               ;move X/Y to min endstops
G28 Z0                  ;move Z to min endstops

The correct syntax (assuming your printer uses regular Marlin) has no numbers - it should just be G28 X Y and G28 Z (if you need to have them separately instead of just homing all three at once with a regular G28 - and if you are going to have them separate it's much better to home the Z first and move the tool up so you don't risk scraping the bed on the XY).

 

I have no idea if it would make Cura would add a travel to the maximum X and Y coordinates because of that (if the position of the tool can't be trusted - which it can't if it isn't homed - if you move it to the maximum required coordinate you can be sure you'll have room to print.)

[FritzGerald 1]

Hi @Slashee_the_Cow,

 

thanks for your quick reply.  You are right about the homing order, I actively decided against it for some internal reasons.

 

Attached the Start-Gcode and there is no extruder specific code.

;Start GCode
M109 T0 S{material_print_temperature_layer_0}
M109 T1 S{material_print_temperature_layer_0}
G21                     ;metric values
G90                     ;absolute positioning
M107                    ;start with the fan off
G28 X0 Y0               ;move X/Y to min endstops
G28 Z0                  ;move Z to min endstops
G1 Z2.0 F400            ;move the platform down 2mm
G92 E0
M75                     ; Start Print Job Timer
M605 S2 P11
M117 BIBO Printing...

 

I am also wondering where the feedrate of 7200 is taken from?!?

 

Cheers, Fritz

 

[Slashee_the_Cow 480]

18 minutes ago, FritzGerald said:

I am also wondering where the feedrate of 7200 is taken from?!?

Marlin does speeds in mm/minute. I don't know why. Find whatever speed is set in Cura at 120mm/s and you might have your answer.

 

I'd still change the homing code to remove the numbers, slice something and see if that stops the extra move being added.

 

If I may offer a couple of other thoughts on your startup gcode:

26 minutes ago, FritzGerald said:

M605 S2 P11

I'm not familiar with your printer, but I'm guessing it's single nozzle, multi extruder? It's just that the P11 in that command will tell it to move extruders 0, 1 and 3 (it's zero-based) together (bitmask is 1011). I'm assuming you don't actually have four extruders? If you have only two extruders and they're numbered 0 and 1 (which I'd guess they would be, especially based on your tool numbers) you're better off just using M605 S2 E1

 

You don't have temperature commands for the build plate (M140 and M190) which results in Cura adding them right at the start by itself. This isn't technically wrong, but in my startup gcode I use an M190 with a lower temperature than the final one, then an M104 to start the hot end heating up, then an M190 to wait for the build plate for its final temperature, then home the nozzle (my printer has a PEI plate so the odds of it expanding as it heats are low, but my brain is too thorough about doing things "properly", at least as it sees it 🤕) followed by an M109 to wait for the nozzle.

 

To be thorough, it's a good idea to have an M220 S100 then M221 S100 at the start to reset the feed rate and flow rate in case a previous gcode file changed them before the end and didn't change them back. A lot of printers will reset it anyway at the start of a new print but it can't hurt to make sure.

 

44 minutes ago, FritzGerald said:

G92 E0

Just to be pedantic, this isn't necessary because you haven't actually extruded anything in your startup gcode, so the extruder will be at 0 anyway.

[FritzGerald 1]

Hi @Slashee_the_Cow,

 

thank you for your feedback and all the other suggestions. I changed the homing code numbers, but it did not change anything. I think I somehow have to dive into the code to see what causes this line.

 

Kind regards

[GregValiant 1,409]

That travel move was hard to find.

It's the initial move to the prime tower location for purging.

Both of the BIBO extruder definition files have these lines:

        "machine_extruder_end_pos_abs": { "default_value": true },
        "machine_extruder_end_pos_x": { "value": "prime_tower_position_x" },
        "machine_extruder_end_pos_y": { "value": "prime_tower_position_y" },
        "machine_extruder_start_pos_abs": { "default_value": true },
        "machine_extruder_start_pos_x": { "value": "prime_tower_position_x" },
        "machine_extruder_start_pos_y": { "value": "prime_tower_position_y" },

 

Deleting the  Start and the End position lines will keep that travel line out of the gcode.

Think before you do that.  You might not need it but someone thought it was a good idea to have it in there.

 

 

[GregValiant 1,409]

@Dustin,

 

I see this line added regardless of the number of extruders enabled, or whether or not "Prime Tower" is enabled.

;LAYER_COUNT:348
G0 F7200 X-106 Y-92  > Travel to the extruder start position:  X="prime_tower_position_x", Y="prime_tower_position_y"
;LAYER:0

 

I can understand if the Prime Tower is enabled, but if the "Prime Tower" is disabled, or only a single extruder is enabled, should that line go in?  It seems to happen with UM printers as well as at least a few 3rd party printers.

[FritzGerald 1]

Hi @GregValiant, sorry for my late response, I was away. Thank you for your time and looking at the issue. Do I understand you correct, that you could reproduce the problems on other printers as well?

[GregValiant 1,409]

I don't know that the move itself is a "problem".  Any printer with the "machine extruder start/end positions" defined in their extruder definition file(s) will have that line added.  Some might require it.  I will assume that since UM does extensive testing on their machines that it works for them and it likely works for others.  It might be a case of "Hey, if your gonna puke then go puke in the corner!".

 

There have been issues with some Cura settings being used when their parent setting is set to "False".  That is a problem as it creates the dreaded "unexpected behavior".  I can't remember exactly what the specific settings were, but this might be another case of that.  If you aren't using a purge tower then why move to the purge tower location?

Edited November 25 by GregValiant

[FritzGerald 1]

Hi. You are right about my misleading term "problem". I did not mean it this way. I was just surprised by the movement and I believe - I am not 100% sure - that it was somehow introduced in a cura3d software update, since it did not happen before. However, I have to test it to confirm this "observation".

 

And I agree that the movement to purge tower location without enabling it is in best case unnecessary and annoying. Should I open a issue at github for this? What do you think?

[GregValiant 1,409]

Yeah, I'd say that's a bug.  As I mentioned, there were other "child" settings that were invoked even when the "parent" setting was turned off.  A bug report HERE on Github is a good idea.

[FritzGerald 1]

Hi @GregValiant. Thank you for all your time. I opened a ticket at https://github.com/Ultimaker/Cura/issues/19959 for this this issue.

[FritzGerald 1]

For everyone facing this problem:
Thanks to @GregValiant there is a workaround for this problem until the issue is fixed code-wise. The workaround is described here: https://github.com/Ultimaker/Cura/issues/19959#issuecomment-2504969993 For those not familiar with definition files, please take a look here: https://github.com/Ultimaker/Cura/wiki/Definition-Files-Explained