Just so I’m making sure I understand, if I want fully dynamic flow calibration:
I should uncheck “Enable Pressure Advance” under each of the filament profiles I use
After each time I load a filament into a toolhead, for my first print, I should check “Extrusion Flow Calibrate”
As long as I don’t use a filament profile on that toolhead which has “Enable pressure advance” enabled, or unload that toolhead, it will preserve my dynamically calculated pressure advance value for repeated prints
None of this has anything to do with “Flow Ratio” which I should still tune using a traditional orca “Flow Rate → YOLO” calibration test
One question I have is, while performing a flow rate test itself, should I enable pressure advance or not? Should I use dynamic flow calibration or not? Or does it not matter?
EDIT I just did this and while watching the logs in fluidd, it seems like my dynamic flow calibration can’t even measure the value on its own
11:40:11 // start extruding
11:40:11 // measure k: 0.03800
11:40:42 // measure area: -552799.00000
11:40:42 // measure k: 0.06200
11:41:23 // measure area: -1647190.00000
11:41:23 // abort calibration: out_of_range
11:41:23 // flow k is out of range, use default value:0.05
@Wombley helped me out here I edited the relevant profile in fluidd under snapmaker/filament_parameters.json, adjusting my flow_k_min and flow_k_max to 0.01 and 0.08 respectively (the defaults were 0.038 and 0.062) and now dynamic flow calibration is able to detect a usable k value.
That being said, I ran a followup print, using the same toolheads, the same profile (with “pressure advance” checkbox disabled), and did not re-run the extrusion flow calibrate sequence. At first it seemed to be using my originally computed K values, however, as the print progressed, it seemed to switch out for 0.02 static pressure advance.
I did several more tests and found that, for any print past the first print, it does not consistently re-use my previously-calculated dynamic flow calibration values. If you want to use those values, then you need to run a flow calibration before every print.
So in conclusion, at least until this gets fixed, I think the better approach is:
Enable flow calibration
Note the value it computes from the fluidd logs
Enable the “pressure advance” checkbox in the slicer and use the value you noted in step 2
Never re-run dynamic flow calibration for that filament brand/type again
I’d still warn based on the values you showed me on discord, 0.08 is also probably a little bit too high. It was becoming parabolic for some of the values approaching that. 0.06 might do.
Hello, i have tryed to research a little, from what i have found untill now the printer it is using ( if even is doing this, i do not know what motor drivers are) only feedback from the motors based on load. It is somehow working, but for this reason the bed mesh is not quite accurate, and is not almost at all for the pressure advance reliable.
It is an option, it is looking nice and i think this is all.
For this reason also there are imperfections at the changes of the speed, it is a fix value and is not dynamically monitoring changes in load, acceleration, high flow infill ( this i think is the reason that the hotend in many cases is scraping on grid infill ) it is only apply some empiric mediations based on that fix value for all.
Quite some basic printer i would say.
LE: forgot to mention that i am checking few times each day the delivery status can wait to receive mine
To Pressure Advance U1
It’s a cool principle:
Each of the four toolheads of the U1 is equipped with an integrated load cell. This is located directly above the hotend or is part of the suspension. It registers the vertical force (pressure) generated when the extruder motor pushes the filament against the resistance of the nozzle.
The principle:
The higher the flow rate or the thicker the material, the greater the backpressure acting on the load cell.
The value is not saved, so it is lost when the printer is turned off, and possibly also at the next print start without a filament change.
For me it is easier to caliberate the filament once, set the vlues and forget. I.e. measure the flow rate (e.g. 97 %) and measure the PA value (like 0.02), set them in the filament details and forget about the automatic dynamic stuff of the printer. The name for that autoamtic things is also misleading..
Actually, the logic in this area was previously discussed with everyone in the forum and has been communicated to the product manager, hoping they can sort out a good priority and usage scenarios.
I am also having an issue with dynamic flow calibration returning an inappropriate value. For example, I get a value of 0.017742 from calibration. But when performing manual PA calibration, the best values are between 0.028 and 0.032.
I can’t find any information on how the various flow calibration parameters impact the calculation. I tried increasing k_max since the default was right at the start of decent values, but no impact. Still received a 0.017xx value. Anyone have any information on how to get the calibration functioning correctly? Bambu lab’s approach, however it works, seems to be quite superior.
I just came across this thread because I was also wondering how the assignment actually works. I had imagined that this value is stored per filament type. So, if I load a filament (type and color) for which it already has the calibration, it uses that value.
That would be quite logical, wouldn’t it? Especially since the U1 always complains if I don’t tell it what I’ve loaded. This would also be a motivator to install the custom firmware and use OpenSpool. Ideally, with the option to manually correct the value.
BTW: what do the lines it presses onto the build plate in front of each extruder actually do? Is it just priming, or does it measure something there as well?
are you absolutely sure about this? I have left PA on in the slicer at the default of 0.02, I then started a print and let the printer calibrate it, when I look in Fluidd I see PA Value of 0.016021
So what is correct here? Do we need to disable it in the slicer or not?
There will indeed be some issues here. I will directly suggest that they change the value here to 4 decimal places instead of rounding to 2 decimal places.