Need Advice: volumetric flow vs actual volumetric flow and how to tune for bridges and curved overhangs
I want to understand how the XL is meant to be tuned so I can improve print quality on bridges and on overhangs that transition upward along curved geometry. On my other printers, those problem areas are usually solved by slowing down and increasing fan speed. The XL seems to want a different approach, and I am trying to work with it instead of against it.
Putting this in the XL forum because, compared to other printers I use, the XL feels very tuned around volumetric flow. It seems to print best at higher temperatures and generally higher speeds, which is very different from how I normally tune other machines.
I read Prusa’s articles on volumetric flow, but I am missing something fundamental, especially around how the slicer represents volumetric flow versus actual volumetric flow.
Three things are confusing me:
1. Prusa slicer's "Print Settings" show max volumetric speed as 0 mm³/s. I assume that means it is deferring to other limits in the filament settings, but I do not know for sure what limit is actually governing flow.
2. In the preview, the volumetric flow rate view shows a wide range of flow rates across the print. But when I switch to the “actual” volumetric flow rate view, it shows a very low and very consistent flow rate everywhere. Why is the actual volumetric flow so low compared to the volumetric flow view? Also, I assumed the goal was to keep it consistent, so why such a wide difference of very low (blue) to very high (green)?
3. I tried this item many times, but cannot get it to print as well on my XL as on a machine like a Bambu. Another XL person comments similarly on the "Makes & Comments". This leads me to believe that I need to approach the same problem differently, as I'm sure it must be possible on the XL: https://www.printables.com/model/1475259-3d-printing-bridge-calibration-test-basic-advanced
I am using stock profiles and trying to understand how these limits interact so I can tune the machine properly instead of guessing.
If anyone has good guidance, videos, articles, or firsthand experience tuning the XL around volumetric flow, I would really appreciate being pointed in the right direction.
Best Answer by ron:
1.
Actual volumetric speed can't be consistent because of accelerations. Then there are some tricks to mitigate the effect of non consistent volumetric speed (linear advance, pressure advance, ...). For flexible material you want it the most consistent possible then you print at slow speed to get reliable prints. Once I made a flexible filament profile with speed varying between the different features to keep a constant volumetric speed. But due to acceleration, the actual volumetric speed can't be constant. As soon as you want to print at high speed, your actual volumetric speed will vary greatly.
2.
You may find description of "actual" here: https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.8.0-alpha5
Consider "speed" and "volumetric speed" calculated with infinite acceleration. "actual speed" and "actual volumetric speed" are with acceleration. Then you see on small trajectories, the toolhead has not enough time to reach the targeted speed you specified for a feature.
I still don't understand why you got a so big actual volumetric speed (68.69) for a custom g-code which is probably the prime line. That makes me feel it is a bug. But intuition is not science.
RE: Need Advice: volumetric flow vs actual volumetric flow and how to tune for bridges and curved overhangs
We don't see the scales of the volumetric speed. Is the maximum about the same?
RE: Need Advice: volumetric flow vs actual volumetric flow and how to tune for bridges and curved overhangs
Sorry - the image is clipped in the forum unless you click on it.
For volumetric speed the scale is from 25.310 down to 0.920
For actual volumetric speed the scale is from 68.690 down to 0.000
RE: Need Advice: volumetric flow vs actual volumetric flow and how to tune for bridges and curved overhangs
That is indeed strange to get an actual volumetric speed higher than a volumetric speed. And having 68.69mm3/s as a maximum in the scale. And it is not easy to track down where is that 68.69mm3/s in the print.
Does "hide custom g-code in" the legend area change anything?
RE:
Sorry - the image is clipped in the forum unless you click on it.
For volumetric speed the scale is from 25.310 down to 0.920
For actual volumetric speed the scale is from 68.690 down to 0.000
Yes, that helped! Never would have thought to click that. So, based on what I've been reading
1. Shouldn't volumetric flow be consistent for quality and predictable prints, and how would I tune for that using PrusaSlicer?
2. Is there a description somewhere of what I should trust, and how to use/compare the volumentric flow vs the "actual" volumetric flow?
RE:
1.
Actual volumetric speed can't be consistent because of accelerations. Then there are some tricks to mitigate the effect of non consistent volumetric speed (linear advance, pressure advance, ...). For flexible material you want it the most consistent possible then you print at slow speed to get reliable prints. Once I made a flexible filament profile with speed varying between the different features to keep a constant volumetric speed. But due to acceleration, the actual volumetric speed can't be constant. As soon as you want to print at high speed, your actual volumetric speed will vary greatly.
2.
You may find description of "actual" here: https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.8.0-alpha5
Consider "speed" and "volumetric speed" calculated with infinite acceleration. "actual speed" and "actual volumetric speed" are with acceleration. Then you see on small trajectories, the toolhead has not enough time to reach the targeted speed you specified for a feature.
I still don't understand why you got a so big actual volumetric speed (68.69) for a custom g-code which is probably the prime line. That makes me feel it is a bug. But intuition is not science.
RE:
I still don't understand why you got a so big actual volumetric speed (68.69) for a custom g-code which is probably the prime line. That makes me feel it is a bug. But intuition is not science.
This sounds exactly like what I'm seeing for Core One in PS: There is a single feature that gives crazy high numbers - and yes, if I remember correctly it is indeed the prime line. It squishes the scale of the plot so actual numbers are getting difficult to read because 99.9 % of the plot use < 10 % of the number range on the color scale.
I consider it a bug, annoying but not critical. And there seems to be a button made just for this problem: "disable custom G-codes" but it only hides the prime line, doesn't re-scale the color bar.