Alright, I'm at my wits end. Is there a bug with pressure advance?

Board: Duet Maestro 1.0 (duetmaestro100)
Firmware: RepRapFirmware for Duet 2 Maestro 2.05.1 (2020-02-09b1)

Yes old firmware, just haven't felt like learning new firmware mid-build and it does everything I need.

Anyway, here's the problem:
Tuned e-steps, no problem. Tuned flow % in slicer, no problem (94.3%). Decided to tune pressure advance, did that (~300mm Bowden, landed on S0.4 for the PETG I usually print).
So then I do a quick print, and it fails. Nozzle caught the print, shifted the bed. Don't think twice about it, made sure I had z-hop, slowed it down, reprinted. Print finishes, but it's pretty ugly. Top surfaces clearly show overextrusion, and (it's the tolerance test piece from the Cura plugin) all the cylinders are welded into the part.
I had already printed this before tuning pressure advance, everything was free except the 0.2 (aka, 0.1mm wall to wall clearance)).
Odd.
Checked slicer settings, all fine.
Decided to print my flow % tuning model (Made a piece where the perimeter length = 1 full rotation of filament drive gear).
With no pressure advance, the walls come out 0.39-0.42. With pressure advance they come out 0.42-0.45.
So ~7.5% overextrusion. Very odd, but also didn't really match the tolerance piece over-extrusion. It was visually worse, and the dimensions of the part went from 60x12 (+/-0.05) to 60.3x12.3.
I re-sliced the part to have only bottom surfaces and 3 walls. Printed with no pressure advance, 1.2mm walls. Printed with pressure advance, 1.5mm walls!! And that matches the 0.3mm the model grew.
Just to validate, I re-sliced with flow at 72%. No pressure advance, the part barely stays together it's so under-extruded. With pressure advance, the model prints perfect. The cylinders are less oval by a couple dozen micron, everything is dimensionally accurate, and even the 0.2 is free.

So the only thing that comes to mind is the pressure advance implementation has a massive bug. And it wouldn't be that bad if it was consistent. But since the overextrusion is varying between ~7% and ~25%, I have no option but to keep it off.

Anyone ever seen this behavior or have any thoughts (besides fiddling with firmware versions)?

@mrehorstdmd Fascinating. Appreciate the feedback. That makes me curious about whether I should try some different models to see if it's consistent across them. If the single-wall extrusion case is the only deviation, I think I'd live with it.
Is it safe to say you've tried both single-wall (non-vase) and regular parts, and 85% works well for both?
I also haven't played with how extrusion rate might affect it. So far in my testing, I've stuck with a tortoise-like 2.4mm^3/s just to limit whatever nonsense may crop up at higher flow.

So far I've tried rolling backwards to 2.04 firmware, and the behavior is the same there. Currently running a print on 2.02b firmware to see if it's still there.
If it's the same there, I think I'll try pursuing your thought of verifying it's consistent across the 'normal model' scenarios, and maybe just live with that. I'm quite happy with the machines output without pressure advance, it's just that 'chasing tenths' mentality, knowing that round pieces come out slightly more round than oval, and the seams are marginally less visible that has me irritated. That and just the stubborn desire to understand and conquer the problem haha.

Alright, I'm at my wits end. Is there a bug with pressure advance?

Board: Duet Maestro 1.0 (duetmaestro100)
Firmware: RepRapFirmware for Duet 2 Maestro 2.05.1 (2020-02-09b1)

Yes old firmware, just haven't felt like learning new firmware mid-build and it does everything I need.

Anyway, here's the problem:
Tuned e-steps, no problem. Tuned flow % in slicer, no problem (94.3%). Decided to tune pressure advance, did that (~300mm Bowden, landed on S0.4 for the PETG I usually print).
So then I do a quick print, and it fails. Nozzle caught the print, shifted the bed. Don't think twice about it, made sure I had z-hop, slowed it down, reprinted. Print finishes, but it's pretty ugly. Top surfaces clearly show overextrusion, and (it's the tolerance test piece from the Cura plugin) all the cylinders are welded into the part.
I had already printed this before tuning pressure advance, everything was free except the 0.2 (aka, 0.1mm wall to wall clearance)).
Odd.
Checked slicer settings, all fine.
Decided to print my flow % tuning model (Made a piece where the perimeter length = 1 full rotation of filament drive gear).
With no pressure advance, the walls come out 0.39-0.42. With pressure advance they come out 0.42-0.45.
So ~7.5% overextrusion. Very odd, but also didn't really match the tolerance piece over-extrusion. It was visually worse, and the dimensions of the part went from 60x12 (+/-0.05) to 60.3x12.3.
I re-sliced the part to have only bottom surfaces and 3 walls. Printed with no pressure advance, 1.2mm walls. Printed with pressure advance, 1.5mm walls!! And that matches the 0.3mm the model grew.
Just to validate, I re-sliced with flow at 72%. No pressure advance, the part barely stays together it's so under-extruded. With pressure advance, the model prints perfect. The cylinders are less oval by a couple dozen micron, everything is dimensionally accurate, and even the 0.2 is free.

