Feature request: Visualize fan speed in preview tab

[Boby71]

Version

1.41.2 Win64

Operating system type + version

Win64

Behavior

Please add the following feature: Visualize the FAN SPEED in the preview tab

Why: For some filaments (especially for tranparent PETg) and for analysis various problems (bad overhangs or bridges) it could be very helpful to know about the fan speed in the certain area (0-100%).

[ManuGithubSteam]

This is a very good idea!
Want that too :-)

[Budkudyba]

Came here to post this. +1
Could also be an indicator/predictor of layer adhesion strength.

[jschuh]

This should do it. It turns out it was a very straightforward change, although I don't know who I should approach about getting it landed upstream.

[Boby71]

@bubnikv , could you have a look at @jschuh 's addition? Thanks!

[jschuh]

If it helps, I tried to implement this in as small a change as reasonably possible. Nearly all the code is just plumbing and boilerplate, since the existing code already had all of the primitives for tracking metadata and rendering visualizations. So, it should be an easy review for anyone familiar with the visualization code.

About the only non-obvious decision is in tracking the fan ID in _processM106(), where I erred on the side of simplicity over a guarantee of accurateness.

[bubnikv]

Thanks. Please create a pull request from the code. I am currently reviewing other pull requests, so this one will be in the queue.

At the first sight, I am not excited about adding another data to the extrusion paths, I have to do some back of the envelope calculations on how it will increase memory consumption.

[jschuh]

The PR is linked above, but here it is again: #2922

I added fan_speed as a float to GCodeAnalyzer::Metadata because I interpreted that to be consistent with the existing code. However, it looks like I could easily reorder the members and pack extrusion_role, extruder_id, cp_color_id, and fan_speed into u8 bitfields, reducing the net size of the data structure by 24-bytes while still landing this change. And that's before analyzing any of the float/double use to determine if narrower, specialized types would be more appropriate. I've seen similar low-hanging memory reductions across the codebase; I could probably do some investigation and propose patches if someone would be willing to review.

Separate from this change (and apologies for bugging you here) I have a small PR up that's actually the reason I needed this visualization. It just adds an independent fan speed setting for external perimeters, and I would appreciate if someone could take a look at it: #2921

[mkbel]

It looks like it is implemented in 2.2.0, so this feature request can be closed.

[bubnikv]

great. closing.