Flow rate colors need binning

[ednisley]

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

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:

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 ...

[VanessaE]

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.

[VanessaE]

Is this ever going to get fixed? come on guys.

[dartrax]

This is really annoying. In fact, the "Extrude speeds in mm³/sec"-info is nearly unusably in my opinion.

I was looking for a quick&dirty way to fix it to be able to get mm³/sec for a specific gcode i'm working on. It is far from perfect, but with a few simple steps, you can use it for yourself:

1. Click the green "Clone or Download"-button and "Download ZIP" to get your copy of the files.
2. Extract to any folder you like.
3. Put a textfile in it, call it "start.cmd", and save the following command line: start chrome %~dp0index.html --allow-file-access-from-files --user-data-dir=%~dp0Chrome-TEMP\
4. Open \js\renderer.js and insert this line after line 286: speedIndex = Math.round((renderOptions["colorLineLen"]-1)* ((extrusionSpeeds[speedIndex]-Math.min.apply(null, extrusionSpeeds))/(Math.max.apply(null, extrusionSpeeds)-Math.min.apply(null, extrusionSpeeds))));
5. Open \js\ui.js and go to line 101. Insert a new line var extrusionSpeeds = GCODE.gCodeReader.getModelInfo().extrusionSpeeds;
6. Go to line 115. Replace if(speedIndex > colorLen -1){speedIndex = speedIndex % (colorLen-1);} by speedIndex = Math.round((renderOptions["colorLineLen"]-1)* ((extrusionSpeeds[speedIndex]-Math.min.apply(null, extrusionSpeeds))/(Math.max.apply(null, extrusionSpeeds)-Math.min.apply(null, extrusionSpeeds))));
7. Save everything and open start.cmd. It will launch a new chrome instance that has access to the javascript sources by the --allow-file-access-from-files flag. Now it will look like this:

I know it's not perfect but usable. If anyone has the time to improve the math, please do it. You can't say you didn't know how to start ;-)

Currently it takes the values of all layers into account, this is why you do not see all 8 available colors in every layer. To fix this, one needs to replace extrusionSpeeds[speedIndex] by extrusionSpeedsByLayer[z][speedIndex], I think...

PS: For convenience, the whole thing is attached as gCodeViewer-master.zip. Download, extract, "start.cmd", enjoy.