Flow rate colors need binning #42

ednisley opened this Issue Mar 27, 2016 · 1 comment


None yet

2 participants


Issue #28 mentioned that the flow rate colors can be hard to distinguish, but there's also a problem of too many colors:

g-code viewer - excessive flow rate detail

That list isn't useful, because each color represents eight flow rates that have widely different numeric values.

Would it be possible to use only eight (or so) unique / garish / high-contrast colors per layer, with each color representing a group of "similar" flow rates?

For example, the 68 (!) different flow rates for that layer range from 1.430 to 3.118. Divide their span by (number of colors -1) to get the bin size, then assign the colors accordingly:

g-code viewer - binned colors

Using fixed-size bins, as in the first column of colors, may skip some colors, because those bins may be empty.

You could assign a fixed number of flow rates to the same color in order, as in the second column of colors. That would produce variable bin sizes, but the different colors would indicate the general trend of flow rates.

The general idea is to make the colors correspond to a meaningful range of flow rates, so that the preview will reveal the problem I'm having: too much plastic in the first layer. Is it a slicer setting or a printer misalignment?

The same color logic would improve the extrusion/move preview, which has a similar tendency to showing hairsplitting numeric details.

Thanks ...


This is a useful tool to me as well, and I agree with you that the color range is not useful.

I would say a continuous black-blue-green-yellow-orange-red-purple gradient (i.e. similar to a weather radar display) is a better idea, with black remaining the lowest-valued color.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment