Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Head is moving to MAXX and MAXY before printing #19959

Open
fixundfertig123 opened this issue Nov 27, 2024 · 9 comments
Open

Head is moving to MAXX and MAXY before printing #19959

fixundfertig123 opened this issue Nov 27, 2024 · 9 comments
Labels
Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. Type: Bug The code does not produce the intended behavior.

Comments

@fixundfertig123
Copy link

Cura Version

5.8.1

Operating System

Win 11

Printer

Bibo2

Reproduction steps

Unfortunately a couple of month ago (I think after some cura3d update) all my newly created print jobs contain a fast G0 movement to MAXX and MAXY prior to printing. I have not enabled prime tower. The reason for the movement is caused by a line inserted at the beginning between the layer count output:
....
;LAYER_COUNT:26
G0 F7200 X210.575 Y162.575
;LAYER:0
....

This issue has been confirmed and discussed at the forum.

Actual results

;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...
G1 F1500 E-6.5
;LAYER_COUNT:26
G0 F7200 X210.575 Y162.575
;LAYER:0
...

Expected results

;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...
G1 F1500 E-6.5
;LAYER_COUNT:26
;LAYER:0
...

Add your .zip and screenshots here ⬇️

cura.log

@fixundfertig123 fixundfertig123 added Status: Triage This ticket requires input from someone of the Cura team Type: Bug The code does not produce the intended behavior. labels Nov 27, 2024
@GregValiant GregValiant added Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. and removed Status: Triage This ticket requires input from someone of the Cura team labels Nov 27, 2024
@GregValiant
Copy link
Collaborator

Thanks for the report.
I played with this some more.
(BTW The behavior is the same with an Ultimaker S5 active.)
The OP's problem is the travel-to-the-prime-tower line that Cura inserts at the end of the StartUp Gcode section.
;LAYER_COUNT:348
G0 F7200 X97.575 Y63.575
;LAYER:0

In your "BIBO" extruder definition files, in the "overrides", are these lines:
"machine_extruder_end_pos_x": { "value": "prime_tower_position_x" },
"machine_extruder_end_pos_y": { "value": "prime_tower_position_y" },
"machine_extruder_start_pos_x": { "value": "prime_tower_position_x" },
"machine_extruder_start_pos_y": { "value": "prime_tower_position_y" },
A workaround is to change them to:
"machine_extruder_end_pos_x": { "value": "prime_tower_position_x if prime_tower_enable else 0" },
"machine_extruder_end_pos_y": { "value": "prime_tower_position_y if prime_tower_enable else 0" },
"machine_extruder_start_pos_x": { "value": "prime_tower_position_x if prime_tower_enable else 0" },
"machine_extruder_start_pos_y": { "value": "prime_tower_position_y if prime_tower_enable else 0" },
That will eliminate that travel line unless the Prime Tower is enabled.
You could also delete those lines, or change the endings to: { "value": 0 } which effectively disables them.

I see some other problems in Cura in regards to those settings.

  • The printhead always moves to "Extruder Start Prime Position" whether or not the prime tower is enabled and regardless of the extruders_enabled_count or the number of extruders used in the print.
  • The printhead never moves to "Extruder End Prime Position".
  • Neither the "machine_extruder_start_pos_x" nor the "machine_extruder_start_pos_y" can be enabled in the Cura settings. So they cannot be changed by the user, only from a definition file.

Someone from the Cura team will take a look.

@fixundfertig123
Copy link
Author

HI @GregValiant. Thanks again for taking a look at my issue that quick! I really appreciate it.

I validated your suggestions and this workaround works great for me and saves me quite some time, since otherwise I have to manually remove the line. And I forget to do it frequently ;-)

Secondly I tried to reproduce my problem and figure out when it started. I freshly installed different versions of Cura. In 5.7.0 and the extra line of code occurred. However, if I am not mistaken in 5.6.2 this line was not added. I hope that I did not pickup any legacy setting somewhere. However this observation looks interesting and I wanted to let you know for tracing down the problem.

@GregValiant
Copy link
Collaborator

I went back to 4.13.1 and the "start" position seemed to work correctly, but the "end" position never showed up in the gcode.
The Prime Tower was reworked a couple of versions ago when the "Interleaved" option was added. It is not unusual to get "unexpected consequences" in the code when making significant changes to existing code.
Glad the workaround helped as the Cura team has been busy with other things so it will likely be a while before this gets addressed.

@fixundfertig123
Copy link
Author

I'm familiar with kind of side effects :-). And it is absolutely fine with me to not being prioritized since there is a workaround. Thanks again for all your work.

@HellAholic
Copy link
Contributor

