burtoogle

Thanks for that, I'll take a look later. In the meantime, I printed your model on a Sovol SV01 (budget printer) using 0.2 layers and 0.4 nozzle, 15% gyroid infill. Took 31 mins and came out like this... Look at the speeds, here... The walls around the holes are printed SSLLOOWW.. How to get that? One other thing. I am printing using Octoprint and in there I am specifying a flow rate of 108%. I could have specified it in the slicer but, it makes no difference. Why? Well, when I calibrated my extruder at a typical extrusion rate, it under-extruded by around 8%. The point is that you have to calibrate your extruder using a realistic feedrate and temperature for the material in use. It's not good calibrating your extruder without actually pumping plastic at a typical rate. Some firmwares (e.g. RepRap) can do non-linear extrusion which is nice but, otherwise, you just have to pick a suitable flow rate for the target extrusion rate. Hope this helps, will take a look at your project later....

Thanks for the file but, unfortunately, it wasn't a project file. Please do File->Save (not Export). Thanks.

I'm reasonably acquainted with the Cura innards and I don't believe that to be the case. In the situations where I have seen under-extrusion in my own prints the problem has always been due to some bad combination of settings that resort in too much demand being placed on the extruder.

Hello @Arak0n, could you please provide the project file for that print? Do File->Save and attach the .3mf file to this thread. Thanks.

Personally, I only ever use the middle slicing tolerance as I expect (hope) the slicer to create a gcode file that is dimensionally faithful WRT the model. Of course, the printer may not actually print what I want (dimensionally) because 3d printers that squirt plastic never do. So then I may need to adjust my model just like designers/manufacturers have been doing for hundreds of years to compensate for dimensional errors that are introduced by whatever material and process has been used. Nothing new about that.

The distance used in the max comb distance with no retract feature is the combed distance from the point where the travel starts to the point where the travel ends, what happens before and after those points (infill, walls, skin, etc.) is not a consideration.

https://github.com/Ultimaker/Cura/issues Incidentally, have you tried the fan speed override setting? That let's you specify a different fan speed for the skin over support. So for example, when using PETG, it helps to specify 100% fan when printing skins over support to get better separation. Also, my Cura builds already feature a setting for printing the first skin over support using bridging settings. You can find my Cura builds at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0 Please read the README.md file there before using.

Fair enough. I guess there's always going to be conflicts of this nature when you have an application (or anything) that is targeted at a broad spectrum of users; engineers to artists, etc. I'm afraid I can only see the world through my engineer eyes so hence my confusion here.

The idea behind that setting is to give the user the option of printing the first skin above sparse infill using the bridge settings. Set that to a value greater than the infill density and the skin above the infill will have bridge settings applied. Here's your sample project doing just that...

Perhaps, then, the bridge sparse infill max density setting could be useful?

Thanks for the file. Unfortunately, I can't reproduce what you see because my Cura is different to UM Cura in some ways including the handling of bridged skins. What happens if you set bridge skin support threshold to less than 100% ?

I have found that because PETG is so runny, combing is not appropriate for a lot of models. If you do use combing with PETG, use a very small max comb distance with no retract. Certainly no more than 10. The combing mode (all, not in skin, within infill) does not influence which travel moves will use combing, only the routing, i.e. not in skin will route along walls and over infill but (when possible) not over skin areas. You would be forgiven for thinking that within infill mode would route only within infill but, in fact, it will also route across areas of skin which is why I created the not in skin mode to stop combing trashing skin.

Then increase the distance. The best distance to use depends on many factors so you need to do some experimentation.

Please provide the project file, do File -> Save and attach the .3mf file, thanks.

I find their choice of words here very confusing. The underlying operation when exclusive mode is selected is that the polygons that define the outline of each layer are calculated as the intersection of a given layer and the layer above. Intersection is like a logical AND, you need both parts to be present (true) for there to be an output, why didn't they call it "intersection" or "and" rather than "exclusive"? Similarly, the underlying operation when inclusive mode is selected is that each layer's polygons are made by doing a union of the current layer and the layer above. Yes, you guessed it, union is like logical OR. So why didn't they call it "union" or "or" rather than "inclusive"? Perhaps the marketing people thought that using engineering words would be too scary for the gentle user.

Inspired by this thread, I have today submitted 2 PRs to UM that restore those missing layers... https://github.com/Ultimaker/CuraEngine/pull/1306 https://github.com/Ultimaker/CuraEngine/pull/1307 The current behaviour may be unintended (due to bugs) or intended (due to their intentions), we shall see.

With regard to accuracy in the horizontal versus layer height, the problem is really akin to digital signal processing in that if the incoming signal contains frequencies that are higher than (1/2) the sampling frequency then the digitisation will be subject to aliasing errors. The analogy suggests that if the model's contour varies with z values with a greater frequency than twice the layer height then information is going to be lost when the model is sliced.

Late arrival to this topic. Could you please attach the project file for this print so I can take a look, thanks.

Sounds good, and are you still getting decent adhesion and minimal corner warping?

It was me, you're very welcome! I use 0.1mm for PETG and don't normally have any problem removing the brim. As I mentioned above, one thing that really helps with avoiding corners lifting is to use a high build plate temp. For me, going from 55 to 75 degrees reduced the corner warping considerably.

https://support.ultimaker.com/hc/en-us/articles/360012512340-Shell-settings

If you use a small gap (i.e. 0.1mm) you will find that the brim does still mostly touch the model but is easier to remove. Surprisingly, it does still help reduce the model's corners curling even when there is a visible gap between the inside of the prim and the model perimeter. This is the model that inspired the brim gap feature. Printed using PLA, I noticed that the corners on the side tended to lift from the build plate unless I used a brim but the brim was hard to remove without looking ugly so I tried using a wide skirt with a very small gap and it still helped reduce the curling of the corners. I am guessing that a brim helps reduce curling by reducing the temperature change between the layers at the edge of the model. I have also noticed when printing PETG that corner warping is greatly reduced when the bed temp is increased so for that material using a high bed temp (at least 75 deg) and a brim with gap gives me little warping at the corners.

Initial bottom layers specifies the number of skin layers at the very bottom of the print, i.e. those layers that are touching the buildplate (or raft). Bottom layers specifies the number of skin layers that are immediately above air (or support). Top layers specifies the number of skin layers that have air (or support) immediately above them. Hope this helps.

Try setting the brim gap to 0.1 or thereabouts.

You want to set Z overrides X/Y.