Turning combing off on bottom and top layers?

[aviphysics 9]

I love combing as much as anyone, but I would like to know if there is a way to force retractions on the bottom and top layers, so you don't get those visible combing scars.

 

[Dim3nsioneer 377]

How did you survive http://wiki.ultimaker.com/CuraPlugin:_RetractWhileCombing so far... ?

 

[phil-t 0]

How did you survive without it so far... ?

Wow!!!

I have been looking for this for a while now, all those nice glass smooth first layes marred by the combing will be a thing of the past!!!!

 

[forerunnert 0]

Wow this is great! How did I survive indeed...

 

Now for a 'apply plugin for top and bottom layer'-tickbox and the plugin would be perfect ;-)

 

[jweaver 1]

I am sorry to ask this, but could someone explain what combing is, and perhaps show some photos of the benefits/disadvantage.

I understand combing (atleast I think I do).. Is it where the head will avoid going over spaces in the print...

But why does this cause a problem? I assume this is because you get 'stringing' in the void? But why is this a problem.. That can be easily removed.

Am I right in thinking that the 'scaring' is caused by combing, as the head travels across previously printeed parts and thats is harder to fix.

I think I understand the basics of this, but struggle to understand the "real world impact"

Can anyone shed any light on this?

Jon

 

[IRobertI 429]

You got it right. You think stringing isn't a problem, that's a very rare opinion indeed Most people hate stringing and combing is one way to try and combat it.

 

[IRobertI 429]

Oh, and I should mention. We haven't always had retractions that work as well as they do today. You should've seen the early days...

 

[jweaver 1]

You got it right. You think stringing isn't a problem, that's a very rare opinion indeed Most people hate stringing and combing is one way to try and combat it.

Interesting.. So the stringing we are talking about, would be in the open (and visible) spaces in a model, rather than the inside where the "infill" goes?

When ever I have seen 'stringing' I have found that a sharp knife just flicks it off.. But perhaps I havn't seen it yet..

So the idea is that Combing is good, to stop stringing.. But bad in terms of surface quality.

This is why people want combing off on the outside/top/bottom of a print.. But on, for the rest of it?

 

[Dim3nsioneer 377]

Wow this is great! How did I survive indeed...

Now for a 'apply plugin for top and bottom layer'-tickbox and the plugin would be perfect ;-)

Would the first and the last layer be close enough?

[aviphysics 9]

Meant scarring.

The issue with the first and last layer is that the path left by combing leaves a visible line on your model. It isn't something you can just trim off.

[forerunnert 0]

Would the first and the last layer be close enough?

 

Actually after thinking about it a little more I would want the plugin enabled for any horizontal surface that is visible after printing completes. I do realize this probably is impossible with the current slicing engine.

I think when I enable this plugin I would always want it to be enabled for the first layer automatically: this doesn't need to be configurable.

The same is probably true for the top layer: it can be always applied. Although this would not make sense for prints without a horizontal surface as top layer, it wouldn't hurt them either.

What do you think?

 

[Dim3nsioneer 377]

Automatic recognition of horizontal surfaces is beyond the reach of a plugin right now. As you mentioned, not even the CuraEngine itself can do that.

However, an override checkbox for selecting the first and the last layer (and ignoring whatever layer height or numbers is selected) is possible. If you want to activate it for a layer range in addition, you would have to run it twice.

I recommend you watch http://umforum.ultimaker.com/index.php?/topic/4270-new-versions-of-cura-plugins-tweakatz-and-retractwhilecombing/ for the upcoming days/weeks.

 

[aviphysics 9]

Cura's slicer must have some sort of awareness of top surfaces, otherwise it wouldn't be able to do top thickness.

 

[Dim3nsioneer 377]

Cura's slicer must have some sort of awareness of top surfaces, otherwise it wouldn't be able to do top thickness.

 

True... :oops:

Without knowing I guess it does it on the level of the layer polygons not of the print path. As plugins are postprocessors they do not have this possibility.

 

[aviphysics 9]

The way I imagine doing it would be to draw each layer by G1 path and line width as a bitmap (or something like that. I think "rasterize" would be the technical term.) You could then draw each combing move along the layer above it and compare to the same image without the combing move. Any travels that alter the white space would be transformed into retracts.

You could have a setting to let the user specify the amount of white space a combing move is allowed to alter before it gets turned into a retract. This setting would also be used to determine the resolution of the rasterized images.

I don't think that looks too hard to code, but I bet it would take annoyingly long to process. I believe there are even already python scripts to do that sort of rasterisation. Would probably just do one layer at a time, so you don't need to store all those images.

 

[Dim3nsioneer 377]

Nice idea. The current support in Cura works the same way (yes, the one UM people say it sucks).

However, I think combing might be a feature that sees some changes with the Pink Unicorn edition. The fact that the new Cura is based on pluggable unicorn (hey, the names are not my invention... :mrgreen: ) opens new possibilities for additional functionalities. However, this means, that it makes not much sense to invest too much effort into that topic at the moment.

 

[rpress 1]

I submitted a pull request here that will help with the scarring.

https://github.com/Ultimaker/CuraEngine/pull/153

 

[aviphysics 9]

I submitted a pull request here that will help with the scarring.

https://github.com/Ultimaker/CuraEngine/pull/153

Thanks...

I really should take a class in object oriented programming. I always get confused when those arrows and periods start getting thrown around.

 

[rpress 1]

Ha ha, the pull request was closed already with no discussion. Well I guess we will see what happens, there is a chance an alternate solution could be found.

 

[nallath 569]

The arrows and periods are c++ specific, not OO specific.

 

[aviphysics 9]

The arrows and periods are c++ specific, not OO specific.

 

Just speaking to the general method of organisation. I have a vague idea of what the arrows and periods do, but just need to build a firmer foundation for working with objects.

Nearly all my experience until recently was doing pretty strait forward computational code or pic PIC Assembly. Just didn't have any need for anything fancier. I have been wanting to branch out, but have been feeling too lazy.

 

[aviphysics 9]

Ha ha, the pull request was closed already with no discussion. Well I guess we will see what happens, there is a chance an alternate solution could be found.

 

Well that's kind of lame that you weren't given a reason. Had you already tested the code?

 

[rpress 1]

Well I should be clear, there were reasons given but no discussion. Ideally a pull request would have some back and forth discussion to see if it is the right thing, and modifications are possible so it's not necessary to close it if something somewhat different is desired. And if an amicable solution can not be found then eventually closing it is the thing to do. But closing the pull request immediately basically says, "No!"

Yes I tested the code with a few prints and it works fine. But I agree the ultimate implementation might be different than the one I came up with, this is why discussion is good.

 

[Daid 278]

Well that's kind of lame that you weren't given a reason. Had you already tested the code?

 

There was a reason given. Just no discussion.

I'm trying to keep it a bit clean on pull requests and issues (not that it's working so far), and that means closing stuff as soon as it's the issuers turn to do something again. And when I'm not going to merge something in it's current form, I close the pull request. (The issuer can re-open it, so it's not something final)

(Right now I'm juggling a lot of projects, so my answers are usually short and quick)

 

[rpress 1]

As far as I know, there is no way for me to re-open a pull request, I would have to make a new one. Which is not that efficient and clutters things up.

So now that I know where things stand, if there aren't the resources to discuss improvements then I shouldn't be wasting my time either. Let us know when Ultimaker can dedicate more resources to the open source community.