-
Posts
1,529 -
Joined
-
Last visited
-
Days Won
19
Content Type
Forums
Events
3D Prints
Posts posted by burtoogle
-
-
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.
-
8 hours ago, 64Pacific said:
I am glad that I was pointed in the direction of this post, it has helped out a lot with a current project. I am wondering if the great developments made by @burtoogle in this branch of Cura will be implemented in a future version of the main trunk of the software by the Ultimaker team?
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!
-
1
-
-
32 minutes ago, cakeforcat said:
and by looking at the difference in the X direction it comes to a move of 0.623mm which is larger than the line width of 0.44 you can see in my screenshot(and even more than the 0.4 you say is in the profile I sent). Is it intentional or am I reading it incorrectly?
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
-
17 minutes ago, cakeforcat said:
Yeah, apart from 0.401mm not being 0.44 I have set(But I' guess you mean it's not a big difference which I agree),
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.
-
-
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.
-
-
-
-
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.
-
-
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?
BUG:Support Zigzag doesn't produce zigzag but lines
in UltiMaker Cura
Posted
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.