-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Comments
Thanks for the report. In your "BIBO" extruder definition files, in the "overrides", are these lines: I see some other problems in Cura in regards to those settings.
Someone from the Cura team will take a look. |
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. |
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. |
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. |
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. |
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:
Since there is workaround I am happy now. Nevertheless - not at high priority - I would suggest to look at and implement @GregValiant clean suggestions. |
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:
|
I'm working on a post-processor (Hellaholic is the reviewer) to help with this behavior.
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. |
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
Expected results
Add your .zip and screenshots here ⬇️
cura.log
The text was updated successfully, but these errors were encountered: