phord/Teacup_Firmware — comment on commit 522b863ee80254b7870835856f2cd4748522ee52
File:  line 0
By phord:

What do you think of this patch to handle E overflows?

I need to look at it more than just this patch, but I haven't the time tonight. At first blush it looks a little contorted. I was thinking of something along the same lines, I think, but keeping an accumulated "integer mm base" that could be used to offset the absolute E value. This would be accounted for when reading the G-code, I think. I haven't looked at how the numbers are converted to integer-um yet, so this may be the wrong place to do it. But from outside the code, it makes sense to me.

The advantage to accounting for it as integer-mms is that the number would be very small and would not require any other scaled math to avoid further 32-bit overflow. So, for example, when the GCode E value goes past 1000.0000 mm, we could begin offsetting this value by 1000, effectively resetting our base position to zero again. It never makes sense, afaik, to have consecutive E targets that are 1000mm apart, even if we're counting extruded-mm instead of input-mm. So the 1000mm number seemed like a safe granularity to ignore.

For that matter, I guess you could even always consider E values to be (given-E)%1000mm (assuming you handle the roll-over), and you'll never go wrong, since (delta-e < 1000mm) for all reasonable increments of E.

Maybe this is what your patch is doing, but it's not clear to me on its own. I need to look deeper at the code to understand the context.