Gibberish/invalid feedrates in exported g-code

[VanessaE]

Describe the bug

Slic3r creates gibberish/invalid feedrates in exported g-code, in auto-speed mode, but only if the maximum volumetric speed is set high enough (and all line speeds set to "auto" of course). With the attached config, setting this below about 16.5 mm³/s, seems fine, but at 17 mm³/s it gets weird.

This glitch looks somewhat similar to issue #3295.

If you examine the attached g-code, you'll find lines like the following (line 22898):

G1 F241502
G1 X82.789 Y95.243 E8.82378
G1 X82.418 Y95.614 F24000.000
G1 F1.18123e+06
G1 X82.418 Y104.387 E8.82738
G1 X82.809 Y104.758 F24000.000
G1 F245484

I'm... pretty sure scientific notation is not allowed in G-code, and anyway it looks like some kind of math overflow, or maybe it's just not applying the configured max feed rate. Normal feed rates for this model are between about 10000 and 17000 mm/min, and should not exceed 24000 (the configured limit).

To Reproduce

1. load the attached config.
2. load a Benchy and slice it with that config
3. Export to g-code and load that into Pronterface, observe the projected print time, and/or compare with the attached g-code file.

3D Model and Slic3r Configuration Export

Model: Just a common Benchy.
Config: slic3r-config-20190328.ini.zip
Benchy sliced with the above config: 3DBenchy.gcode.zip

Desktop (please complete the following information):

• OS: Linux (Debian)
• Version: git commit 05a2f90 plus the bridge angle fix (Fixed that bridge angle is lost on shell layers #4743) and @supermerill's thin walls PR (Thin wall improvements (v2) #4534).

[lordofhyphens]

Looks like you hit a corner case in the auto speed math.
It would be interesting to me to see what kind of moves were following that speed change.

[VanessaE]

Judging by the E amounts, I'd have to say what I originally pasted was gap fill. That would make sense, as gap fill would normally trigger the highest feed rates when trying to maintain a constant flow. Here's some more context:

G1 F33507.1
G1 X71.503 Y100.652 E12.50153
G1 F45864.5
G1 X71.466 Y100.402 E12.50419
G1 F140415
G1 X71.439 Y99.914 E12.50588
G1 X71.456 Y99.714 E12.50657
G1 F54298.7
G1 X71.481 Y99.451 E12.50894
G1 F39137.9
G1 X71.488 Y99.395 E12.50964
G1 X71.529 Y99.338 E12.51051
G1 F52745.9
G1 X71.570 Y99.282 E12.51115
G1 F80860.6
G1 X71.611 Y99.225 E12.51157
G1 F187409
G1 X71.697 Y99.116 E12.51193
G1 F1.18123e+06
G1 X71.736 Y99.070 E12.51195
G1 X72.008 Y97.824 F24000.000
G1 F16651.6
G1 X72.008 Y98.215 E12.52333
G1 X72.254 Y98.070 E12.53164
G1 X71.857 Y97.673 E12.54798
G1 X71.857 Y97.163 E12.56282
G1 X72.613 Y97.920 E12.59397
G1 X73.028 Y97.825 E12.60636
G1 X71.857 Y96.654 E12.65459
G1 X71.857 Y96.144 E12.66943
G1 X73.523 Y97.810 E12.73804
G1 X73.885 Y97.864 E12.74871
G1 X74.187 Y97.965 E12.75798
G1 X71.857 Y95.635 E12.85395
G1 X71.857 Y95.125 E12.86879
G1 X81.982 Y105.251 E13.28584
G1 X81.982 Y104.741 E13.30069
G1 X71.857 Y94.616 E13.71774
G1 X71.857 Y94.106 E13.73258
G1 X81.982 Y104.231 E14.14964
G1 X81.982 Y103.722 E14.16448
G1 X71.857 Y93.596 E14.58154
G1 X71.857 Y93.087 E14.59638

[lordofhyphens]

I think we should force the speed to fixed-point instead of taking the default (with IIRC is engineering/scientific).