@dc42 yeah it is only ever the bottom sensor that exhibits that behavior. I am fairly confident my connector crimps are good as I have tried to shake/shimmy the harness around while heated and attempted to recreate the readings but they were stable. I just hate that the problem is so inconsistent and hard to replicate. I will start by replacing the sensor and double checking my connections on both sides and see if that fixes the issue.

Ok, this has now been resolved (at least on one printer. Will test on the others once I have rewired them).

To fix the issue, had to update firmware and rewrite the stop.g and cancel.g files. Guessing issue was somewhere in the old firmware or in those configs.

Updated to RRF3.4.4 (Sorry, the printers were in storage for months).
Cleared all entries in stop.g and started over.
Then found it would throw the heater fault on cancel.g but is now fine on stop.g.
Cleared cancel.g, then rewrote it calling stop.g with a couple calls before and it works now too.

On another topic, also found on very rare occasions to be breaking contact on the connector, even with new wires, new molex connector crimped, and new senso with appropriate connector. I have found this can be averted by fixing the connectors so they are not free to move around. ...I need to revise my cable management.

@steviegregory said in Can’t store heater fault details in returned message:

@owend Is it possible to do this on RepRap 3.1.x, before the addition of events in RepRap 3.4?

No.

@vandermeulen said in heated bed temperature fault:

@engikeneer Okay, I hadn't found the M143 command. Let me try.

While you play with M143, you can loo at the heater's monitors in the DWC object model section. It will show you the internal affect of your M143 on the RRF internal configuration.

@dc42 and @engikeneer,

Hello, thanks for the input and suggestions. I finally got the thermistor back in, and the hotend assembled. I kept running into issues, broke the heat break, the heater cartridge looked a little frayed and ended up getting the precision cartridge. So I replaced more than just the thermistor. Here is the new graph for the autotune this time around.

updateTempChart.png

On to the next issues. Again thank you.

@Phaedrux :
I solved my problem, I add the command M501 at the end of my config.g.

I use in my Duet2WiFi the firmware version 3, RepRapFirmware Configuration Tool v2.1.8.

I made the autotune in the BED and I add the Heater model parameters at the config-override.g.

Now it's working well, thanks for the support.
thank you for your support. I read your previous recommendations on the topic.

@Phaedrux No. well below thresholds. The issue has been solved and noted in my above statement. Thanks

@dc42 Interestingly it did however I assumed you suspected that the values were either not applied / were overwritten.

It turns out there was already a line in the config file specifying the parameters that occurred later that where I had included the correct ones. This was overriding the values and seems to have been what was causing the issues.

Needs some testing to be sure but it seems likes its running smoothly again.

Thanks for all the help guys!

I swapped the termistor with another new one and so far it's been holding steady!

Hopefully that was the problem.

Set up your extra thermistor as a virtual heater using M305, then use M143 to monitor it. See https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M143_Maximum_heater_temperature.