Remember to there is never a dumb question and you will never stop learning. The day you think you know everything is the day your ego has taken over.
@Brigham_Valdez Thanks for the advice. Always happy to learn. I thought I’d covered the filament side but maybe its just too humid in here!
adavidm
Trouble shooting … Assume nothing - question everything ! Guaranteed it will be the last thing you check 
Seriously though verify what you know and the possibilities decrease.
Well, ditto, that escalated quickly. A bit much on the chest beating, it looked pretty unprovable and narcissistic to me.
ThanatiK’s explanation makes the most sense to me. I’ve seen similar behavior in Cura’s infill. I forget what I did to solve it.
It must be hot in california.
@Brigham_Valdez I was wondering if you had a sense of humour. So you do. Good.
OK, confession time.
Under-extrusion was the issue after all. Steps/mm all ok in both firmware and eeprom. Unfortunately, the idler bearing was binding in it’s mount, forcing the extruder to work extremely hard and either skipping steps or grinding on filament(not really sure which). This only came to light after running a test piece and comparing measured v actual consumption. There was a 30+% difference.
After fixing the idler and re-checking the filament consumption everything is working fine. As a bonus, The first layer looks a lot cleaner now, better than ever before, in fact. I’ll post a photo later to show the difference.
What surprised me was how uniform the under-extrude was, I would have expected it to be in fits and starts rather than a fairly consistent under-run.
Thanks for all the advice.
adavidm
It’s annoyed me enough that I’m looking at designing an encoder that tracks the rotation of the idler.
“The more complicated the plumbing the easier it is to plug the toilet” - Chief Engineer Mr. Scott, USS Enterprise. I think you would be adding more complexity without a real need. If it was part of a real time filament monitor that determines the volume of material that others are working on … okay, but not just for this one odd failure mode.
You are completely correct. Might be a fun exercise though. I’ve seen commercial bearings with built-in encoders. Price On Application, mainly, so probably expensive…
Something like this, but smaller, might also work:
That kind of closed-loop motion control is very cool. Using a DC motor+Encoder motive system for a 3D printer would be a really neat trick. I assume machineKit can already drive them, it would just need someone to put a printer based on one together.
Hmm, here is one. Not sure the results justify the complexity, or the price. But it exists: