Heater Fault + Odd behavior.

rflulling

Or did you mean M301 versus M307?

The M305 is configured and installed by the configurator. M303 was run after successful firmware boot and primary Stepper Motor configuration, and the result is stored automatically in the override config. M307 and M301 as listed below are commented out as they are NOT part of my config. However their setup is based on data pulled from the M307 H1 command entered through line terminal. Thus it would seem that M307 and M301 are redundant, or depreciated by other commands and or operation of firmware. Deliberately adding them back in seems like it may not be needed and may cause unforeseen issues. I think, I should assume that at this point other than for trouble shooting, I have no reason to use these commands normally.
-Please note OP.

M305 P1 T100000 B4388 C7.060000e-8 R2200 ; Pre configured by RRF
; M307 H1 A263.4 C98.1 D1.8 B0 S1 V24 ; Hand assembled based on echo from M307 H1 command
; M301 H1 P20 I0.5 D100 ; Hand assembled based on echo from M307 H1 command

Also, if I have never used M301 and M307, adding these commands to the Configuration will not cause any harm to existing settings?

Does any of this effects the original observation.?

Phaedrux

M307 is certainly not deprecated. It's highly recommended that you auto tune the PID values for the heaters and use the M307 to have those values saved for the firmware.

rflulling

@phaedrux

Yet, when asking the Firmware what it's stored values are, by sending M307 H1, it has no issue in replying a completely correct answer without M307 or M301 having ever been configured.

M307 H1 
Heater 1 model: gain 263.4, time constant 98.1, dead time 1.8, max PWM 1.00, calibration voltage 24.0, mode PID, inverted no, frequency default 
Computed PID parameters for setpoint change: P36.9, I2.779, D46.5
Computed PID parameters for load change: P36.9

Phaedrux

@rflulling Did you happen to save the results of the tuning using M500? They would go into a config-override.g which gets loaded by M501 in config.g.

@rflulling said in Heater Fault + Odd behavior.:

Yes this I do and is stored in the override config.

rflulling

@dc42

By the way, just to see what would happen, to see if I could generate a fault on command. Sent command, M307 A1500 H1, and got a very stern warning from the firmware:

M307 A1500 H1
Warning: Heater 1 appears to be over-powered. If left on at full power, it's temperature is predicted to reach 1525C.

I suspect the random fault that I experienced is generated by the momentary spike in power that I see on screen, via the web interface after each reset. -Perhaps this is a clue to generating a fault on demand for testing?

rflulling

Correct, I store the results in Config-Overide using M500 and do not mess with them in any way.
-Ahh I see they are set using M307. Though no sign of M301.

Ok some of this paradox is resolved.

@phaedrux said in Heater Fault + Odd behavior.:

@rflulling Did you happen to save the results of the tuning using M500? They would go into a config-override.g which gets loaded by M501 in config.g.

@rflulling said in Heater Fault + Odd behavior.:

Yes this I do and is stored in the override config.

dc42

@rflulling said in Heater Fault + Odd behavior.:

I suspect the random fault that I experienced is generated by the momentary spike in power that I see on screen, via the web interface after each reset. -Perhaps this is a clue to generating a fault on demand for testing?

I doubt it, the heater will be off at reset.

rflulling

@dc42
@JamesM
@Phaedrux

Thank you for each in following up with this report.

I am confirming what seem to be a BUG and it's behavior is repeatable though I am not sure the full scope.

IF, heater core is in FAULT state, and commands are sent over USB, they will immediately be executed ignoring delay for warmup.
IF, heater core is in FAULT state, and a file is loaded from SD card and executed, some errors will be output on screen, delay for warm up is ignored, and commands will be executed without further error.

dc42

@rflulling said in Heater Fault + Odd behavior.:

I am confirming what seem to be a BUG and it's behavior is repeatable though I am not sure the full scope.

IF, heater core is in FAULT state, and commands are sent over USB, they will immediately be executed ignoring delay for warmup.

That's to be expected. The Duet will send error messages back to the USB port, but it's up to the USB host program to do something about them.

IF, heater core is in FAULT state, and a file is loaded from SD card and executed, some errors will be output on screen, delay for warm up is ignored, and commands will be executed without further error.

That could be changed, I think it would be sensible for the firmware to refuse to print a file from SD card if any heater is in the Fault state.

rflulling

@dc42 so you would prefer to make the behavior different for direct and WDC? Why?

Just fix the firmware code so that it says something like:
IF heater is in FAULT state, do nothing. ; Prevents start up of machine in FAULT.
IF heater is in FAULT state, and M564 S1 H0 sent, then unlock. ; Allows movement for servicing.
My point in giving the details was not to highlight function diffrences just observations. However the underlying mechanism in the code, in the firmware is the same regardless of the subset performing operational commands. Be it a function of WDC or USB. The part of the code in error is at the core of the firmware, the actual machine controller code that listens for an instruction.
My point is that regardless of where the instruction is coming from the controller should be saying:
Hey Operator! We have a problem! You need to fix the Heater before we can continue!