burtoogle

Thanks for the project file. You simply need to set the support wall line count to 0 to remove the walls that encompass the zig-zag support. I think the difference between your displays is due to the level of OpenGL that is provided on your two machines. To get the fancier display, your computer needs to support OpenGL 4.1 or greater.

Hello @hennysavenije, thanks for the files. Unfortunately, I can't import that profile. Please save the project (File -> Save) and attach the .3mf file. The file you have already attached only contains the model and is not a project file.

Hello @td1, I think what is happening there is that the cylinder is being printed as a thin wall and the Ultimaker Cura implementation of thin walls has a tendency to include little jaggies like you are seeing. I produce my own Cura builds and they use a different implementation of thin wall printing (along with lots of other tweaks and bug fixes) and they handle this particular model better as you can see here. My builds can be installed alongside the Ultimaker releases without conflict. You can find them along with a README that describes what's different here https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

Hi @hennysavenije, please save your project (File -> Save) and attach the .3mf file to this thread so we can check it out. Thanks.

Hello @dextop, can we see a screenshot? Even better if you could attach the cura.log file so we can look for error messages that will give us a hint as to what the problem could be.

Please save the project file (File -> Save) and attach the .3mf file so I can look at the settings. Thanks.

Hello @dejawho, both of those models have problems. If you install the mesh tools from the Cura marketplace you will see these warnings when you load the models.

I'm glad to have helped. My implementation appears to work well a lot of the time but I still regard it as "experimental" and I haven't yet submitted it to UM for consideration. I don't know what Ultimaker's plans are with regard to improving their thin wall and gap filling implementation. Maybe they would look at what I have done or perhaps they would do something else completely new.

Even if you have calibrated your extruder using the typical low speed extrude method, the actual achieved extrusion volume can be reduced quite markedly depending on lots of factors such as nozzle size, material, temperature, extrusion rate, extruder mechanical properties, etc. The bottom line is that for a small nozzle size, the achieved extrusion amount reduces markedly with increased extrusion rate. The printer controller I use (Duet) implements a non-linear extrusion function that can compensate for the reduced extrusion amounts at higher extrusion rates. So then if you ask for 10 mm of filament to be extruded that's what you get across a fairly reasonable range of extrusion rates.

Ha! @tinkergnome, we think alike!

Yes, but the skin lines are being printed on the diagonal so the X coordinates of the line ends will be spaced sqrt(2) * line spacing, e.g. 1.414 * 0.44 = 0.622

No no, the line width in the profile was set to 0.4mm so the difference is weeny (technical term). As for the line spacing, I'm too lazy to work it out from those diagonal lines so let's look at some vertical lines. Here's the end of one of the wall lines... And here's the end of the next wall line... One finishes at an X coordinate of 120.7, the other at X coordinate 121.1. So the line spacing is 0.4. That matches the line width used in the profile. So the gcode confirms that the extrusion rate is correct and the line spacing is correct WRT the profile.

Here's your first layer being printed (100% flow) visualised in a 3rd party gcode viewer. The numbers you see are calculated from the gcode. You can see that the gcode viewer is reporting an extrusion rate of 0.020 mm of filament per mm of line length. Assuming you are using 1.75mm dia filament, that equates to (2.405 * 0.020) = 0.048 mm^3 per mm of line length. The layer height is 0.12 mm and so the line width will be 0.048 / 0.12 = 0.401 mm. That corresponds nicely with the line width in the profile. So it looks like cura has got its sums right here.

Thanks for the files. This is the first layer of your project without any changes by me... This is the first layer after resetting the flow to 100%... The gaps between the lines look smaller with the 100% flow.

Hello @cakeforcat, if you could please save the project file for your example (File -> Save) and attach the .3mf file to this thread, I will check the spacing of the generated lines WRT the layer height and line widths used in the profile. Thanks.

Thanks for the logs. Looking at cura.log, the reported OpenGL version changed on the 14th of August (19.0.2 to 19.0.8) so it's not obvious what happened today and I can see that Aldo's suggestion worked for you. Happy days!

Hi @grizewald, a tale of woe, indeed. Can you please share the cura.log and stderr.log files? Thanks.

The model has problems, here's what cura's mesh tools says about it...

The model does appear to have a solid bottom... Can you please provide a project that includes the profile (File -> Save). Thanks.

It was the value of Minimum Infill Area that was causing that skin not to be printed. It seems to me that setting has completely the wrong name and blurb because the effect it has is to remove areas of skin that have an area smaller than that value and it has nothing to do with infill.

What we really need is the project file that has both the model and the settings. Please do File -> Save (not export) and attach the .3mf file to this thread. Thanks.

Thanks for the project file. The remedy is easy, just enable the bridge settings in the experimental section and the first bridge layer becomes like this... You will find there's a bunch of settings in there for tweaking the bridging behaviour.

Hello @td1, I need to see the project file so I can see the settings you are using. Please do File -> Save (not Export) and attach the resulting .3mf file to this thread. Thanks.

Actually, those travel moves after the NONMESH and before the LAYER comment are part of the previous layer. For a long time now, Cura has added the travel move(s) to the start location of the next layer on the end of the previous layer. Recently, the z change to the new layer height was added so that the nozzle lifts before doing the travel moves. This was requested to reduce the chance of the nozzle hitting something when it travelled to the next layer start point.

Does this problem only occur on Windows systems?