So the only thing that comes to mind is the pressure advance implementation has a massive bug. And it wouldn't be that bad if it was consistent. But since the overextrusion is varying between ~7% and ~25%, I have no option but to keep it off.

Anyone ever seen this behavior or have any thoughts (besides fiddling with firmware versions)?

@fcwilt I was also surprised to find an issue that sounded similar to mine considering the user had completely different hardware and firmware to me. But hey, glad I looked, helped me fix my issue. Maybe it'll help someone else

@dc42 That I can confirm, it was the exact same code that ran at start-up, my macros just happened to call it multiple times throughout normal printer operation after initial power on (It lived in a file called printer_bedmesh.g, which was called by config.g on startup, but also by homez.g, homeall.g, and bed.g)

And when I was narrowing it down after your question, I literally just powered on the printer, sent M401, M402 to confirm operation, then sent M558 P9 and M401 and M402 no longer responded.

@fcwilt Yes, it was the full config code for the sensor. My config.g only calls macro files, all of them printer_"something".g related to whatever I am defining (I prefer the organization that way) And in printer_bedmesh.g I had the configuration for the probe, which was:

M558 P9 H5 F240 T5000 A4 S0.005 R0.2 B1 ;BLTouch probe (p9), h = dive height, f=z speed, t=travel speed, A=max # of times to probe, s=deviation allowed, r=recovery time, b1=turn off heaters
G31 X-43 Y-5 Z2.102 P25 ;Define the X,Y,Z-offsets of the probe,P=trigger value (25 for BLTouch)

All of my homing sequences (as well as bed.g) call this file to restore the saved heightmap after completing. I set it up that way because when this printer was in its previous barbaric state with no probe, I had set up different heightmaps by temperature, and wanted a centralized place to change the name of the heightmap I wanted to call and it affect everything at once.

I simply moved the probe definition into my printer_tools.g file and all is working as intended.

But after dc42 asked his question, I did some tooling around. All of the other M558 parameters (and M558 on its own) do not negatively impact the probe. It is when I send M558 P9 that makes the probe unresponsive.

@dc42 I sure am glad you asked the question, and I went to confirm before replying.
Clearly I had jumped to some conclusions when first attempting to narrow down the problem and provided an inaccurate report. Here's an update:

Neither G29 nor G30 seem to 'bug' the sensor. Putting them into a macro which simply runs G29, a G0 move, then a G30, also does not 'bug' the sensor.

So I dug deeper and found the cause (at least of my issue, do not want to speak to the problem @ctilley79 has)

My issue was caused by a macro I had which called bed settings after performing things like homing functions, etc.
I went through the commands one by one and found the culprit. It is the M558 command.
For whatever reason, calling M558 P9 (I checked each of the other parameters individually, it's only the P parameter) at any point after the initial power-on reading of config settings, leads to the probe ceasing to respond until power cycle.

Thanks dc42, your pertinent question resolved my problem : D
Time to go fix the macros.

I have a very similar problem, but much easier to replicate, and on different hardware and firmware.

BLTouch will work and deploy flawlessly when I first power on the machine. But as soon as I have used it in a macro (so if I do a G30, or I run a macro to square my gantry, or I run a bed mesh) it will stop responding to commands.
So it will do G30, it will do G29, but only once per power-cycle, and per macro. As a test, I modified my home z to home ( I have a limit switch), probe by my lead screws to tram the gantry, g30 in the middle of the bed, and then G29 to mesh the bed. All of this completes flawlessly. But will only do it once. After it is done, probe doe snot respond to any M280 commands, M401 or M402 commands, nothing. And the blue PWM signal light on it is now out until power-cycle.

I cannot do what I described if I break up the sequence. So if I make a macro to just tram the gantry, I cannot do any of the rest afterwards.

I tried what was recommended earlier, and when on a fresh power-cycle, it will seemingly respond to M280 and M401 and M402 commands indefinitely (I literally pasted thousands of them into a macro and went to lunch, it was still working when I came back)

I wish I could tell you if this is some new behavior, but I have just purchased the BLTouch, and was setting it up for the first time
Oh, it's a BLTouch v3.1

I have it wired through the probe connection.
Configured as follows:

M558 P9 H5 F240 T5000 A4 S0.005 R0.2 B1 ;BLTouch probe (p9), h = dive height, f=z speed, t=travel speed, A=max # of times to probe, s=deviation allowed, r=recovery time, b1=turn off heaters
G31 X-43 Y-5 Z2.102 P25 ;Define the X,Y,Z-offsets of the probe,P=trigger value (25 for BLTouch)

Duet Meastro 1.0, Firmware 2.05.1 (2020-02-09b1)

Here's my issue.

Sometimes, and I haven't been able to determine for what reason, I'll upload gcode and it refuses to run. It will pretend like it's running, but the status bar will go extremely quickly (like it'll "finish" the "print" in like 10 minutes on a 10 hour print). But nothing will ever actually happen. The printer will just sit there.
I have occasionally been able to solve this by renaming the file to something like a single character. Other times I have been able to solve it by not uploading it to a folder and just to the main directory.
This particular file I have not been able to solve (despite actually being identical to another file, just at a different temperature).
I finally noticed that I could tell beforehand whether the file would print or not. The metadata for the file isn't being read by the Duet when this happens. Most of the fields read n/a

