rpress

I noticed this too. The number still works, it's just not displayed. Actually what I would like to see is a profile setting that stores the scaling. This way different materials (profiles) can have a default scaling for shrinkage. 0.3% doesn't seem to me like such a small number; my printer is better than 0.5% accuracy once I adjust for shrinkage. And often I make press fit parts that go with other non-printed objects.

I have designed the TMC262 into a commercial product. It works very well and the configuration abilities are fantastic, but it's more complex with the SPI bus. The stallGuard is a nice feature, the coolStep is not so useful. /256 microstepping is very smooth. I have also played with the TMC2100. As mentioned the stealthChop is not good with high accelerations, I tried higher voltages but haven't tried an external clock. With small low inductance motors it's pretty noisy in spreadCycle. This has good current control for accurate microstepping. The microPlyer is perhaps the best feature. It's as smooth as the TMC262 without the high step rates and works well with the step rate limits of the Arduino boards. And after all the accuracy of a step motor is no better than /16.

Yes it's not very clear what the skin surface is. Skin is only the flat infill on a horizontal exposed surface. So for your die, it will comb on the perimeters (the sides and holes) but not on the flat parts in between.

Maybe the RetractWhileCombing plugin will give you z hop for just the bottom. Or it could be modified, etc. But for the perimiters next to skins this is much more complicated. And I suspect it has limited appeal for others; I have not found combing to affect my perimeters, but my stringing is nothing like yours.

Retracts for everything on the bottom are doable with small changes. But for the top it's a question of what is the "top"? For a square part it's easy, the top is the last layer, but what I think you mean is not "top" but any exposed flat surface. This is a skin. But for perimeters it's hard to decide when is the right time to modify behavior.

I'm not sure I understand, so you want combing off for perimeters (retracts) but you want combing on for perimeters to eliminate defects? When you say outer walls you mean perimeters yes? Yes, of course "No Skin" with no z-hop will still scratch, but not ooze. But this "No Skin" setting will do a standard retract, including z-hop. So you already have z-hop on skin. Am I missing something here too? You want z-hop without retract on skin?

The problem is that the "skin" surface is only the flat part in the middle, not the perimeters. The "No Skin" feature is meant not for the beginning of printing the layer, but meant so that after it prints the skin it won't ooze or scratch on it moving to the next point. I suppose it could be made to add retracts on the bottom layer for the perimeters but at some point you have to ask yourself why use combing at all? You could also try increasing your travel speed.

Here is the Simplify plugin. This reduces the number of short moves to keep from overloading the printer motherboard and causing blobbing, etc. https://github.com/presslab-us/Cura-Plugins/blob/master/Simplify.py

Thanks @Daid for accepting the pull request. The corresponding one for Cura is here: https://github.com/daid/Cura/pull/1087

I pushed the changes to my branch.

Yes you will reopen it (and contribute to discussion/possibly approve) or yes I am wasting my time? :mrgreen:

If a pull request is closed by a maintainer, the contributor cannot reopen it. I think this is leading to some confusion here when you keep saying I can reopen it. The option you show must exist because the request was closed by the contributor and not the maintainer. So, if I make this "turn combing off for skin" a configurable option, would you reopen the pull request? Or would I be wasting my time? There is still no reply on the pull request comment page.

Bad example, and you are missing the point. It's not the rejection, it's the unwillingness to discuss. I have contributed to the Linux kernel. The difference is that they are more than willing to discuss things (maybe even too much) and usually suggest an alternative to the things they don't like. No need to beat this horse any more. But maybe in the future you will be more open to discussing pull requests and not close them immediately. Or maybe not, it's up to you.

Yes, you can reopen it, but I can not. How do we know what you like and don't like if you don't have time to discuss things? My comment from 2 days ago is still unanswered on the pull request. Why should we spend our time making patches only to offer them up to the "gods" and hope that it appeases them? My time is much more valuable than that. Of course you have every right to do what you want with your project. I just want to make this clear so others don't waste their time. In fairness to other developers you might want to put a comment on your GitHub page to the effect "I may or may not like your pull request, so submit them at your own risk." :mrgreen:

It would be easy to add a commit to the pull request adding a way to configure it, if it weren't already closed. I would just push the changes to my branch and it would show up in the pull request. But even then I suspect this isn't the real issue.

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.

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.

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.

I submitted a pull request here that will help with the scarring. https://github.com/Ultimaker/CuraEngine/pull/153

The warts look to me like the classical blobbing problem caused by pressure increase/decrease in the extruder. For example, Sailfish firmware has the JKN algorithm to compensate for this: http://www.makerbot.com/sailfish/tuning/ Now what you can do is make sure the infill and perimeter speeds are the same. If you can, increase the acceleration for travel moves. The workaround in Slic3r of changing the perimeter order is sometimes effective as you see but it's sort of masking the real problem. About the top of the sphere there are lots of options to help with that. You can increase the minimal layer time, make sure max fan speed is 100%, and decrease the minimum speed. You can also print two objects at the same time, thereby giving more time to cool.

Yes, it looks like blobbing is due to overloading the printer motherboard. If yours shows "Buf" on the LCD display this would go down to zero when the blobbing occurs. If the STL has lots of polygons the resulting gcode can have lots of moves. This causes problems on the less powerful motherboards like those based on mega2560. Add in the delta calculations and this is too much. I have made a plugin that trims the gcode, reducing the unnecessary moves. In a few days I can share this if you want to try it.

This problem should be fixed now with my patch. http://umforum.ultimaker.com/index.php?/topic/8650-doubling-up-on-layers-bad-for-cooling/

Thanks Daid! @IRobertI, I think what Daid is saying is that the patch reduces the interlayer dependence, which will make multi-threading easier in the future, and that's a good thing.

My pull request here: https://github.com/Ultimaker/CuraEngine/pull/150

This doubling up problem is somewhat unintentional I think, it's just the path optimizer not caring about the layer change. I've come up with a patch to solve this problem, testing it now.