MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.29k stars 19.24k forks source link

[BUG] MAX31855 Spurious Error Causes Marlin to Halt #18025

Closed mobilinkd closed 4 years ago

mobilinkd commented 4 years ago

Bug Description

I am trying to deal with a MAXTEMP error when using the MAX31855. I am replacing the Mightyboard on a Flashforge Creator X with an SKR Pro v1.1, TMC2209s, and a couple Adafruit MAX31855K boards. This a Makerbot Replicator clone. The problem with the Replicator design is that it uses thermocouple sensors on the hot ends and the thermocouple wires are routed with the extruder stepper wires. This causes a lot of noise to be coupled into the thermocouple sense wires.

I should also mention that my printer was functioning just fine with the Mightyboard running Sailfish 7.6 and 7.7.

The problem that I am having is that as soon as the extruder motors are enabled, the noise increases on the thermocouple sense wires and the MAX31855s start emitting errors. Marlin halts on the first error.

I have reduced the noise somewhat by shielding the thermocouple wires. However the errors still persist -- just the frequency has been reduced. A single event is enough to cause Marlin to halt. There is no grace period or retries when this error condition occurs.

I removed the MAX6675 error handling code to get my printer working temporarily.

In researching this, I discovered that the Sailfish firmware I was running on the Mighyboard has a compile time parameter, SENSOR_MAX_BAD_READINGS, for the number of errors that can occur in series before it halts. This is defaulted to 15.

My Configurations

config-3.zip

Steps to Reproduce

  1. Upgrade the Mightyboard on a replicator clone with an SKR Pro 1.1, TMC2209 stepper drivers, and two Adafruit MAX31855K boards. Use Extension port 2 to provide power and SPI to the two MAX31855 chips.
  2. Configure Marlin to use MAX31855s for hot end thermocouples (probe type -3).
  3. Note that the temperature readings are correct and that stable hot-end temperatures can be maintained.
  4. Enable all steppers.

Expected behavior: [What you expect to happen]

I expect that that Marlin continues to run after steppers are enabled and that it will ignore spurious "Short to VCC" or "Short to GND" errors reported by the MAX31855 chips.

Actual behavior: [What actually happens]

Marlin emits a single error message "Short to GND" or "Short to VCC" and then halts with a MAXTEMP error.

Additional Information

I am in the process of adding a THERMOCOUPLE_MAX_BAD_READINGS option to my fork. Is this something that would be accepted in to Marlin mainline?

I can maintain stable temperatures with the steppers enabled by ignoring the errors from the MAX31855.

I have also upgraded the stepper drivers to TMC2209s. Changing the extruder stepper mode from stealthchop to spreadcycle seems to reduce the errors a bit, as does lowering the stepper current. But the noise is still there and the errors are never completely eliminated.

For those that are curious, below is what the (worst case) noise on the thermocouple wires looks like with the steppers disabled and enabled. Power, GND and SPI control wires are all very clean when steppers are enabled. The noise only affects the thermocouple sense wires.

sds2204x-2020-05-17T10:59:03-05:00 sds2204x-2020-05-17T10:58:47-05:00

rmcrabb commented 4 years ago

I'm in the same boat here. Same problem for the last week.

rmcrabb commented 4 years ago

What pins on the SKR are you using?

Grogyan commented 4 years ago

You will need to ensure that the thermocouple is electrically isolated in the can, and also ensure that you have an EMI shield that goes from the can, all the way up and over the wires to the ground pin on the Max31855 board you are using

mobilinkd commented 4 years ago

What pins on the SKR are you using?

#define MAX6675_SS_PIN                      PD5   // EXT2
#define MAX6675_SS2_PIN                     PE0   // EXT2
#define MAX6675_DO_PIN                      PD2   // EXT2
#define MAX6675_SCK_PIN                     PE2   // EXT2
mobilinkd commented 4 years ago

I'm in the same boat here. Same problem for the last week.

Try the attached patch to src/module/temperature.cpp and see if that fixes the problem for you. It fixed it for me. Also, try reducing current to your extruder steppers. And if you are using a TMC, use SpreadCycle rather than StealthChop.

temp.diff.txt

mobilinkd commented 4 years ago

You will need to ensure that the thermocouple is electrically isolated in the can, and also ensure that you have an EMI shield that goes from the can, all the way up and over the wires to the ground pin on the Max31855 board you are using

Both thermocouples are electrically isolated. I have verified this.

At this point the wires are as shielded as they can be. The one thing that really helps is to move them away from the stepper wires. But the design of the printer is such that it is not really feasible to do that long term and not run into other problems.

I have shielded the wires. I have adjusted the TMC driver settings and the motor current. All have helped to reduce the problem. None have eliminated the problem.

The problem is that these errors are spurious. A single event will ruin a print.

I have a patch that is working for me. It allows my prints to succeed. And it will trigger a halt if the problem is persistent.

rmcrabb commented 4 years ago

My issue was resolved with mobilinkd's PR #18039

Grogyan commented 4 years ago

I tried this again today, setting the error catch to 0 No, min temp triggered Set the error catch to 15 No min temp triggered.

As only firmware change was the error catch number, nothing else changed, and couldn't reproduce the min temp trigger that I got yesterday, quite reliably.

I'm still cautious, as I haven't done yet a full print

@thinkyhead as there are now 3 of us that have verified this change works, it can probably be now merged.

mobilinkd commented 4 years ago

@grogyan @rmcrabb Thank you both for testing this. I truly appreciate it.

Grogyan commented 4 years ago

@Grogyan @rmcrabb Thank you both for testing this. I truly appreciate it.

The only real difference between ours, is that I put the error catch define in conditionals_post.cpp instead of config_adv

mobilinkd commented 4 years ago

I did not put an error catch in config_adv. I put the default config there.

There is an error catch to set a default value in temperature.cpp immediately before the function.

On Tue, May 19, 2020 at 10:59 PM Grogyan notifications@github.com wrote:

@Grogyan https://github.com/Grogyan @rmcrabb https://github.com/rmcrabb Thank you both for testing this. I truly appreciate it.

The only real difference between ours, is that I put the error catch define in conditionals_post.cpp instead of config_adv

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/18025#issuecomment-631221812, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABD64DGJSX3WP74OEU6JFPDRSNISXANCNFSM4NDSOTHA .

github-actions[bot] commented 4 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.