After re-uploading, power-cycling, renaming, re-slicing, etc. for kicks I decided to run the Simulation of the file, to see if maybe that would somehow fix it. The simulation also started extremely quickly, with no layer time estimation info, no coordinates changing as in normal simulation. Basically, it behaved exactly how trying to print the file would behave. Pretends to do it, but doesn't.
Then a few minutes into the simulation, I got an error. Error: Bad Command 3954

After this error, normal simulation began, with layer times and the amount of time it was taking was now appropriate.
I haven't seen anyone reference anything similar. I looked at line 3954 in the code (and the surrounding ones). There's nothing interesting there. it's just extrude moves.

Once the simulation ended, the print time estimate was filled in, but the file still doesn't work and the rest of the fields are still n/a. And when I went to a different folder and came back later, the Simulation time was n/a again (which isn't normal).

Again, this file is literally identical to another file which works fine, except the temp is 230 instead of 205. But it happens to some files, seemingly randomly.

Duet Maestro, Firmware 2.05.1 (2020-02-09b1), Web 2.0.7
However I've had this (or similar on the surface) problem on multiple firmware versions (last time I mentioned something I was running 2.02b and someone recommended I update). And on multiple Maestros (I own 4).

Thoughts?

Ok, I was just playing around before posting trying to get the file to work and noticing that some other files were also listed n/a, despite having no issues printing them when I first uploaded them. This reminded me that sometimes I would print a file the first time after uploading with no issue, but then when I go to re-print, I run into this problem.
Anyway, while messing with this I uploaded the current file into the main directory, and everything shows up fine, and I can print it fine.

But if I drag it into the Production folder (all others don't exhibit this behavior), the info fields go to n/a again. But now I can print it fine

After doing an E-stop, it doesn't know how tall the file is, but all the other fields are now filled in and it will print.
I deleted the file, re-uploaded directly into the Production folder again, and all fields show up and it starts printing fine.
I think it's haunted. At least I sort of understand how to work around it consistently now instead of messing with renaming. But it's still incredibly annoying.

@dc42 said in Duet runs pause.g prior to running trigger?:

Either use M591 to manage your filament monitor, or use a GP input pin and use M581. Not both.

Ahhh, that was my problem. Thanks for the clarification. The way I read the documentation, I thought that M591 just defined the switch (like an M574), and M581 defined the behavior. So if my understanding is correct, M591 is specific and pre-configured command for filament monitors which will always run pause.g when triggered, where as M581 is a general command for assigning a macro event to a switch input.

I think it would still be beneficial to note in the documentation of M591 that it runs pause.g on it's own. And while I don't have one, it leads to the question: what happens if you use M591 with a filament monitor which also keeps track of whether the filament is moving or not? Does it just run pause.g? Or is there a way to have it adjust extrusion multiplier to compensate for deviations in filament diameter and/or slipping?

@deckingman said in Duet runs pause.g prior to running trigger?:

Can you confirm that both pause.g and trigger2 both run when the switch changes state?

I confirmed this by including some beeping sounds at the start and end of both pause.g and my trigger2.g file. It was executing both, first pause, then trigger (which makes sense from the documentation)

@deckingman said in Duet runs pause.g prior to running trigger?:

Is the trigger macro in the macros directory?

No, it was just in my sys folder.

@deckingman said in Duet runs pause.g prior to running trigger?:

can you try using C0 just to see if the behaviour changes

I did not try this since dc42 explained where the issue was coming from. Based on my current understanding, the same thing would still happen.

Thank you all

No, no special reason. Just prefer stability. It worked and did what I wanted, so didn't bother changing.

Updated firmware, now running 2.05.1 (and tested the new DWC interface. Will probably get used to it on desktop, but my mobile devices thank you :D)

Tested the behavior, pause.g is still executed before executing trigger2.g