5.3.0 strange artifacts in skin (jagged paths on curved surfaces)
discip opened this issue · 101 comments
Application Version
5.3.0/1
Platform
Manjaro
Printer
unrelated
Reproduction steps
Open the attached 3mf and slice it with both 5.2.2 & 5.3.0/1, compare the result by looking for almost _ microscopic_ extra paths in the skin, which do break continuity of curved paths.
Actual results
There are artifacts in the skin when sliced with the latest release.
Expected results
No artifacts in the skin should occur, as in the previous release.
Checklist of files to include
- Project file
Additional information & file uploads
project file
Please enlarge the screenshots to be able to observe the irregularities best.
Also: Note the bumps in the marked areas on the slopes left and right.
Addendum:
After inspecting the screenshots closer, I noticed that the paths in general in 5.3.0/1 are quite jagged compared to those of 5.2.2, the latter being much smoother (Particularly noticeable in the front area of the large circles!).
overview
5.2.2
5.3.0
artifact 1
5.2.2
5.3.0
artifact 2
5.2.2
5.3.0
artifact 3
5.2.2
5.3.0
Thanks for the report and the file.
Here is the model in MS 3D Builder. You can see that it is reporting that there are errors in the model.
I used Cura 5.3beta and created a gcode from your project and read the file into AutoCad. Here is that same area.
I measured the error and for both the larger marks it is 0.15mm. They were the only glitches I see in the gcode.
Here is a view in Mesh Mixer. You can see that the triangle density of the model varies widely from area to area. This is not the smooth model that it appears to be at first glance.
In regards to this bug report:
The model has some definite issues and it's possible that 5.2.2 is simply more tolerant of model problems than 5.3 is. The slice I did with 5.2.2 does not show those hiccups that are in the 5.3.1beta slice.
The Cura team will take a look
@GregValiant
Thank you for the investigation.
It may be that the object has issues and most likely this is the cause for the dimples, but as mentioned in the first post addendum, unfortunately that's not all!
There are also these noticeable jagged paths on curved surfaces.
The same strange jagged paths also appear on a smooth surface of a simple cylinder, while there is nothing of the sort in 5.2.2.
Overall, the surface in 5.2.2 is much smoother compared to the same surface in 5.3.0.
Please enlarge the images for a better view.
There is a very short extra path inserted between 2 consecutive segments of a curved path:
You can see the difference particularly well on the left side.
I also saw these distinct jagged paths on the surface when slicing with version 5.3 ,
Does anyone solve this problem
Im having the exact same issue with 5.3. Ive been racking my head for days on this one. Smooth curved surfaces with dimples and what looks like extra seams forming vertically up the print.
@GregValiant
@MariMakes
@jellespijker
Is anyone on this already?
I'm seeing this as well. I pasted my comments below from #14943, since this thread has more activity and it seems to be a duplicate issue.
I'm seeing the exact same thing. This is a regression in 5.3.0 - the problem does not appear in 5.2.2. It seems to happen when a wall goes from straight to large radius convex curve. There is a weird extra move in the gcode output. It's very hard to see in Cura's preview, but is quite clear if the gcode is viewed in the PrusaSlicer viewer.
Here is an example:
In Cura's preview, you can see a slight discontinuity:
The resulting print:
The same STL sliced with Cura 5.2.2 does not have these artifacts. Prusa Slicer also does not have this issue. Note that this is not the Z seam - that's in a different location. This artifact appears in 4 places on this model - every location where a straight wall connects to a large radius convex curve. It does not appear on the small radius curves (small fillets) or on the concave curves.
Here is the STL I used and resulting gcode:
STL File
5.3.0 gcode
5.2.2 gcode
Both gcode samples were sliced with the Cura default standard 0.2mm profile.
can anyone from the developers confirm the problem? or is that not a problem?
@qwerty8224
As stated by all the commenters here, this is definitely a problem!
I think what you meant, is the question about this issue being addressed yet. 😊
@qwerty8224 Как заявили все комментаторы здесь, это определенно проблема!
Я думаю, что вы имели в виду, что вопрос об этой проблеме еще не решен.😊
they didn’t confirm the problem for me, they sent me to read YouTube and look for the cause in the printer 🤷 му ticket #14970
@qwerty8224
According to your description, including the solution: "Increase the resolution", your issue is not the same as this one.
Since applying your solution doesn't fix the problem I'm referring to here.
@MariMakes the discontinuity that @darrellenns expirienced is probably fixed in main for 5.4 with this commit Ultimaker/CuraEngine@21e5e8f Nevermind, that commit is already in 5.3 as well
Same issue here with curved surface models. Seems like the slicer is having a numerical precision issue when planning the path for curved surfaces.
There does seem to be something profile-related going on here. I did the following as a test:
- Remove all Cura settings files
- Launch Cura 5.3.0
- In the first run dialogs, configure Cura for a Creality Ender 3 Pro
- Load same STL from my earlier post and rotate it 90 degrees for correct print orientation
- Select the Cura provided 0.2mm profile
- Slice the model and look in Cura's internal preview for the glitch
If I do those steps exactly, the glitch is there. As I mentioned before, spotting it in Cura's preview is a little tricky but it is visible. It's more obvious if you select the extruder preview control at the bottom and move one step at a time using the arrow keys on the keyboard.
I then tried the exact same steps, but using a different printer model in the first run dialog. I tried Prusa MK3, Ultimaker S5, and "Custom FFF". None of these exhibited the glitch. Additionally, I tried changing the machine/extruder settings for the Custom FFF to match the Ender 3 Pro settings. It still did not exhibit the glitch. I then tried a few different Creality printers, and all of them showed the glitch.
After some further experimentation, I found the combination of settings that results in this glitch:
- Mesh Fixes -> Maximum Resolution: 0.25
- Walls -> Print Thin Walls: disabled
These are the default settings for Creality machines. In the "Custom FFF" machine, the defaults were resolution 0.5 and thin walls enabled.
So it seems there is a bug that is triggered by disabling "Print Thin Walls", but the glitch is filtered out if "Maximum Resolution" is set too high for the glitch to show up in the result.
As a workaround, you can edit creality_base.def.json and remove the line with "fill_outline_gaps". This enables "Print Thin Walls" on all profiles for Creality machines, unless you have explicitly disabled it in your custom profile. Of course, creality_base.def.json will be replaced next time you upgrade Cura, but hopefully the bug will be fixed in the next release anyway.
Not sure this works for me - I have a custom profile and I have thin walls enabled and the issue persists. It moves if I change the mesh resolution (I.e: the lines go to another place in the model) but doesn’t disappear.
Hey All,
We've added a ticket to the backlog with the intent to improve this.
For internal reference CURA-10500
Thanks for the report! 👍
As a workaround, you can edit creality_base.def.json and remove the line with "fill_outline_gaps". This enables "Print Thin Walls" on all profiles for Creality machines, unless you have explicitly disabled it in your custom profile. Of course, creality_base.def.json will be replaced next time you upgrade Cura, but hopefully the bug will be fixed in the next release anyway.
Thanks it works when i enable the "Print Thin Walls" function for my Cr-10, standard PETG and Cr-10 Printer Settings.
I've been having this issue. It seems to be related to infill somehow. I accidentally printed with 0% and the print came out perfectly. when I turned infill back on, the artifacts / warts came back.
Same issue here with 5.3.1 (5.2.2 not a problem).
I did looked into the gcode generated by 5.3.1 and it kinda duplicates some of the movements; X,Y have almost identical positions.
See some pictures bellow.
I've been having this issue. It seems to be related to infill somehow. I accidentally printed with 0% and the print came out perfectly. when I turned infill back on, the artifacts / warts came back.
Unfortunately I can't confirm that.
Tried what you suggested but the artifacts remained.
but I've currently rolled back to 5.2.2
That's exactly what I did! 😊
But exclusively for testing purposes I also left 5.3.1 installed!
Project file for stuttering zits on round surface....referenced above.
5.3 stuttering zits.3mf.zip
Same here, since Cura5.3.1 I got ugly vertical blobs on my outer wall as well.
I tried the print after slicing on two diffrent sidewinder x2, and two Fl Sun V400.
those 4 printer`s are diffrent in age, 1 X2 and 1 V400 are just 1 week old, and they work absolutly precise.
I tested it to be able to exclude hardware problems. I also tested it with Cura 5.2.2, and there the Problem didnt show up
I also seem to be experiencing this issue, notice that when printing the toolhead would appear to stutter while going across a curve, but it clearly wasn't a hardware issue as it was retracting during those stutters as well. It ended up leaving artifacts in the surface from the drop in speed/flowrate. Using Cura 5.3.1.
Yes, there is an obvious problem, I wrote about it from the release of version 5.3 already 5.3.1, but the problem was not solved (((can 5.3.2 be released? Well, it’s not possible to work in a broken version of the program (((
Hey @qwerty8224,
We really want to fix this for the upcoming 5.4, A few of our developers have found the root cause, but the solution will require some time, so I can't make any promises. Apparently, micro-segments have been a problem for a while but with this release, they are aligning and it's become more obvious.
Bugs that impact the print quality are taken seriously, so we hope to be able to update you soon.
Stuttering still present in 5.4 Beta
Stuttering.zip
@MariMakes Hi mari,
please see above
@casperlamboo
Unfortunately the claim of having solved this issue with 5.4.0-beta1 is not true. 😞
The behavior is nearly unchanged.
Please correct this information in the release description.
Is this something thats expected to be fixed in 5.4.0 still? Or has this been postphoned to the next minor or major?
A quick release hotfix for 5.4.1 would be nice. This issue is horrendous.
@discip, I'm sorry to hear that you still have this problem. I would like to ask you to share a bit more than your current statement: "nearly unchanged". We did work on this problem and we tried our best to limit the small path deviations that could (and can) still happen during slicing. Did you come to this conclusion with actual prints or by looking at the preview GCode?
The artifacts that occurred in 5.3 were caused by either multiple tiny paths placed after each other, which could cause a buffer underrun in some printers. Simply put, the printer couldn't handle a burst of GCode commands in a timely manner, or by tiny paths with a sudden deviation of the angle compared to an ideal fluid motion line.
During slicing, the generated polygons, and at a later point in time, the generated toolpaths are simplified. This will filter out tiny line segments as much as possible while still trying to hold true to the shape of the model and limiting the inadvertent generation of other print artifacts, such as banding. Banding is a slight shift of a longer path in position and orientation compared to the shape of the path in the previous or next layer.
The simplification looks at the following conditions:
- If the deviation from a point is less than x amount from the distance perpendicular to the base of a line drawn from the previous point and the next point, then consider this point for removal. This is known as the maximum deviation in the front-end.
- If the length of a line from the previous point to the current point is less than 5 microns, remove it always.
- If the length of a line from the previous point to the current point is less than the maximum resolution, consider that point for removal.
- If the point is to be removed, and it will affect the area of the triangle between the previous, current, and next point by deviating more than x amount, then don't remove the point. Since this will result in banding problems, which are even more visible than blobs and also impact the dimensional accuracy negatively.
The root cause of this problem lies in the fact that the simplification of our polygons and toolpaths is over-constrained because of the above-mentioned conditions. But we also know from experience that these conditions are needed. The simplification algorithm can therefore never find an optimal solution but will find a solution within an allowable range.
We worked on improving this problem in at least two sprints, with two developers, and we managed to improve it compared to what it was in 5.3. We see a drop in the violations of sequential GCodes compared to 5.3.1, as shown in the graph(s) below. Here we analyze the violations for the buffer underruns. Keep in mind that a single small line segment in itself might not be an actual problem, but a number of them might be.
This next graph shows that there are still a lot of violations that occur when looking purely at the theoretical data. This is mostly due to this particular model, which consists of a number of spikes where the diameter of each spike goes towards a diameter of 0.4 mm. Here you see that in order to hold true to the shape of the model, we simply can't create lines long enough such that we don't have any violations.
We keep on working on this problem, but unfortunately, the solution isn't as clear-cut as we want it to be and very complex in its nature. Mostly because simply analyzing the print in something like the gcodeanalyzer or in the preview view of Cura will only tell you that there is a small segment somewhere. It doesn't show if that small segment is actually a problem.
That will only be visible in actual prints, and for this, we could really use your help.
Because our UltiMaker printers don't show these defects.
If the problem still occurs, I would like to ask you guys to do some actual prints where you try out different resolution and deviation settings, to see if these settings are actually sensible for your printers.
And maybe help figure out which simplification conditions should weigh more in the simplification algorithm. Keep in mind that you can't have it all 😭. Believe me when I say that I'm as frustrated by this as you guys.
Please share the project files and photos of the print that still show the problem so that we can use these for further analysis.
@Turbine1991 and @L0laapk3, we're trying to improve this even further in the beta period. But since it isn't a regression compared to 5.3, we will most likely continue with the stable release for 5.4 without further improvement. That doesn't mean that we will stop working on this problem, and if we manage to improve it a lot, then it will certainly warrant a patch release 5.4.1.
Please see my attached files above.
Is the graph for infill the same as for outer and inner walls? I would think infill would not be the most relevant part of the problem. We get zits on outer walls from the stuttering. Maybe they are exactly the same result...I don't know.
The stutters manifest as zits so they are very easy to see through a simple print, I find the head of matterhackes Phil-A-ment exposes them perfectly.
I understand you have constraints, but Smartavionics master branch, Prusa, Orca etc. Don't have this problem. Is this the hill Cura dies on? It is a major make or break bug, along with a few others that have existed since 5.0 came out. New features really do feel frivolous while such major issues have gone unaddressed for an extended period of time.
ps...I do appreciate your time and efforts. I understand I'm getting Cura free and the whole community has benefited from Curas advancements. But currently Cura really is riddled with significant bugs. Imagine the oceans of people frustrated with their printers causing zits. How many of us will have the tools to understand what is happening. How many more will waste hours trying to solve a problem they cant fix.
@PhilBaz did you do an actual comparison print in 5.4.0-beta.1 with that project and could you send over the photos such that we can map the actual print defects with the generated gcode.
I'm also curious what happens if you play with deviation and resolution settings. These settings need to be fine tuned for a specific printer and we can only do that for UltiMaker printers, since we don't have access to other third-party printers and are dependent on the settings provided by our community members.
I will attach the graphs for the violations in the walls tomorrow morning first thing. accidentally copied the wrong ones, in the reply.
@jellespijker Hi, thank you for your explenation and efforts. They are much appreciated :)
Just to be clear, I did not yet try the 5.4.0 beta1, I was going off of comments of others and probing for a timeline. I can try the beta if it is still useful.
I switched from merlin to klipper precisely because it is much better at executing the instructions, which obviously means that these kind of artifacts are a much bigger deal. My 5.3 prints were awful but I've been happy with 5.2 so far.
Thank you for the extensive explanation. 👍🏻
I do somewhat get what you explained.
However, this issue was previously not present (5.2.2).
- You're right, I haven't printed with the latest beta yet.
But judging by the results visible in the slicer when comparing 5.2.2 and 5.4.0, there are big differences.
Yes, actual prints from that exact project file and Gcode. Also compared with Smartavionics branch, and of course the whole lot just went out to the trash. Ill print the beta again.
You can see the resolution settings in the file. The same i use with SA branch. If you have a suggestion I can try it.
No worries about the graphs, was just wondering which one you were using for your findings as infill wouldn't be as useful as wall.
Also, I'm running all this code on a klipper machine with tons of processing headroom if that makes any difference. No 8bit buffer here.
@jellespijker Ps... you can also compare with a very similar file I attached in my may 5th comment above, if that's helpful.... its 5.3 with similar issue.
The artifacts that occurred in 5.3 were caused by either multiple tiny paths placed after each other, which could cause a buffer underrun in some printers. Simply put, the printer couldn't handle a burst of GCode commands in a timely manner, or by tiny paths with a sudden deviation of the angle compared to an ideal fluid motion line.
In the cases I observed and reported in this thread, it was definitely a "tiny paths with a sudden deviation of the angle" rather than a buffer underrun. It's a single line of gcode with a sudden angle change.
Do you have any idea why enabling "print thin walls" works around the problem? Does disabling print thin walls do something to do the path simplification algorithm that is introducing the problem?
I tried a benchy in 5.4.0-beta.1 it still causes the zits and blobs. Please check #15813 I have posted some pictures there.
Thank you guys for your input, I will take it all into account when working on this. I might ping you guys on occasion during when I got it in a state that it needs some actual printing. Otherwise I'm working completely blind, since our printers Don't show this behaviour. I also can't make any promises that this will make it for the stable release, but if I finish after the stable I believe it will warrant a patch release.
Devs for internal reference see: CURA-10724
I'm also curious if you guys are running Klipper or Marlin.
Thank you guys for your input, I will take it all into account when working on this. I might ping you guys on occasion during when I got it in a state that it needs some actual printing. Otherwise I'm working completely blind, since our printers Don't show this behaviour. I also can't make any promises that this will make it for the stable release, but if I finish after the stable I believe it will warrant a patch release.
Devs for internal reference see: CURA-10724
I'm also curious if you guys are running Klipper or Marlin.
I was under the impression that this issue was mostly for klipper, or that may have been one of the issues closed in favor of this one :p
I can tell you that when I shared my print with zits in the klipper discord, someone immediately diagnosed it correctly as me having used cura 5.3, as far as I can tell it is the common consensus there that cura starting at 5.3 generates unusable gcode for firmware that actually respects the generated paths to a high degree of accuracy (aka klipper)
I'm also curious if you guys are running Klipper or Marlin.
I am running klipper, but I have tried this in marlin(+Cura 5.3.1), I see a proper Z seam in marlin that can be hidden
I use Klipper and Marlin on an Elegoo Neptune 3 Pro printer, and I'm happy to know it's a slicer bug and not a printer or filament problem, because I couldn't understand why my "curvy" prints were full of zits/blobs when using Klipper (no problem when I reinstall Marlin firmware with the same gcode print file).
I started to suspect it was a slicer problem when I realized that the blobs/zits are always located at the same place when I printed the same 3D model at different speeds and settings for tests.
I currently use Ultimaker Cura 5.3.1, didn't try 5.2 yet.
Just adding my two cents here: I'm also experiencing this with recent versions of Cura. The latest working version I've tried was 5.2.2, and the first time I saw this issue was after updating to 5.3.1 .
I took some slow-motion footage of my printer in action, since I saw blobs/zits appearing relatively consistently along one side of print (not the seam), to confirm what I thought I was seeing. I was able to confirm my printer was consistently slowing down significantly at a number of points along the curved surface.
Taking a look at the preview in Cura, I could not see anything peculiar at that point. However, when I saved the gcode and re-loaded it in Cura from there, the imperfections did appear in the preview, and they correspond to where I saw my printer slowing down (video)
Finally, out of curiosity, I dug into the gcode to try to identify why my printer was slowing down. There were no speed modifications or anything else that obvious. I wrote some quick python to graph the line movements around that area and show each movement's length and saw some very interesting outliers.
Graphing most of the main outer shell path here for a single affected layer, and highlighting line segments <0.1mm:
We can easily spot the problematic sudden changes in angle which are forcing the printer to almost completely stop in its tracks for a brief moment, leading to the dreaded blob:
and
thanks for all the good comments guys, they align with my findings as well.
I'm currently investigating the effects of adding a polygon/extrusion line smoothing operation after the simplification algorithm.
The basic idea is that it will have sliding window over 4 points (3 line segments) if the middle line segments is shorter then the maximum resolution it wil move the points of that segment closer to the other points (p1 -> p0 and p2 -> p3) with a smooth factor. If possible, otherwise it will filter out p1 or p2. If the distance is shorter then twice the smooth factor of the segment before and after.
This is all WIP and I still need to validate if this won't introduce to big of an error compared to the original polygon.
This should help smooth out sudden bigger changes in the paths. Which are more noticeable in smooth motion planners, such as Klipper.
This could result in us adding a smooth factor setting which will probably be printer (GCode dialect specific)
@jellespijker These particular sentences of your explenation have been haunting me for some time:
The artifacts that occurred in 5.3 were caused by either multiple tiny paths placed after each other, which could cause a buffer underrun in some printers. Simply put, the printer couldn't handle a burst of GCode commands in a timely manner, or by tiny paths with a sudden deviation of the angle compared to an ideal fluid motion line.
We worked on improving this problem in at least two sprints, with two developers, and we managed to improve it compared to what it was in 5.3. We see a drop in the violations of sequential GCodes compared to 5.3.1, as shown in the graph(s) below. Here we analyze the violations for the buffer underruns. Keep in mind that a single small line segment in itself might not be an actual problem, but a number of them might be.
There appears to be some mixing up between two different phenomena, I think there is an important destinction to be made here:
- Too many small gcode commands are sent, causing a buffer underrun and pausing the printer until new commands are received
- A single tiny path with a sharp direction change forces the printer to slow down drastically to adhere to acceleration constraints
As far as I understand these are two totally different things. (obviously many of 2. may also cause 1.) By the sounds of it you guys have been mainly doing sprints hunting after 1. However I believe that 2. is actually what is causing problems here, and my understanding is that klipper is better at avoiding 1. (or so I've been told) while making more efforts to follow the faulty 2. paths as listed in the gcode.
I have been trying to definitively rule out buffer underruns on my klipper machine, but have been unsuccesful in figuring out how to do so. But as far as I can tell, even a single faulty (= sharp angle change) line segment can often cause zits which strongly hints at 2 in my eyes.
that is why I'm currently working on the smoothing part atm
Hi All,
TLDR; I believe I have managed to fix the issue (or at the very least, improve the behaviour). I need you guys to test it on actual printers since I cannot validate the fix (or even the bug) on our printers. Please do this at your earliest convenience, because we plan to release the stable version at the beginning of next week and it would be a shame if this fix is not included.
Problem
The simplification of polygons sometimes leaves small segments with large differences in angles compared to the segments before and after them. This occurs because the simplification algorithm is over-constrained, and the solution space doesn't diverge to an optimal point, but to a plateau. This means that smaller segments won't be filtered out since doing so would violate other criteria, such as removing too much area, etc.
Printers with Marlin 1.x seem to handle the resulting toolpaths better than smooth motion planners such as Klipper. These printers see a sudden change in direction and will try to adhere to the requested toolpath as much as possible. Because that toolpath is now suddenly requesting a change in direction (for a very short length), the head will slow down to make the corner, but the extrusion process can't adjust at the same speed, resulting in over-extrusion at that spot.
Fix
Since we can reasonably assume that such a sudden change in toolpath direction over a short distance, compared to the direction of the toolpath before and after, does not belong to the actual intended shape of the sliced model, we can adjust the polygons in favour of the intended path and help the smooth motion printers.
We loop over each closed polygon, which is used to generate the Aranche toolpaths, and examine 3 segments (4 points) each time: AB -> BC -> CD. Small segments BC (< maximum resolution / 10) that deviate more than a certain angle compared to a fluid motion angle (wall transition angle) between the preceding segment AB or subsequent CD are smoothed out. This is done by either shifting point B or C towards A or D by half the maximum resolution's distance if there would still be 1/3 the max resolution distance left on the segment AB or CD. or removing them altogether if there is no room to shift them.
Process
We plan on releasing the stable version at the beginning of next week, regardless of whether this issue is actually fixed. Do not worry, work will continue on this issue and if we don't manage to include it in the stable version, we'll release a patch version. We decided on this approach to ensure that this ticket isn't rushed and our quality standard is maintained. We also need to release due to UltiMaker's new PET-CF materials being available (it would be odd if people can buy it in the shop but not slice it with Cura).
The Pull Request Ultimaker/CuraEngine#1891 still needs to be reviewed and component tested by one of my colleagues (probably @casperlamboo) and QA tested by our QA engineers @HellAholic and/or @Vandresc. We need your help (@discip, @cohaolain, @poulpor, @aaron-crocker, @harishrajan96, @L0laapk3, @darrellenns, @PhilBaz, @Turbine1991, @Wolfgang-create, @qwerty8224, @DenTechs, @plainoldjim, @alexdoni, @themuck, @Yhunoo). We can't reproduce this issue on our own printers (otherwise, QA would have never let this pass to a release), and we don't own third-party printers (since Cura supports over 500 different printers from competitors). We need you guys to test this proposed fix, not just slice and preview the G-code, but actually print with this nightly and compare it with the 5.4.0-beta.1 or 5.3.x.
I have created a nightly: 5.4.0-beta.2 They can be downloaded here:
UltiMaker-Cura-5.4.0-beta.2+305e00-linux-AppImageUltiMaker-Cura-5.4.0-beta.2+305e00-linux-modern-AppImageUltiMaker-Cura-5.4.0-beta.2+305e00-win64-exeUltiMaker-Cura-5.4.0-beta.2+305e00-win64-msi- Mac ( Coming soon, the compiler Apple-Clang v13 is missing some functionality)
New builds (#14811 (comment)):
UltiMaker-Cura-5.4.0-beta.2+305e00-linux-AppImageUltiMaker-Cura-5.4.0-beta.2+305e00-linux-modern-AppImageUltiMaker-Cura-5.4.0-beta.2+305e00-win64-exeUltiMaker-Cura-5.4.0-beta.2+305e00-win64-msi
Even newer builds (#14811 (comment)):
- UltiMaker-Cura-5.4.0-beta.2+305e00-linux-AppImage
- UltiMaker-Cura-5.4.0-beta.2+305e00-linux-modern-AppImage
- UltiMaker-Cura-5.4.0-beta.2+305e00-win64-exe
- UltiMaker-Cura-5.4.0-beta.2+305e00-win64-msi
- UltiMaker-Cura-5.4.0-beta.2+305e00-mac-dmg
- UltiMaker-Cura-5.4.0-beta.2+305e00-mac-pkg
I noticed that in atleast one test project file of mine a hard crash on the engine occured, not directly related to my fix and in a location where it previously did not crash. I will investigate further on Monday why that is. But the nightlies as they are now should at least validate the fix.
Sounds promising, I'll take a look at this. I may not be able to print something soon, but I'll definitely be able to compare Cura's output with my python script to see if the short line segments have been eradicated. Essentially, this will check all line movements generated to see if any are shorter than 0.05mm.
They are quite readily visible, occuring in groups, visible particularly when graphing the issue with many layers on top of one another - or when printing, and seeing them grouped together!
GCode zip file of affected file from Cura 5.3.1
This is the script I'm currently using. You can call it like this:
python test_gcode.py 20230529_Rubber_Duck_02mmlh@150mmps.flow@100.gcode 10 15test_gcode_script.zip
Which shows all outer wall extrusion lines, highlighting short line segments (under 0.05mm), at layer heights 10-15mm.
With the affected gcode I've attached, this yields the following:
I'll take a look at this and compare with the new build soon :)
Smoothing the output sounds like a good idea in theory, though I am still curious if this is just a temporary workaround rather than a permanent solution (better in the short term than not addressing, of course)? In particular, do we have any idea what change actually introduced this issue to 5.3.0?
Thanks all for your time!
A quick test still shows some of these bad segments appearing in gcode, but much fewer - 19 vs 102 at layer heights between 10-15mm.
Still seeing e.g.
STL, gcode: duck_gcode_and_stl.zip
To summarize, it looks like the symptoms have been partially relieved, but the underlying issue is still apparent to some degree. Although I haven't tried printing this output myself, it seems apparent this would still have some marked impact on the final print quality.
Can you share the 3mf instead of the stl since the settings and printer definitions determine a lot in the smoothing algorithm.
b.t.w good approach using Python for this. We recently added some extensive logging to engine with our Visual Debugger and in my test projects I don't have any segments smaller then 50 micron between longer segments. Mind you they can still occur in sequence for very small radii. But then it is expected and acceptable since it is the intent.
That being said, I do see a lot more violations when I slice that rubber ducky stl on a Creality printer. Which is a bit of a bummer, I will investigate further on Monday. Since I didn't intend to work this long on this ticket on a Saturday.
Haven't seen ParaView before, looks cool. I'll share the .3mf when I'm home, enjoy your Saturday :)
3mf as promised, the gcode from this on the new build yields 19 erroneously short line segments between layer heights 10-15mm, as mentioned above. The model is scaled 150%.
test2_20230702_Rubber_Duck_02mmlh@150mmps.flow@95.3mf.zip
I did some quick fixes, eliminating a lot of those pesky segments. Two of the biggest culprits were an optimization made to check the deviation between angles (fix here: Ultimaker/CuraEngine@f9a3538 ) and checking the first segment in the closed loop (fix here: Ultimaker/CuraEngine@f694ca4 )
I build a couple of new installer:
I noticed that the filter criteria for the smoothing was a bit to aggressive and that removal of points if a point couldn't be move resulted in self intersecting shapes (which are a major cause of hard crashes).
Both issues resulted in to much deviation from the intended shape in general and are fixed with this commit Ultimaker/CuraEngine@6220a38. These new builds are based on that fix and should only smooth out the problematic segments:
- UltiMaker-Cura-5.4.0-beta.2+305e00-linux-AppImage
- UltiMaker-Cura-5.4.0-beta.2+305e00-linux-modern-AppImage
- UltiMaker-Cura-5.4.0-beta.2+305e00-win64-exe
- UltiMaker-Cura-5.4.0-beta.2+305e00-win64-msi
Please test it out with some actual prints
This looks much better. From what I can tell this will yield 1-2 artifacts, but it's a significant improvement over 5.3.1, and even 5.2.2, using my .3mf as reference!
| version | # outer wall segments < 0.05mm |
|---|---|
| 5.2.2 | 13 |
| 5.3.1 | 1701 |
| 5.4.0-beta.2+305e00 as of writing | 2 |
Those two segments in the entire gcode are the only ones that are questionable, specifically these moves:
| move_to_x | move_to_y | segment_length | z_height |
|---|---|---|---|
| 156.314 | 76.396 | 0.04661544808323279 | 11.0 |
| 67.092 | 123.938 | 0.025806975801128857 | 52.4 |
Particularly that second one @ Z=52.4mm:
The first isn't so bad, as it's not so much of an angle change.
This looks great :) I'll go about printing something when possible, but as far as I can tell, this is a solid improvement.
yes those shorter paths are probably in the fluid motion lines, the "problematic" shorter segment is probably not smoothed because the previous or next lines are also relatively short.
When printing also make sure that you check the quality and dimensions in general, because it is a common trap to loose sight of other factors. In short, this fix shouldn't impact dimensional accuracy etc.
We need your help (@discip, @cohaolain, @poulpor, @aaron-crocker, @harishrajan96, @L0laapk3, @darrellenns, @PhilBaz, @Turbine1991, @Wolfgang-create, @qwerty8224, @DenTechs, @plainoldjim, @alexdoni, @themuck, @Yhunoo).
Please print something with the latest shared builds and give us your feedback.
Nothing fancy or long, just a quick print.
It's planned, but my main computer is a mac, so I have to boot a Linux or Windows VM. Sorry will do it later when I have a moment ^^;
Unless you could build a mac version?
Hoping I can fix the mac builds tomorrow morning. I need to sit behind an actual MacBook to debug and fix that problem and for that I need to ask IT for one in the office
We need your help (@discip, @cohaolain, @poulpor, @aaron-crocker, @harishrajan96, @L0laapk3, @darrellenns, @PhilBaz, @Turbine1991, @Wolfgang-create, @qwerty8224, @DenTechs, @plainoldjim, @alexdoni, @themuck, @Yhunoo).
Please print something with the latest shared builds and give us your feedback.
Nothing fancy or long, just a quick print.
Tonight
@cohaolain
I was very optimistic, when I read about your results regarding the latest build.
But after testing it I am somewhat puzzled how you got better results than 5.2.2.
Attached are the 3mf files saved both with the latest build and 5.2.2.
I named them accordingly.
Could you please check whether you get better result with those too?
cylinder5.4.3mf.txt
cylinder5.2.3mf.txt
Thanks in advance!
I just finished printing something with output from the new build - much better results - though I did find two sharp angle changes in the output with my script the first time I sliced it.
20230702_Tradfri_Control_Switch_Standard_Light_Switch_Overlay_UK_02mmlh@150mmps.flow@95.gcode.zip
Issues at:
140.127 151.367 0.028425340807119535 @Z1.4
78.377 69.446 0.02860069929215607 @Z1.8
I can spot these 2 blobs on the finished print, but probably would have to be looking for them (since they aren't banded together like before), though would be nice to eradicate them too I guess!
But otherwise, no issues were spotted.
I went to re-slice and create a .3mf for you to see these two issues, but only have the gcode I sent to printer which has the 2 anomalies since the anomalies don't seem to be appearing on new re-slices with the same version? Is there a random seed used somewhere or something? Not sure what changed there otherwise! 🤔
Here's a 3mf anyway:
20230702_Tradfri_Control_Switch_Standard_Light_Switch_Overlay_UK_02mmlh@150mmps.flow@95.3mf.zip
@cohaolain I was very optimistic, when I read about your results regarding the latest build. But after testing it I am somewhat puzzled how you got better results than 5.2.2. Attached are the 3mf files saved both with the latest build and 5.2.2.
I named them accordingly.
Could you please check whether you get better result with those too? cylinder5.4.3mf.txt cylinder5.2.3mf.txt
Thanks in advance!
If you could send me on the gcode output from you slicing with both versions, I could generate the list of short line segments for you in each file?
We need your help (@discip, @cohaolain, @poulpor, @aaron-crocker, @harishrajan96, @L0laapk3, @darrellenns, @PhilBaz, @Turbine1991, @Wolfgang-create, @qwerty8224, @DenTechs, @plainoldjim, @alexdoni, @themuck, @Yhunoo).
Please print something with the latest shared builds and give us your feedback.
Nothing fancy or long, just a quick print.
With beta 2 I had no noticeable artifacts on my usual test print... So, this is a large improvement :)
I have used the same test shape with all the different versions.
Good stuff! Thank you for your efforts!
ps...I didn't check dimensions at all.
For people with a Mac (@poulpor )
I noticed that the filter criteria for the smoothing was a bit to aggressive and that removal of points if a point couldn't be move resulted in self intersecting shapes (which are a major cause of hard crashes).
Both issues resulted in to much deviation from the intended shape in general and are fixed with this commit Ultimaker/CuraEngine@6220a38. These new builds are based on that fix and should only smooth out the problematic segments:
* [UltiMaker-Cura-5.4.0-beta.2+305e00-linux-AppImage](https://github.com/Ultimaker/Cura/suites/14009032738/artifacts/781862053) * [UltiMaker-Cura-5.4.0-beta.2+305e00-linux-modern-AppImage](https://github.com/Ultimaker/Cura/suites/14009032738/artifacts/781862054) * [UltiMaker-Cura-5.4.0-beta.2+305e00-win64-exe](https://github.com/Ultimaker/Cura/suites/14009032738/artifacts/781862056) * [UltiMaker-Cura-5.4.0-beta.2+305e00-win64-msi](https://github.com/Ultimaker/Cura/suites/14009032738/artifacts/781862058)Please test it out with some actual prints
I`m Downloading it now, and print something instantly, results will be postetd as soon as the print is done.
it got better but there are still bugs....
I'm worried about something else when I select the Ultimaker S5 printer in the preview, it's just awful, it didn't happen before .....
maybe it's in the hardware and some kind of library or video card processor and the like causes incorrect slicing?
You would have to be a bit more specific.
What do you mean there are still bugs? are these actual printed blobs, do you observe this in the preview. Can you share the project file, such that we can reproduce
@qwerty8224 can you elaborate what you consider worse behaviour, because if I slice this project in 5.4.0 it looks pretty decent in the preview. It would really help if you would print the model as well and add some photos such that I can investigate further
I will do a statistical analysis and run it through the visual debugger tomorrow morning. But I don't see any obvious jagged paths just skimming over the Cura preview.
Yes, this project is not bad, but still there are a few shortcomings, I'm wondering why the ultimaker S5 project looks very bad, I have not seen this before.
I also understand that maybe my settings are very old, they were probably transferred from Cura 5.0. But unfortunately, I can't make all the settings from scratch yet, completely remove Cura and clean up all the files. Now I'm wondering why the profile of the ultimaker S5 looks bad, I didn't touch anything on the default settings ... it turns out we are repairing one but the other is breaking ..
you write that you cannot reproduce the problem on Ultimaker printers, I originally had this problem on Ultimaker printers, I reported it and now I also see a problem in Ultimaker profiles, so I can’t understand why you don’t see it, but I see, I can assume that could it be something else? 🤷
thank you for your perseverance in solving the problem 😉 I think the community will appreciate it.
in my opinion, if I remember exactly in my cfffp profile (the maximum resolution is reduced to 0.04 and it should be 0.25) please check, maybe this will help to see the problem more clearly.
I'm printing the S5 project file as we speak on my own Ultimaker S5. This should contain all the settings that you use. I will share the images later.
On a separate note if I look at the screenshot that you shared I have trouble mapping those defects to the actual shared project file. If the screenshot and the project file are the same then the seams on the chamfered edges of the 4 holes should look the same. But in the screenshot that you posted they are in a straight line, while in the project file sliced on my computer, they're clearly not. See the screenshot.
I will post the statistical analysis of the sliced project files tomorrow morning, as well as the actual printed part and we will go from there.
I am seeing "Slicing failed with an unexpected error" with the new build (5.4.0-beta.2+305e00) in one situation today. I've verified the issue doesn't occur with 5.4.0-beta.1. I'm unsure if it's related specifically to the smoothing operator though.
Project File: 20230705_tallneck_failing_540_beta2.zip
Engine crash log file: engine_crash.log
(Model from here)
Of all the STLs included in the model and 3mf above, looks like even body-middle-no-supports.stl on its own causes the crash.
thanks @cohaolain best to open up a new issue for that crash, otherwise this ticket will be come one big collection box and it will never get closed.
@qwerty8224 I did a bit of investigation on your shared project files and I can't find any occurrence of something resembling jagged paths. Analysing the toolpath lengths and directions in Paraview (see screenshot below) show that there are 9 segments in the whole print with a length below 50 micrometer, keep in mind that these are are not troublesome on their own, but they can be, if they occur in short repetition of each other (resulting in buffer underruns) or if the suddenly deviate to much in angle from the angle of the previous segment and next segment (jagged paths). All 9 segments (<50 micrometer) seem to be single occurrences and inline with the segment before and after.
Looking at the actual print, of your shared project file on a S5 also doesn't show any jagged paths.
It could be that you observed a some visual rendering artifacts when you inspected the GCode in the preview view. Which made it seem worse? I would ask you to actually print the model on your printer such that we can rule that out.
Regarding the resolution of in the cffp profile:
maximum resolution is reduced to 0.04 and it should be 0.25
Yes it was indeed set to 0.04, which is to low for any printer in my opinion and not a realistic value. For us programmers and tester it is hard to guard and sanitize the output of Cura, while also allowing for a lot of fine-tuning of other settings. So it is entirely possible to create profiles which will result in weird undefined behaviour. This is why we have a whole department Print Process and Material which come up with good profiles and values for our UltiMaker printers. But we can't do that for all 3th party printers or Custom FFF printers. We rely on the community contributor or someone such as yourself to determine realistic values for their profile.
I did the same analysis with our Visual Debugger with Paraview and regardless of the used value: 0.04 or 0.25 for maximum resolution did not observe any jagged paths.
I will close this ticket now, since we believe that the behaviour is improved if not fixed. I would love it if people that experienced this issue would download 5.4.0 and do some actual printing and report back if they still see any jagged paths. We can then reopen this ticket if needed.
If you're observing crashes or any other weird behaviour please create a new issue for that.
I would also like to thank the people who helped out with actually printing some stuff to validate my WIP build an such short notice.
On a side-note we will look into expanding our support for Klipper printers I believe @MariMakes has some plans about starting this up.
thanks for your work.
But I still attach screenshots
this is my profile maximum deviation 0.25
I understand that maybe I don’t know something, I’m not a professional, I’m an amateur, but just take it into account. Thank you.
@jellespijker What are you using to convert gcode to pvtu for paraview? I'd like to do a few comparisons of my gcode, and doing it in paraview seems much nicer than what I was doing before.
thanks for your work.
But I still attach screenshots
it looks like you're using a very low max resolution please increase it to a value in the region of 0.5 mm
@jellespijker What are you using to convert gcode to pvtu for paraview? I'd like to do a few comparisons of my gcode, and doing it in paraview seems much nicer than what I was doing before.
We have a closed source visual logger to help us debug the engine which outputs pvtu files.
thanks, you're right, it's getting better, in general, you need to optimize the parameters for yourself.
On a side-note we will look into expanding our support for Klipper printers I believe @MariMakes has some plans about starting this up.
Off-topic, but really looking forward for the direct Klipper support in Cura! 😁
I currently maintain Fluidd (Klipper web interface) and am a regular contributor to Klipper, Moonraker, and even Mainsail, so if there is anything I can help to get this going, please don't hesitate in contacting me!
👋 We are collecting feedback on how we can improve our support for Klipper printers in this discussion
I'll add this link to the Github release notes and will add an extra field in the issue templates where reporters can share that Klipper is part of their configuration to help with troubleshooting. 💪
If you have any feedback on how we can do better, we would love to see it in the discussion. ❤️
Sorry for the late update, I wanted to test your 5.4.0-beta.2+305e00 build but when I tried to slice my test shape (the one I've posted pictures earlier) with it, I got the "Slicing failed with an unexpected error" message. Strangely, when I changed the model scale in Cura to anything higher than 100%, even 100.1%, the slice worked fine, but I chose to wait for the final release.
So, I tried today the final 5.4.0 and the slice worked fine, I kept my default Marlin settings, nothing fancy (fine quality 0.2mm at 60mm/s print speed).
The print looks OK and I didn't find any zit/blob, so thank you very much for this quick fix!
Will keep an eye on this ticket in case of further developments.
The white model print was sliced with 5.3.1, the blue one with 5.4.0.
I ran some slicing tests with 5.4.0, and I no longer see the short sharp angle segments on large radius curves like in 5.3 versions. So, at least in my test the changes seem to have fixed that issue.
If this has been solved by filtering out short/sharp segments, I do wonder if that could negatively affect fine details. I don't really have a good test procedure for that though. Was there already some testing/validation done in the development of the fix to make sure it's not smoothing out details that should be there?
A huge thanks to @jellespijker and everyone else involved with testing and fixing this issue.
Thx @darrellenns for providing additional feedback.
No need to worry about negatively affecting small details. The fix was smoothing the shapes from which the toolpaths are being generated. I took your concern into account and developed an algorithm which only acts upon very small line segments (< 50 micrometer in length this will probably be a new setting in Cura 5.5) but on top of that these line segments also need to deviate an certain angle when look at the previous segment of the shape and the next segment of the shape. This extra filtering conditions further ensures that we only act upon lines which are probably not "intent" of the model; most likely created during previous morphological operations and not filtered out during the simplification since it didn't fulfill the conditions of that over-constrained algorithm.
Since this smoothing operation will not remove points but only shift them along the direction vector of the previous or next line segment and only do this if that line segment is at least twice as long as that shifting distance.
This will result in a more continual movement of the printhead since it doesn't need to slow down to make that sharp corner, for a line segment which is relatively unimportant to the whole shape.
After shifting point B towards A and C towards D, the head doesn't need to slow down as much to make the corner.
And the actual affected surface area is relative small. Remember the size of the dimensions used. BC < 50 micrometer
