[3.6.0-beta.1] Heater feedforward not working

[Kiolia]

@droftarts As supplemental information, here are some FF-enabled PWM plots from 8/27 on 3.5.1 for comparison against the 3.6.0-beta.1 plots. Again, this is when it WAS working, because I rewired my machine. The FF-enabled PWM reactions to extrusion have very different profiles, and the lack of this behavior in the alpha and beta 3.6.0 builds is obvious from the plots.

[droftarts]

@Kiolia okay, sorry, I misunderstood, I think because you said the extruder was on a toolboard. One for @dc42 to look at. Maybe he made some changes to enable it on toolboards that have had unintended consequences.

Ian

[Kiolia]

@droftarts Understandable, no worries. I got overly stressed about this one because I thought I bricked my 6HC updating to the latest beta for testing (Bossa to the rescue, but idk what I'm doing wrong unless it's leaving the CANboard plugged in for the mainboard update), so I'm sorry if I came on strong

[Kiolia]

@droftarts I wasn't aware DC had done any work toward it. If so, is it possible a requirement was inadvertently added that E and heater/therm need to be on the same board? I could revert my wiring updates and re-test with heater/therm back on the CANBoard, if it would be useful. (I can't put E back on the mainboard, though; I'm out of drivers there!)

[droftarts]

@Kiolia Honestly, I don't know if he has or hasn't, I just don't know why there would be a regression in functionality between 3.5.1 and the 3.6 alphas and the betas. I can't find anything in the changelog: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta. I'll ask in the morning.

Ian

[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!