add a preprocessing function to calculate flush vol based on color

[jacksky6]

When using purge bucket in multi-color printing, the value of flush vol is very important.

Orca/bambu slicer can calculate it automatically. But prusa/super slicer cannot, it is a fixed value by default. When using orca/bambu slicer, people rarely modify the specific value of flush vol (no clue), at most they modify the multiplier. (The extrusion multiplier can be set in the bucket macro, such as blobifier)

The difference in flush vol from dark color to light color and from light color to dark color is huge. It is unreasonable to use a fixed value.

However, the flush vol in orca/bambu is calculated by color and is not related to other parameters.

Is it possible to decide whether to use the flush vol extracted from gcode or calculate by color according to the user's settings (enable_flush_vol_calc: True) during preprocessing.

After this processing, the user only needs to care about whether the color is correct when slicing.

Original C code of orca:
https://github.com/SoftFever/OrcaSlicer/blob/main/src/libslic3r/FlushVolCalc.cpp

Translated python code:
https://github.com/jacksky6/FlushVolCalcScriptForERCF/blob/main/FlushVolCalcScriptForERCF.py

[moggieuk]

Right, Happy Hare today will pull the purge volume matrix from the slicer and store in the "slicer tool map" for use during purging, etc.

Are you suggesting that a purge volume matrix could be created programmatically and override the slicer provided one based on the RGB color in the provided routine? I would probably use a configuration toggle variable, so you could get to either the slicer set or color computed set.

If so that was actually on my "wish list" but I didn't have reference logic to do the calculations (until now). Thanks!

[jacksky6]

@moggieuk

Yes!

When I used prusaslicer, I modified my PURGE macro to calculate PURGE_LENGTH every time based on the color instead of using the sliced ​​pruge vol.

The logic is referenced by orcaslicer, so the results are the same.

It is better to calculate the matrix data once and store it in a variable when printing, rather than calculating it every time.

In this way, all PURGE macros can be customized to choose pruge_vol_from_slicer or pruge_vol_calculated_by_color.

[moggieuk]

I've implement this in the v3.0.0 release which should be out in beta in 2-3 weeks to support type-B MMU designs. I didn't have time to retrofit to v2.7 ...

[jacksky6]

@moggieuk
Wow，it's cool...

Does the B-type mmu only support stepper motors or does it also support dc reduction motors like the one from Bambu AMS?