[3.6.0-beta.1] Heater feedforward not working

Kiolia

@droftarts Thanks! I figured that with all the 3.6.0 changes, it would have been easy for a link to something like feedrate to become broken, but it also seems like something unit testing ought to catch unless it's specific to a weird edge case like mine of the Extruder being the only aspect of extrusion not being controlled by the mainboard.

I appreciate your attention on this one. It's not quite a blocking issue for my use case but it's a significant QOL (and QOPrinting!) impact.

droftarts

@Kiolia I asked, and @dc42 replied that he couldn't think of anything, but would check the code.

Ian

droftarts

@Kiolia @dc42 has confirmed heater feedforward is broken in 3.6. Use 3.5 for now.

Ian

Kiolia

@droftarts Bummer, okay. Would it be (feed)forward (sorry) of me to ask if the fix might make it into the 3.6.0 release? Also, do I need to do anything to flag the forum topic closed/etc.?

dc42

@Kiolia yes we'll fix it before the 3.6 release, probably in beta 2.

Kiolia

@dc42 Legendary, thank you! I'll be watching for the next update and ready to test.

Kiolia

@droftarts @dc42 I hate to be a bother, but it seems related -- would it be possible for you to check the code that compensates for tool cooling based on the second K term set by M307? I have a growing suspicion that this isn't working, either.

Source/testing: I was hoping to use second K manipulation as a backdoor patch for missing feedforward, but after 30 minutes of testing, I can't see any difference in the temp drops or PWM reactions to a range of second K's from .05 to .485. In each test case, without moving the head (from 1mm Z), the application of full CPAP knocked temps down by the same amount (+/-5%), ramp to the new PWM level took about the same amount of time, recovery of the hot end to commanded temp took about the same amount of time, and stability of the temps after regaining commanded temp looked about the same.

I started doing diagnostics like sending M307 H1 to check the actual applied tuning values, then realized this was a little too similar to my last round of feedforward testing and figured I'd better ask.

One thing I did not test was un-selecting the tool and re-selecting it between M307's, if that matters.

The range of values I tested went from fairly lower than ideal to fairly higher. Most recent tune value, done tonight at the same toolhead location, was M307 H1 R3.181 K0.424:0.185 D4.11 E1.35 S1.00 B0. I have not changed my machine setup or firmware version since that described in the original post above. (Edit: and yes, the hotend is that efficient and windproofed. I've invested a lot of effort in optimizing thermal efficiency.)

EDIT 2: this testing was done in 3.6.0-beta.1. I cannot say for certain if it was working or not in -alpha.5+1. I believe it was working in 3.5.1, but at the time I wasn't running as aggressive of cooling profiles in any print tests, so it's hard to say. I've been having difficulties with updates, so I'd prefer not to roll back to verify behavior.

EDIT 3: I will also note that I did my testing with fan setting via the DWC fan controls, not by sending Gcode commands, if that matters.

chrishamm

@Kiolia I've identified and fixed a problem affecting the tools' heating rates which can occur when M106 Pnnn Snnn is used to update the current tool's fan value. It is no issue if only M106 Snnn is used.

Kiolia

@chrishamm droftarts asked me to test that (in the beta.1) and M106 without a P does appear to trigger cooling compensation behavior where the DWC fan controls do not. These were two ~1-minute CPAP bursts activated in those two ways:

chrishamm

@Kiolia That's fixed then. DWC uses M106 Pnnn Snnn to set specific fan speeds. If you select the tool fan slider, DWC sends M106 Snnn instead.

T3P3Tony

@Kiolia please would you confirm these issues are fixed for you in 3.6beta2

Kiolia

@T3P3Tony I will test as soon as I can on all issues noted.

T3P3Tony

@Kiolia thanks, appreciated!