Completely disabling heater short/fault detection?

[dc42]

1. Have you made sure that the thermocouple connections are electrically isolated from the metal parts of the bed and the hot end?

2. Which thermocouple daughter board do you have: the MAX31855 version or the newer MAX31856 version?

[k120]

1. Yes to both, and I'm not sure how I could isolate the hotend thermocouple further. The opening of the cartridge is not in contact with the block. I don't get shorts if just the bed is turned on.
2. I purchased it relatively recently from Filastruder, so I believe it's a MAX31856.

[dc42]

@k120 said in Completely disabling heater short/fault detection?:

I purchased it relatively recently from Filastruder, so I believe it's a MAX31856.

If it'a MAX31856 then it will have FAULT LEDs on the daughter board, and you will be using X150 or X151 in the M305 command to configure it.

The spikes in your temperature graph are mostly quite short, and if they were all like that then I would suggest interference from the extruder motor or static discharge as likely causes. Interference from the extruder motor wiring can be reduced by using twisted pair cabling for both the thermocouple (which I presume you are doing already) and the extruder motor (1 pair for each motor phase). Static discharge can be eliminated by grounding the hot end metalwork.

However, as one of the temperature spikes is longer (the one that caused the heater fault), and the spikes are triggered by high temperature, I agree with you that it appears to be a cartridge issue. I suggest you contact some thermocouple manufacturers and see if you can find an alternative mineral-insulated thermocouple that is guaranteed up to the highest temperature that you want to use. For example, a quick search produced this page https://www.elmatic.co.uk/thermocouples/ and style 11 on that page looks suitable.

I think the heater fault isn't being triggered by the temperature failing to respond to heater power as expected or changing too fast, which is what M570 controls. Instead, it is being triggered by the sensor repeatedly failing to provide a reading. The number of consecutive failures to provide a reading that is allowed is 4. You can increase that if you change constant MAX_BAD_TEMPERATURE_COUNT in file Config.h and recompile the firmware. The maximum allowed value is 255; any more than that and you will need to change the type of variable badTemperatureCount. The code that handles this is in file Pid.cpp, lines 202-225.

[fcwilt]

@k120 said in Completely disabling heater short/fault detection?:

E3D PT100

Would these be of use: https://www.adafruit.com/product/3895

It states they are rated to 500C and are suitable for the MAX31856.

Frederick

[dc42]

@fcwilt said in Completely disabling heater short/fault detection?:

@k120 said in Completely disabling heater short/fault detection?:

E3D PT100

Would these be of use: https://www.adafruit.com/product/3895

It states they are rated to 500C and are suitable for the MAX31856.

Frederick

This one https://www.adafruit.com/product/3245 looks more suitable because it has an insulated tip, however it doesn't say what diameter the cartridge is.

[k120]

@dc42

It's a MAX31856 then.

Something worth noting is that I swapped in my hotend for polycarbonate with an unused thermocouple, and it's been much more stable. Smoke came out of the cartridge on the first heatup to around 300 °C (I didn't notice this on the second most recent TC, as it initially heated up with my door closed and filter running), but it's evident that the extreme temperatures over 400 °C further damaged the others. This is the first out of four TCs I haven't shared between my PEEK and PC hotends, and it's the only one to work correctly so far.

I was planning on trying this next, but I'll give a custom TC or the Adafruit one (if the diameter is suitable) a shot if that doesn't work out. I don't fully trust the rating, but it's 3 mm and cheap.

I followed the instructions here, but I'm stuck building DuetWifiSocketServer and RRFLibraries. I'm getting the following errors/warnings and missing folders:

DuetWifiSocketServer:

RRFLibraries:

I've done some troubleshooting already on my own, but I have no experience building firmware. So I'm not sure how to fix things that aren't common searchable problems.

[dc42]

You don't need to build DuetWiFiSocketServer, but you need that project to be present because the RepRapFirmware project uses one of its include files.

Have you imported the FreeRTOS project into your workspace?

[k120]

@dc42
Yes, and it doesn't give me any errors when I build it.

I fixed the issues I was having by removing "-master" from the project names, as I had only renamed CoreNG. I've successfully built everything, but I don't know how to export the results into a ZIP to upload to my Duet.

[dc42]

You can just upload the Duet2CombinedFirmware.bin file that you will find in the Duet2_RTOS folder.

I suggest you edit the Version.h file and build again, so that you can identify the firmware as your own build.

[k120]

Alright, I rebuilt and uploaded the firmware successfully. I'll switch hotends and test it. Thanks for the help!