This is an intended behavior, it's there to make sure in case of a nozzle oozing, the mess is cleaned up during the move from prime tower position to the skirt/brim/raft/model start on the initial layer.
The prime tower position is only used as a purge spot, so if prime tower is enabled or disabled, the location is used to clean during move. There are many printers with many build plate shapes and start gcode details, so the approach needs to be general enough to be easily applied.
At most this travel move is gonna add 30 seconds to the print time but it means that if the nozzle has oozed and it's dragging a string of material behind it, that string will not end up in the model's bottom side.
Still if you absolutely cannot tolerate the added move, the workaround Greg offered is a good solution.

@fixundfertig123
Copy link
Author

Hi. Thank you for your quick reply. I am by far not an expert, and I do understand your intention. However, in cases where there is no prime tower (imho in most single printhead & one color printing), there is simply no cleaning taking place. On the contrary, things potentially are getting worse because you are dragging any potential nozzle oozing across the clean but hot&sticky build plate. And how do you handle the case you want to print multiple jobs in different build plate areas without removing the prior objects? And why was it introduced in release 5.7.0 without special notice? Therefore, I personally follow @GregValiant 3-point argumentation:

  • The printhead always moves to "Extruder Start Prime Position" whether or not the prime tower is enabled and regardless of the extruders_enabled_count or the number of extruders used in the print.
  • The printhead never moves to "Extruder End Prime Position".
  • Neither the "machine_extruder_start_pos_x" nor the "machine_extruder_start_pos_y" can be enabled in the Cura settings. So they cannot be changed by the user, only from a definition file.

Since there is workaround I am happy now. Nevertheless - not at high priority - I would suggest to look at and implement @GregValiant clean suggestions.

@HellAholic
Copy link
Contributor

HellAholic commented Dec 1, 2024

The move is independent of prime tower enabled setting and number of active extruders. It is simply using the position as a reference. Example of the issue with single extruder:
image
And how the move improves the result:
image
This is a single extrusion print.
You can switch the prime tower position X and prime tower position Y from within Cura which will update the move.
There is a setting that was added in 5.8.0 which is called Layer Start X and Layer Start Y which inherits from the calculated location for the move (prime tower position in this case), which indicates where the printing should start to eliminate the nozzle ooze from being dragged back across the build plate. See patch notes of 5.8.0.
image

If you have examples of bad quality resulting from this, please share them and I can raise it as an issue. The setting has been there for 2 major versions and apart from this report and the one linked in the 5.8.0 patch notes, there were no complaints.

Not all changes end up in release notes, simply because there are around 100 different changes/features/bugs that are included in a release, which will make the patch notes a lengthy novel.

@fixundfertig123
Copy link
Author

Dear @HellAholic. Thank you for your time to explain your point of view. I really understand your point and intention.

Regarding you pictures: the effect really depends upon you homing position. In the second picture, if your homing would be in the lower left corner, and if you would have nozzle oozing during heat up, your move would have dragged the nozzle oozing over your future print as well.

And maybe it is just a wording and general thing on how you view on this issue. You yourself say:
"...
You can switch the prime tower position X and prime tower position Y from within Cura which will update the move.
There is a setting that was added in 5.8.0 which is called Layer Start X and Layer Start Y which inherits from the calculated location for the move (prime tower position in this case),
..."

Please do not get me wrong. For me as an end-user (and I am an software developer myself) is is quite confusing and not very clean to have a independent setting that inherit from disabled feature settings and therefore enabling this disabled feature actuator moves. If I could make a suggestion I would introduce two independent variable settings which can independently be enabled / disabled:

  1. Start position after homing:
    • Enabled / Disabled
    • Start X / Start Y Position
    • ...
  2. Prime Tower:
    • Enabled / Disabled
    • Start X / Start Y Position
    • ...

@GregValiant
Copy link
Collaborator

I'm working on a post-processor (Hellaholic is the reviewer) to help with this behavior.
The pull request is #20013 and it has 4 basic options:

  • "Add Purge Lines" on the left, bottom, right, or top of the build plate.
  • "Move to Start Point" adds moves around the periphery of the build plate so a string doesn't get pulled through the print area.
  • "Adjust the starting E location" so the skirt/brim/raft/model will start right away. (Non-UM printers can have "dry starts" due to the retraction that Cura adds before the start of the print.)
  • "Unload Filament" at the end of the print.

The script always checks for a "Move to Prime Tower" and adds another move just before that line so the nozzle doesn't cross the print area.

I don't know if or when this will make it into Cura, but it is being considered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. Type: Bug The code does not produce the intended behavior.
Projects
None yet
Development

No branches or pull requests

3 participants