Max Volumetric speed bug?

[mysticprysm]

OrcaSlicer Version

1.6.6

OS version

Windows 11

Additional system information

Ryzen 7 5700x RTX 3070 32GB RAM

Printer

BambuLab P1P

How to reproduce

Change max volumetric speed I think?

Actual results

So, I'm not sure if it's model specific or what, but when I slice this model, be it with one on the plate, or multiple, it shows this high volumetric speed near the bottom, even though I have it capped. For visual sake, I capped it at 5, and it shows it getting up to 20 still. Unsure if it's a functional bug or visual glitch, but the print does seem to suffer in that area.

Expected results

The volumetric speed should be capped at whatever you cap it at.

Project file & Debug log uploads

log.zip Mushroom Containers.zip

Checklist of files to include

• [X] Log file
• [X] Project file

[ercdvs]

Came here to look this up. I have max volumetric speed set to 24mm^3, but i have, for a .6 nozzle, .3 layer height, and .62 line width have a wall @ 200mm/s

This results in a volumetric limit north of 37mm^3, and therefore fails to print. The speed should be dropped to enforce this limit

[jaimewyant]

I'm having a similar issue also. I've set the max volumetric flow rate to 5 but it hits 13.37 at certain parts of the model. The image below illustrates this.

[jaimewyant]

The bug is fixed in 1.7 for me. @mysticprysm may be worth checking out for you too.

[ercdvs]

1.7 is what i am using, and it is present for me still. Even though i have max volumetric speed set, its allowing the speed to contribute leading to some areas to outrun my set flow. I need to go an manually adjust speed for all areas which defeats the purpose

[Ninix-source]

I'm having the same issues as @ercdvs. Currently running 1.7 too.

[top4ek]

Got the same bug on 1.7 while material limit is 8. Have found that checking "Use relative E distances" makes speed close to the limit but still more than set(up to 11.55). Once sent to print Klipper stops task with "Move exceeds maximum extrusion" error eventually(in my case after 5 hours), so it's not a visual bug. Had to lower speeds manually to ± fit into the limits.

[hatkyinc2]

1.8.0-beta2 same issue, the max volumetric flow doesn't seem to matter if you put speed up, can get to crazy numbers over

[hatkyinc2]

I found a similar bug in superslicer and it seems correct and provides some insight https://github.com/supermerill/SuperSlicer/issues/3869 Basically, flow multiplier/ratio is applied to max volumetric flow 🤦 So one should divide the required max volumetric flow by the flow ratio to get the desired result. This trick works for me. not saying this isn't a bug of sorts as it's unintuitive and unclear

[edooman]

Same here on many models, Volumetric test is affected too with abnormal behavior. Orca ver. 2.0.0 dev

[github-actions[bot]]

Orca bot: this issue is stale because it has been open for 90 days with no activity.

[github-actions[bot]]

Orca bot: This issue was closed because it has been inactive for 7 days since being marked as stale.

[DearTanker]

This error still exists in the latest version of OrcaSlicer V2.1.1 Official Release

[jeffalanmcclain]

Is it possible that you have "don't slow down outer walls" checked too? I seem to see this significantly cause external walls to print with faster flow (I think there is not a way to limit it then because too many parameters to obey)? If I uncheck this option, I can get it to significantly fall into the max volumetric flow rate (time flow ratio) on most areas. Dramatically lines up.

[stefansjs]

I just came to check this bug. I'm seeing this as well. I do not have "don't slow down outer walls" checked for this filament. I also calculated the flow rate based on my multiplier of 1.078, which should give me a maximum of 20 mm3/s if I limit to 18.4, but it still shows a maximum of 22.4

FYI, if the dev team doesn't have resources to fix these types of bugs in a timely manner, then you should consider changing the github actions behavior to not close these issues right away. This is an open source project without (IIUC) any institutional support/money behind it, so the ticket management probably shouldn't be the same as if you had a full-time development team, project managers, etc.