Heater Fault + Odd behavior.

dc42

@rflulling said in Heater Fault + Odd behavior.:

if some one would be so kind as to offer a way to cause a heater fault on demand without damaging the Duet Controller, or the Mosfet on the board. I would be happy to validate my claims. Beyond 1 observation.

You can cause a heater fault by setting the A parameter of the M307 command for that heater to a high value (but there is a limit, AFAIR it's 1500). The fault should be that the temperature is not rising at the expected rate.

rflulling

@dc42
You can cause a heater fault by setting the A parameter of the M307 command for that heater to a high value (but there is a limit, AFAIR it's 1500). The fault should be that the temperature is not rising at the expected rate.

I am actually not sure how to use the M307. Never used before and it is not in use right now.
-I will make effort to become familiar with these commands.

Most commands make a lot of sense. But the temp command parameters, are honestly over my head. Both M307 and M305. Though, the configurator helps a lot with M305. For me it's like Auto work, I can and will take apart and repair anything, except the Transmission, I will not touch the transmission.

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

So, if Variable A of M307 represents gain, then setting gain to 1500 will force a fault during warm up after heater activation, and will not cause any harm to the hardware?
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

This may help to explain the difference between M301 and M307.

https://duet3d.dozuki.com/Wiki/Tuning_the_heater_temperature_control

Each heating controller in RepRapFirmware 1.15 and later can work either in bang-bang mode or in PID mode. When operating in PID mode, it can get its PID parameters in either of two ways:

Use two sets of PID parameters computed from a first-order + delay time (FOPDT) model of the heating system. The FOPDT model parameters may derived using auto-tuning, or configured manually using M307.
Use one set of legacy PID parameters configured manually using M301. This provides backwards-compatibility with previous versions, and provides a fallback if the behaviour of your heating system cannot be approximated well enough by a FOPDT model.

And as the link goes on to explain, the best way to get PID parameters to use for M307 is to use the auto PID tuning routine provided by M303.

rflulling

@phaedrux

My question was more the difference in M305 (RRF Configured) VS M307

This may help to explain the difference between M301 and M307.

Yes this I do and is stored in the override config. Used to manually input the PID values after a report on the older Marlin based PCB for this machine.

And as the link goes on to explain, the best way to get PID parameters to use for M307 is to use the auto PID tuning routine provided by M303.

Phaedrux

@rflulling said in Heater Fault + Odd behavior.:

My question was more the difference in M305 (RRF Configured) VS M307

My understanding is that M305 is configuring the temperature sensor parameters so that the firmware is getting an accurate temp reading, and M307 is the PID parameters for tuning the behaviour of the entire heating model.

https://duet3d.dozuki.com/Wiki/GCode#Section_M305_Set_temperature_sensor_parameters

Or did you mean M301 versus M307?

rflulling

@phaedrux

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!