Sorry, guys. For some reason I never got a notification about any replies to this.

Just to clarify what I was talking about, the behavior I was claiming was a bug was not the lack of resumption of waiting for the heater. My work around would fix that particular problem.

The bug was that the system resumes on the gcode statement after the one that was executing when the fault happened. That means, in practice, a gcode is going to get skipped. In my example case, it was an M190, but any command that failed during execution would be skipped.

In programming parlance, it'd be like a return-from-interrupt incorrectly incrementing the program counter when pulling it back off the stack, causing an instruction to be skipped. Sure, you could say "hey, I'll just add the instruction that's being skipped into my ISR", but that's not really addressing the issue.

Sorry, guys. For some reason I never got a notification about any replies to this.

Just to clarify what I was talking about, the behavior I was claiming was a bug was not the lack of resumption of waiting for the heater. My work around would fix that particular problem.

The bug was that the system resumes on the gcode statement after the one that was executing when the fault happened. That means, in practice, a gcode is going to get skipped. In my example case, it was an M190, but any command that failed during execution would be skipped.

In programming parlance, it'd be like a return-from-interrupt incorrectly incrementing the program counter when pulling it back off the stack, causing an instruction to be skipped. Sure, you could say "hey, I'll just add the instruction that's being skipped into my ISR", but that's not really addressing the issue.

I was going to put a bug report in for this, but the prompts in github said to post in the forums first. I'm pretty confident this is an incorrect behavior.

Its pretty easy to reproduce...

• Start a print
• Wait on a tool or bed to hit temperature via M190
• Trigger a temperature fault
• Clear the fault
• Resume the print
• Note that the resume happens on the next gcode, and the print does not wait for temperatures to come back up

This happens to me pretty frequently, because I have a 120v bed heater on a separate power switch, and I invariably forget to turn it on when I first print something in a given day. After clearing the fault, and resuming the prints, the system just continues as if the bed was already to temperature.

I'm assuming this happens because, in normal operation, a pause occurs at the end of a gcode operation so you wouldn't want to continue, but in the case of a long-running one where the system and not the user triggers the pause, you really want to restart the long-running gcode.

My first thought, as a work-around, was to just put an M116 in the resume.g, but the fact that its not there by default makes me wonder if that's a reasonable work-around.

So, a couple of test results:

• Single wall cubes print with the correct extrusion width, to .01mm
• Dual wall cubes print just as accurately
• Cylinders also print accurately (which, I think, rules out rounding issues with extrusion amounts, because they use lots of moves, not just a few)

Speed didn't vary the over extrusion, either -- prints printed at 20% are dimensionally identical to one printed at 100% at the same flow rate.

Interestingly, the test cubes seem to oversize slightly more than the cylinders do, which makes me wonder if its more of a problem with long move/extrudes not short.

I've even tested with and without hardware retraction (I usually print with), and the results are generally identical. Its bizarre. (This is because there's only one retract/deretract per layer on a single wall test cube, but many on a "normal" part.)

Lastly, I tested with and without mesh compensation, in the theory that mesh compensation could be causing a tiny squish that is causing the perimeter extrusions to be slightly too wide. Again, no difference. (Which isn't too surprising, as the compensated variance is less than .02mm), which wouldn't cause a nearly 50% over-extrusion.)

