Cannot use decimals or absolute values in flow/speed ChangeAtZ 5.3.0

[OsmosisD]

Cura Version

5.7.2

Operating System

Windows 10

Printer

Creality CR-100, but could affect any printer.

Reproduction steps

Wanted to set absolute values for flow rate in ChangeAtZ since my printer is very finicky about it.

Actual results

Can only enter flow rate as percentage of current value, and only in whole numbers.

Expected results

Set flow rate as absolute values, i.e. 90.8% (my current normal is 90.7%), not relative values (I don't want 90.8% of 90.7%... That would be 82.3556% which is way too low.).

Add your .zip and screenshots here ⬇️

[Asterchades]

ChangeAtZ is a fairly simple script, doing all of its adjustments as single commands in the GCode. For Flow Rate, this means just putting an M221 in the output GCode. The alternative would be to process each and every single E value in the output, which is a lot more finicky when other scripts are in use.

It doesn't accept a decimal value as Marlin (still the most common 3D printer firmware, at least as a foundation) will accept floating point values for M221 but truncate them to whole integers anyway. This way you wind up only being able to specify the value that will actually be used. Though it's possible this is just a happy coincidence, and may not necessarily have been deliberate when the script was implemented.

*Didn't mean to close that. Going to leave it open in case the script author has more additions.

[GregValiant]

From the script setting: "g2_flowrate": { "label": "Flow Rate", "description": "New Flow rate", "unit": "%", "type": "int", "default_value": 100, "minimum_value": "1", "minimum_value_warning": "10", "maximum_value_warning": "200"

So it is as Asterchades explained, the setting only takes an integer. You can enter "91" but not "90.8".

Because there is a limit here imposed by Marlin (and RepRap) then even if the setting box accepted a Float the firmware will truncate it. Entering 91% would be closer to what you want than a truncated 90.8.

I don't see a possibility of a Feature Request here because of the over-riding firmware limit of "integers". I'll go ahead and remove the bug label and close this as it is expected behavior. I hope you understand.

Your alternative is to make a flow adjustment within the Cura Material Settings. Since the flow percentage is used in the actual calculations of the E values (rather than a blanket M221 global change that affects the printer/planner) a number can be a three place decimal (90.888%) and it would be allowed.

[OsmosisD]

So it's a firmware limitation? That's unfortunate. I'll have to look into post-processing using some other method (like a dedicated program to edit any generate gcode). I was under the impression that the post-processing scripts in Cura did that anyway but I guess not; maybe post-processing is a slight misnomer here?

I've been doing flow adjustment in material settings but having to print five models when I can do one with some gcode modifications is a lot less efficient on filament usage (and time).

Guess I'll whip up something similar to what I did to manually add spiral Z-hops to my prints.

Thanks for checking this over though!

[Asterchades]

It's not really a misnomer in that it does alter the GCode after Cura generates it by inserting the appropriate line/s, hence processing it in post. This particular script just isn't as invasive as you were hoping it would be.

Given the foundation in Python there would be nothing stopping a script being created that was more full-processing than this, searching for every single E value and adjusting them similar to how Flow already does. You could even make it "smart" and take retractions into consideration, which I'm pretty sure M221 just plows right over. Just that's a lot more potential for something to go wrong than inserting a single line that covers the majority of use cases.

[GregValiant]

I write a lot of post-processors. There aren't very many that "re-process" the gcode. Generally they go through the gcode, figure some things out, and make a couple of insertions or maybe deletions. Search and Replace, Pause At Height, Filament Change, Time Lapse, Advanced Cooling Fan Control, etc. all work that way as does Change at Z. Change at Z actually may go the farthest into "re-process" when you ask for something like a change in the retraction distance or retraction speed.

If I was to write a script for this I would insist that the user use "Relative Extrusion" in the slice. Each E value in the gcode is then a stand-alone value so each could be adjusted by a specific percentage. The retractions/primes wouldn't need to be adjusted. In "Absloute Extrusion" mode, the E values are incremental and so each calculation would have to take into account the previous value, subtract it, and then do the new percentage on the adjusted amount. In essence you would be converting everything to Relative and then converting the adjusted amounts back to Absolute. That would include retractions and primes. Doable, but tedious and subject to rounding errors that would eat away at the delta change of 0.20% between 90.8% and 91%. The final insertion would need to be a G92 to re-sync the extruder location to the follow-on E values.

Either way the script could be designed to act on a specific range of layers or multiple ranges of layers. If the script was to be ambidextrous it would also need to take into account printers with multiple extruders and make further adjustments at the tool changes. And then there is One-at-a-Time mode.

[OsmosisD]

All right. I'll spend some time writing my own post-processor to do the stuff I need then.

I guess it makes sense that they'd try to keep the scripts as simple as possible if they're trying to avoid potential errors/conflicts.

My previous script to add spiral Z-hop involved switching to relative position and then back again so I didn't have to calculate all the exact positioning; a bit hacky but it does work fine for my printer. I did also wonder if rounding errors from switching back and forth might be a concern.

This is all very informative! Again, thanks for taking the time to write up these detailed responses.

[GregValiant]

This is from the Marlin Git page and "M221.cpp" lines 36 and 37: "if (parser.seenval('S')) planner.set_flow(target_extruder, parser.value_int());"

So the firmware will truncate whatever is in the M221 to an integer so there isn't any use even hand-coding something like M221 S90.888 because the firmware will shorten it to 90 anyway. M220 works the same way for the feedrate %.