Live Extrusion factor control from LCD

[TehMillhouse]

I got fed up with powerlessly watching over- or underextruding prints turn themselves to mush. This lets you set a global factor for all extruder movements. This does also affect retractions (since there's no easy way of differentiating retraction from non retraction movements), so diverging too far from 1.0 will probably introduce some stringing, but since stringing is much easier to correct post-printing than overextrusion, this shouldn't be much of a problem.

[SaschaKP]

Interesting, have you looked at my fork? This is going to be merged there...I'll look at the retraction scenarios

[SaschaKP]

Merged it, I'll also test the live extrusion multiplier and see if I calculated correctly the positive vs negative extrusion values. Test it if you want.

[TehMillhouse]

I'm taking a look at it right now, and I think I now understand how retractions can be handled by this.
I see two minor problems with your approach as implemented right now:

1. To differentiate between true extrusions and reprime movements, you need a running tally. You can't reliably tell them apart simply based on current and last command.
2. Commands that combine reprime + extrusion will have both repriming + the extrusion scaled according to the extrusionFactor, instead of only the extrusion part.

Point 2) also applies when having "extra restart distance" set up in your slicer. This means when your slicer wants to do a retraction by 7mm, it will reprime with some amount !=7mm (both greater and smaller amounts can make sense). Your current code won't recognize that the first 7mm of that reprime are, in fact, just a repriming step, and scale it up/down.
For an example of 1), consider Simplify3D's "avoid crossing outline for travel movements" feature. Gcode generated with this enabled will include a retraction, then an arbitrary amount of non-extruder-movement (which will set lastFilamentPosition to 0), then an extrusion to reprime. Locally deciding whether a movement is retraction/reprime or not will lead to blobs or holes at the start of every layer, as the reprime gets scaled when it shouldn't.

So summarizing: to correctly handle retraction/repriming when applying an extrusion multiplier, we'd have to keep a running tally of how far up the heatbreak the filament currently is, and only scale those parts of movement commands that actually lead to extrusion.

That being said, even my simple version of live extrusion control has proven useful to me, and these caveats are edge cases.

(On a different note: You at some point merged and then reverted (part of?) my changes from #207. Do you mind putting the revert in its own commit? Then I could cherry-pick your branch and try implementing the running tally version without losing my part cooling fan 😅)

[SaschaKP]

Done, take a look, if you want to enable your method, instead of using the COOLING_FAN_PWM use the COOLING_FAN_PWM_ON_DISPLAY

Don't use both, as it won't compile 👍

As for the filament extrusion mods, you're right, effectively you reprime straight, but on pushing filament, it could blob or miss some material, the only way, as you said, is to check if we reprimed before via some variable (using small DIFFERENTIAL var in this case could be of use, I don't think that during a print you reprime tons of filament)

edit:
and we have two extruders and should take into account for both of them, small variable, like a small int16 should be generically sufficiently larger for this scope, so we use only 4bytes in the sram

re-edit:
also, the calculations are as this, if number is 0 we don't extrude nor reprime, avoid calculating (it's still an heavy task even if the number is ZERO), if it's negative we are repriming, positive extruding, we need to save the repriming and on extruding anything that exceeds the reprime, if not zero, is to calculate into your extrusion multiplier

[SaschaKP]

anyway, this question needs another post in here:

from what I understand, you're using simplify3d, have you tried my GPX code in my repositories? this is made especially for simplify3d, since they have that code closedsourced, i reversed their modifications and published the code, it currently works, since I'm using the same programme, and if you use it, you don't need your cooling_fan_pwm method...
Can you tell me if it currently works, if I understood everything allright?

[TehMillhouse]

Ok, I've added the logic for ignoring retractions and reprime movements. (I haven't tested it yet, since I'm not anywhere near my printer.) I'm now keeping track of the current amount of retraction in a uint16_t per extruder.
(Since we both touched this part of the code, this patch doesn't cleanly apply anymore. I'm in the process of rebasing your master so the changes are orthogonal again, and will open a pull request on your fork once I'm done.)

Overflows/signedness errors will only happen if the retraction values involved exceed 16 bits worth of steps, which should never happen in any realistic setup (even with a geared extruder with a 1:3 reduction ratio, the math holds up to retractions of 20cm)

As for your fork of GPX: I initially considered doing the same, but I didn't want my printing setup to require modified software on both the host and the printer.

[SaschaKP]

using that gpx will remove the temperatures limit, for example I also use materials like this:
http://www.nanovia-technologies.com/scripts/files/57cee7071f2a64.52538345/pc-ptfe-alloy-ft-2.pdf

and it don't quite like the 120 fixed temperature of the HBP, it needs at least 125°C...the limit into the original firmware is 280 for extruders, 130 for HBP, but in the gpx distributed by simplify3d the limits are lower..guess why...