Even stranger, the test model I've been using, if I print it with 0 infill, still is oversized, but if I print with 0 top layers so I can measure the walls, they are correctly sized, in terms of thickness. Its just the space they're enclosing is slightly too big. That screams slicer to me, but prints sliced years ago are printing larger, too. And its not a sudden X/Y step calibration (which, of course, can't really vary, anyway) because if the steps were off, inner holes would also grow, not shrink.

I've even done extrusion tests in gcode doing 10,000 .01mm extrusions for the 100mm test, and 10,000 .01mm extrusions in a 1mm zig-zag to see if there's any variance in extruded volume during small steps and during movements. There was none, to the accuracy of my scale and calipers.

Hell, I've even replaced the nozzle, although a worn nozzle usually looks like under extrusion, not over extrusion.

That's why I was asking anyone had figured out the problem, because it appears to be something that has happened to multiple people in very consistent ways, which suggests its probably something stupid.

@GeneRisi -- I don't use paper to calibrate Z-height, I use feeler gauges. The z-height is precise. And, regardless, if it was off it'd only impact the first layer and things like bed adhesion, not a 20mm tall test print.

@phaedrux said in massive overextrusion, E-Steps are calibrated:

If you suspect it's the firmware update, you could always roll back to confirm.

I've been hesitant to do that, because the last time I did a comprehensive calibration was before the RTOS update, so its a major reconfiguration to downgrade. I've been using the printer constantly since the, but I haven't printed anything where a) accuracy was critical and b) I know for a fact the parts used to print fine, because I'd printed them before, until last week. I have a 2-3 year old cable chain on my printer that has sagged from time and ambient heat (PLA was a mistake above a heated bed), so I was reprinting it. That means I know the gcode was fine, and that the parts (when originally printed) were sized exactly right.

At this point its more of a head scratcher than a huge problem -- I can reprint the chain at 65% to get past that, but it doesn't explain what the regression is.

@generisi I'm 100% sure the extruder is accurately tuned to within, as I said, at least a half percent. Verified both by linear extrusion distances and milligram weight. (Ie, cut 200mm of filament, weight it on the kind of scale Snoop Dogg likes to use, extrude 200mm of filament and compare the weights... within the accuracy of the scale -- +/- .005g -- they match.

The extrusion test in the gcode is a good idea, however the "where it is" is unlikely to be an issue as much as "how its being extruded". A simple "G1 E200 F100" is not necessarily the same as a thousand "G1 X.001 Y.001 X.1", or something even smaller.

I had, for a while, a hypothesis that it was rounding related, but that would suggest smaller details would be dimensionally inaccurate, and big straight extrusions would be okay, but that doesn't appear to be the case.

My current hypothesis is that its something in the infill extrusions pushing out the perimeters slightly, but the differences are remarkably similar regardless of how much infill or how the sizes of the parts vary. There appears to be, consistently, around a 1/8 extrusion width oversize on a perimeter, growing very slightly with the size of the "infill" between them. So a 2mm wall will end up being about 2.12mm wide, a 5mm might be 5.16 and a 20mm tends to be more like 20.2. Strangely, single wall extrusions seem fairly dead on -- a .45mm single wall will be damn near .45mm.

The size of the space between is a bad variable to put much weight into, because that could be volume of plastic, but it could also be speed related, as the printer has more time to accelerate. I'm actually running a test right now with the max volumetric rate turned down 80% to see if there's any variance.

I've been testing the last few days, while trying to figure this out, using this model, which is nice for both varying widths and depths of parts. It makes it easier to see if the oversizing is consistent regardless of X/Y/Z size, what's around it, etc.

@hadtstec I, too, am having this problem. Did you ever figure out what was going on?

I think it corresponded to upgrading my printer to RRF 3.3, but I'm not entirely positive about that.

Basically the same underlying issue -- my printer is severely overextruding in prints and parts are dimensionally inaccurate if I don't set my flow rate to ~65%. Happens regardless of filament type or brand, temperature, etc. Extruder is calibrated to within a half percent, based on both a 200mm measurement into it and weighing raw and extruded filament with a ~5 milligram-accurate scale. (Thus within a half percent -- 200mm of filament is about .53g, and with my scale it could be off by a little, but a half percent is within the error bars of filament given inconsistent diameters, anyway.)

Its a head scratcher -- its behaving like the firmware is doing something different with extrusions while printing vs via the web interface. It doesn't seem to be slicer-related, as the exact same overextrusion is happening from Cura, PrusaSlicer, and SuperSlicer. Pressure Advance doesn't impact it, nor does input shaping.

I've been running out of variables to tweak, and as of yet I haven't found any hints where its coming from.

Re: G30, yes. That's what Z-homing is. Printer won't do anything without being homed, so yes, its Z-homed before creating the height map.
No baby stepping.
Printer running as it boots up. Should have no mesh compensation.

To be clear, I can make lots of guesses as to what its doing and why. I'm asking how it works. I could go digging into the code, but the odds are there's people familiar with the code who can explain exactly how it works.

I'm scratching my head here. I've noticed this before, but something went wonky on my printer this week and I've been trying to figure out why my first layers are all screwed up. So I noticed it again, and it was weird enough to ask about ...

What in the world is considered "zero" height on the printer, with regards to the mesh compensation and heightmap probing?

My printer z-probes at the center of the bed, which establishes the "default", using a capacitive sensor. (I used to use a BLTouch, which has only slightly more reproducibility than a dice roll, so this issue wasn't as obvious until I switched it out.) When I run the mesh compensation to generate the heightmap, I would expect that point to be zero by definition, and anything any lower would be negative, and anything higher would be positive.

That isn't the case. For example, my last run had it at 0.055mm. (In fact, the entire bed was positive, if slightly!?)

Now what I find especially concerning about that, is if that "prime" probe point isn't reading zero in the mesh, it means Z-homing will deliver a different height from the bed depending if the mesh compensation is enabled or not. That then throws off the entire map. Z-home->enable mesh->print will result in a different output, as far as I can tell, than enable mesh->z-home->print.

I can't find any documentation that explains how everything is supposed to properly work. Like should we be disabling the mesh compensation in the homing files? And where should the zero point be on the map?

Does mesh compensation actually turn off the mesh compensation when it runs? (ie, does G29 S2 -> G29 result in the identical output as G29 S1 -> G29?)

@fcwilt For what its worth, the default files created by RepRapFormware Configuration Tool do not configure it that way. They have M561, G29 in bed.g, and do not have a mesh.g.

Where did you see that its should be the other way? Given the RRF Configuration Tool is the "official" way to set up the configuration, what you're saying seems to not be in alignment with the recommendations.

@streamliner said in Palette 2 / Canvas Hub Announcement -- Duet compatible?:

The active mechanism they have devised for mixing seems like it would work; but

There's no active mixing, or any ability to mix at all with the Palette -- it just snips and fuses filament. Its completely binary, all of one of the four input filaments.

You need a mixing hotend like a Diamond to get any blending at all.