-
-
Notifications
You must be signed in to change notification settings - Fork 889
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
Improved placement of MESH comments (combing/wipes) #1369
Comments
The logic behind what happens is that Cura finishes printing one object at the end of the last extruded line. From there it's either finished with the layer, or it needs to print more objects. When it prints the next object, it just starts from whichever state the printer was left in: probably somewhere inside another mesh, but it doesn't know and doesn't care. It just travels to the start location of the new object in whichever way it deems necessary. Sometimes this travel move may need to go through other parts. In particular, if the infill is printed after the walls it'll probably end up on the last infill line. But it may also need to go through completely unrelated parts, for instance if printing several concentric rings and it needs to travel from the innermost ring to the outermost ring (passing through several intermediate rings). Note that this doesn't just happen for the first travel move going towards the seam position, but also for travel moves within the same part if combing is not possible (e.g. if combing is set to Infill Only but there is no infill on that layer, or if combing is disabled altogether). Beyond the current behaviour, it is theoretically possible to use a
Considering the magnitude of the changes required, and the minority of the issues it causes (a few seconds extra printing time), I think this is not something we should consider implementing in the near future. I'll defer this until there is a more pressing need to get the |
I agree it is a minor inconvenience, except when it is in the last object before NONMESH layer change moves. The F600 movement that includes X and Y coordinates will mean a very slow movement that lets filament ooze considerably. There is clearly no advantage to having those X and Y coords as they are exactly the same as the previous coordinates (in all the examples I looked at). I do think in the larger scheme of things, as long as gcode remains the standard for 3D printing, having well-defined object/movement delineation should be a goal, as the ability to distinguish objects during a print can alleviate some of the bigger headaches associated with printing (single object failing and taking out entire build plate). I need to look further, but if you put the ;MESH comments just before the first extrusion move of an object, rather than at the end of the previous object, this could fix the problem? |
Putting the There is currently just not enough information in the g-code. This information shortage comes from the inside of CuraEngine where the combing routine doesn't know which meshes it is crossing. |
I think it is still important to remove the X Y coordinates from the F600 move. It is not needed and it destroys the functionality. |
I feel like I'm closing in on a solution (work around?) that would provide a fix for this.
|
I don't really know where those snippets of code are coming from or where they'd be positioned in CuraEngine. The
Note that this doesn't actually cause the nozzle to move. It's just an internal tracker.
I would expect I'm not entirely sure what you're trying to edit there. But hopefully this answers your immediate questions and helps in the endeavours you're trying to fix this for yourself or your users. The problem for us that I described earlier remains though. We will not merge a solution for your plug-in if that affects other features negatively or increases the code complexity too much. |
I'm simply trying to improve the delineation of individual objects in the gcode, and I think this is should be possible with very minor changes. This isn't something that is strictly for me or my plugin. Any integration of M486 commands (which I believe is under consideration: Ultimaker/Cura#7014) will also benefit from having these more accurately represented in the gcode. |
added a setting that if enabled will attempt to remove X and Y components from NONMESH z-hop moves to avoid a slow travel move across the bed for details see Ultimaker/CuraEngine#1369 (comment) and paukstelis/Octoprint-Cancelobject#62
Application Version
4.7+ (at least)
The incorporation of MESH comments is designed to delineate moves associated with each object on the build plate.
Current versions of Cura like to include additional moves on a previous object after it places the MESH comment. I have two cubes on the build plate separated far apart (around ~X35, Y24 and the other at ~X190, Y140) so the coordinate differences are easy to see. Note the transition around the change to cube 2:
The first two moves after the MESH comment are still related to the previous object. If using OctoPrint cancelobjects or M486 in Marlin, and the previous object (X35) is cancelled, there is an extra travel move.
Also, if wipes are enabled these wipes happen here as well.It actually gets worse if you look after it completes the last object in the list and moves to NONMESH:
While it totally makes sense to have the layer change in NONMESH, if you cancel the object before NONMESH, the first thing that will happen is an F600 move across the build plate. This was brought up as recent issue: paukstelis/Octoprint-Cancelobject#62
It seems like the layer change Z move should not be tied to any X and Y moves, and when at all possible.
It seems that most of this is a result of combing, as the moves to get out of an object mostly disappear (with the exception of NONMESH) when combing is turned off.
The text was updated successfully, but these errors were encountered: