Open mattwn opened 2 years ago
Hi @mattwn thank you for your feature request. I will bring this up with the team. Keep you posted!
I have discussed this with the team and decided to defer this request. We don't think that this would have any value for the most users.
However there is a work around: Use another model as travel blocker and set the wall thickness, infill and top/bottom thickness to 0 in the per model settings.
I hope this will work for you as well!
I understand.
I think the fact that this feature is included in CNC packages means there is some value, but I understand the needs of the majority of Cura's userbase may be different.
I could not get your suggested workaround to work. Project file attached.
CE3_SpiralizeSupportTester-SAVEPROJECT.zip
We make lot of little custom vase type prints using spiralize mode. We keep the raft and a 100% infill support as a built in stand. The file will be sliced as normal for the first 3mm of Z axis and then switch to spiralize mode as it travels further up (this is as expected). In Preview, you can see the offending travel lines still going through the "travel blocker.stl" file in the support region (first 3mm of Z axis on the print).
Do you have any other workarounds?
I think this is a special case of spiralize mode that makes the user think the wrong way.
With spiralize mode, Cura uses just 1 wall and sets the infill to 0%, but it still considers the hollow interior to be inside of the model. Having another model overlap it there makes no difference then unless that model cuts away from the spiralized model (which you don't want because then you also get another wall there).
I don't think there really is any workaround to make Cura avoid certain parts inside of a model with travel moves.
Thank you for the reply. I was interested in "but it still considers the hollow interior to be inside of the model".
I would love if that was true, because then wouldn't combing "avoid printed parts when traveling" keep travel moves outside of the vase interior?
"I don't think there really is any workaround to make Cura avoid certain parts inside of a model with travel moves."
Is that not what Combing "avoid infill" should do?
Although I guess the interior of the vase is not "printed" nor "infill" even if it is part of the model, so perhaps you are correct in both cases.
In the end, I think I agree with your last sentence, which is why (when we posted this to the forum before we brought it to github), we were also looking to pay a 3rd party developer to create a plug-in for this. Assuming a plug-in would be capable of influencing these kinds of travel moves. I'm not sure where the best place is to advertise for a paying 3rd party plug-in job.
I would love if that was true, because then wouldn't combing "avoid printed parts when traveling" keep travel moves outside of the vase interior?
No, since it's moving from the interior of the vase to the interior of the vase.
Is that not what Combing "avoid infill" should do?
Although I guess the interior of the vase is not "printed" nor "infill" even if it is part of the model, so perhaps you are correct in both cases.
Indeed, it's not marked as infill because there is no infill.
CuraEngine has no plug-in structure. To fix this you'd need to make modifications to CuraEngine. Of course, if someone is willing to make those changes (after being paid for it or not), we'll gladly consider merging them to mainline Cura too.
Sounds good. Seems like it's a no-go all around. I will mark this closed. Thank you for your time.
I'd prefer to keep this one open, if you don't mind. It's a feature I'd like to see myself too, and you're not the first one to request something like this. We're not rejecting it, but it's not high on the priority.
Just found this from a Google search. Thank you so much for the tip about a "normal model" with no walls, skin, or infill being used as a travel blocker. For my own use case this is sufficient (though not quite ideal), and I doubt I would have thought of it on my own. A couple tips, for anyone who also finds this issue via Google search:
If your design uses other modifier meshes (meshes in "modify settings for overlaps" mode), and a travel blocker overlaps with them (for instance, I often use low-poly modifier meshes that extend far outside the bounds of the model), lines will likely be drawn there as it takes on settings from those meshes. You can avoid this by setting the "Mesh Processing Rank" of the travel blocker higher than the modifier meshes—by default normal models are 0 and modifier meshes are 1, so 2 is certainly high enough, 1 actually might be as well, I don't know if equal-rank meshes affect each other.
Remember that travel that starts or ends within a model cannot possibly avoid that model, so it does not try. So, make sure your travel blocker does not overlap the point at which any of your model lines start (the white "start" dots, but also the equivalent for inner walls and infill, which you'll have to figure out by running through the preview), or travels to and from those points will not respect it. Actually, that's probably not strictly accurate, as I think Cura does attempt to take short, perpendicular paths through a zone it is trying to avoid, but as a first approximation I think it's roughly correct.
Hi 👋, We are cleaning our list of issues to improve our focus. This feature request seems to be older than a year, which is at least three major Cura releases ago. It also received the label Deferred indicating that we did not have time to work on it back then and haven't found time to work on it since.
If this is still something that you think can improve how you and others use Cura, can you please leave a comment? We will have a fresh set of eyes to look at it.
If it has been resolved or don't need it to be improved anymore, you don't have to do anything, and this issue will be automatically closed in 14 days.
Yes, this is still important—I would say it's actually one of my top requests actually. Precise control of travel moves is probably the single most important factor in avoiding stringing, and Cura's travel planning is too erratic to get 100% consistent results without the ability to put my foot down and say "do not travel here, no exceptions". I've been using the workaround with a no-walls-skin-or-infill mesh since I learned about it, and I often find it's not good enough—Cura decides that it either can't or shouldn't/it isn't worth it to go around and just barges through. I want something that's a hard stop, to the point of outright failing the slice if it can't be respected. Ideal would actually be to partially complete the slice, at least up to the previous layer, and indicate that the next layer can't be sliced because of a travel blocker violation—that way I have an idea where to look in my model to correct the problem. Probably also if the actual origin and/or destination of a travel move is within the blocked area, it can take the shortest possible path out, go around, and the shortest possible path back in, but only that, no getting clever.
Is your feature request related to a problem?
Undesirable travel moves reduce print quality, especially when retraction is not perfectly dialed in to eliminate stringing. Even when stringing is minimized, crossing holes or walls can reduce quality. Combing is useful a good deal of the time, but can not always compute the appropriate travel moves.
Describe the solution you'd like
I believe a "Travel Blocker" feature would help to solve this problem. Similar to "Support Blocker". I envision the implementation as using one or more secondary STLs marked with a per model setting of "Travel Blocker". For each layer, this creates a 2D user defined space that travel moves must avoid.
If the end of a print move finds itself within the Travel Blocker region for some reason, it would take the shortest distance out of the travel blocker region and then plan it's travel move. If the start of the next print move is for some reason inside the travel blocker, the travel planner would locate an entry point on the perimeter of the travel blocker that is the shortest path the start of the print move.
Describe alternatives you've considered
The primary alternative is combing. Combing is an automated process and does not always produce the desired results. A user defined Travel Blocker geometry would increase responsiveness to user expectations of travel moves.
Affected users and/or printers
I believe this is a wide spread issue as there is a large number of forum posts and article regarding combing, its settings, and instances of both success and failure with it. For a large number of users reporting failure with automated combing, a user defined Travel Blocker region could improve their experience.
Additional information & file uploads
If deemed an edge case, we are willing to pay (depending on cost) for a developer to implement this as a 3rd party add on if they a contributor to Cura and can eventually roll it in to regular Cura releases.