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.