Marlin: [BUG] Part cooling fan running permanently

Created on 23 Oct 2020  ยท  29Comments  ยท  Source: MarlinFirmware/Marlin

Bug Description

After flashing one of the most recent 'bugfix-2.0.x' commits, the part cooling fan on both a SKR 1.4 Turbo and a SKR mini E3 1.2 starts to run as soon as the printer gets powered up.

Unfortunately I do not know, when exactly this occurred, since I am not able to flash every single commit.

My Configurations

Configuration.zip

Steps to Reproduce

  1. Flash this commit or later ones, maybe this was caused even by the most recent of the precedent ones.
  2. Restart the printer.
  3. Realize, that the part cooling fan is running, without being activated.

Expected behavior: Part cooling fan should only run when activated.

Actual behavior: Part cooling fan runs without being activated.

Additional information

Unfortunately, I was not able to solve this issue by flashing an earlier version of Marlin. No matter which one I tried, the fan kept running.

thanks in advance
kind regards

Bug? False Alarm

Most helpful comment

Right I've been fooling around with lpc1768/9

When we have an issue with normal arduino and a suspected bad pin we get the user to run the blink sketch on the IO pin and see if it works independently of everything else.

Up to now it was not easy to do this on LPC1768/9. Now it is.

Take a look at https://github.com/ellensp/lpc176x-arduino-blink
This is a 'blink' sketch for a LPC1768/9 but it only works under platformio.

You don't even need to compile this. I've done that for you too, and tested it. (on a azteeg mini 1.1, exact same same processor as the skr 1.4 turbo)

In https://github.com/ellensp/lpc176x-arduino-blink/tree/master/pre-built/lpc1769 is firmware.bin
This is compiled for a LPC1769 and turns P2_03 (fan0) on and off over and over.
It also tells you its doing this on the serial port

All you need to do is put this on your sdcard and boot your controller to load it.

NB it only sets up the SD card as a drive (so you can re flash it easily) and creates a serial over USB, so it can tell you what it is doing and and toggles the one IO pin. It doesn't setup or use your screens or anything else at all

Try this, and is this doesn't turn your fan0 off, you have a hardware fault 100% guaranteed.

All 29 comments

By chance, do you have the fan plugged in the correct port? On the 1.4 you only have 1 PWM fan plug.

I did not change anything hardware wise, and before the update it worked as expected.

Is the temperature on the extruder reading room temperature correctly?

@ellensp
Yes the reading is correct.
But it is about the part cooling fan. ๐Ÿ˜Š
And that one could only be triggered either by via the lcd or via g-code.
But the most confusing part is, that it is not possible to revert this issue by flashing earlier commits.
On the SKR E3 mini 1.2 this was caused by the official build.

thanks in advance

bigtreetech fork of marlin is not supported here. BTT do not patch and update anything like regularly enough.

Ok, I get that, but how did this happen to the 'SKR 1.4 Turbo' as well?
And that one is solely flashed with firmware form this branch!

Could there be any connection between these two?

I suspect you have gremlins, controller destroying gremlins...
If it was firmware, going back to an earlier version would solve it.
But have to wait till someone with a skr 1.4 turbo can verify it.

I have to admit, that I do not know much about the structure and the processes behind firmware in general, but I think that there was something similar regarding my MKS TFT28:

  • something was moved to SPI flash. Unfortunately that build was buggy and so I thought I would go back, by just flashing the build before.
    BUT that did not help, since the bug was still present. ๐Ÿ˜ต๐Ÿคฏ

Maybe this could help narrowing down the 'range of causes'. ๐Ÿคทโ€โ™‚๏ธ

Enable pins debugging in Configuration_adv.h recompile upload
Send a M43 to list all pins, verify what pin the part cooling fan is on and that there are no other functions assigned to this pin.
Remove any conflicts. so the pin only has the one fuction.
Restest.

The next step would be to remove the parts cooling fan pin from marlin so it doesnt know about it, (ie remove from the boards pin file) verify with M43 that marlin has nothing allocated to that pin. Then control the IO pin with M42 for testing.

Ok thank you for your advice. ๐Ÿ‘
Will try that and find out, if I got everything you mentioned.

Even after having followed the steps you provided, meaning I have:

disabled the corresponding pin and confirmed that with M43 via pronterface,

the fan keeps running! ๐Ÿ˜ต๐Ÿคทโ€โ™‚๏ธ

its a hardware fault.

@ellensp
Well, ... hopefully I am able to turn this somehow around. ๐Ÿ˜Š

@digant73
Since you are using the 'same' hardware, it would be nice to get to know, if you upgraded the default mainboard to one produced by BTT.
If so, could you please confirm, if your printer is also affected by the described issue, after flashing the mentioned commit?

thank you in advance

@discip I have the stock HW. no problem with that

@digant73
Thank you.

I do not know, if my assumption is right, but is it possible that not Marlin itself, but the 'lib-packs' which are updated by the compiler, are corrupted?

19857 the same problem

That's different hardware with a different issue.

If you think its a build environment is damaged re-install it.

To competely remove platformio. First remove .pio from your marlin directory. Then uninstall platformio from vscode then delete .platformio directory from your home directory.

Then reinstall pltaformio in vscode and it will download everything again.

I am not sure, if this is the case.
But what I know for sure is:

  1. That the firmware for my SKR 1.4 T was compiled on my machine using the mentioned commit.
  2. That the firmware for the SKR mini E3 1.2 was compiled by someone else, since I flashed a precompiled *.bin.
  3. Both boards are from BIGTREETECH.
  4. The issue occurred on both machines at the same time.
  5. No hardware changes were made.
  6. Both machines use the latest 'Unified UI' firmware as TFT firmware maintained by @guruathwal.
  7. Reflashing previous builds did not solve the problem.

I hope, I did not miss anything.
I am really in need for someone being knowledgeable enough to trace down the root cause, since I am not that familiar with all the internal processes involved in the compilation of firmware.

What pin is your part cooling fan on according to M43?

@discip Did you try it after disconnecting the TFT serial cable to check if the problem is not caused by the TFT controllers?

Right I've been fooling around with lpc1768/9

When we have an issue with normal arduino and a suspected bad pin we get the user to run the blink sketch on the IO pin and see if it works independently of everything else.

Up to now it was not easy to do this on LPC1768/9. Now it is.

Take a look at https://github.com/ellensp/lpc176x-arduino-blink
This is a 'blink' sketch for a LPC1768/9 but it only works under platformio.

You don't even need to compile this. I've done that for you too, and tested it. (on a azteeg mini 1.1, exact same same processor as the skr 1.4 turbo)

In https://github.com/ellensp/lpc176x-arduino-blink/tree/master/pre-built/lpc1769 is firmware.bin
This is compiled for a LPC1769 and turns P2_03 (fan0) on and off over and over.
It also tells you its doing this on the serial port

All you need to do is put this on your sdcard and boot your controller to load it.

NB it only sets up the SD card as a drive (so you can re flash it easily) and creates a serial over USB, so it can tell you what it is doing and and toggles the one IO pin. It doesn't setup or use your screens or anything else at all

Try this, and is this doesn't turn your fan0 off, you have a hardware fault 100% guaranteed.

@ellensp

First of all, thank you for helping me to solve my problem. ๐Ÿ‘โค

I just flashed and booted the provided *.bin, while having established a serial connection, which read Led ON; Led OFF ....
But as you might have expected: The fan kept running.

Is it even possible to fry a board / controlling component by flashing corrupted firmware?

@guruathwal
Thank you!
I will try that later, since I have to disassemble my printer for that.

I just updated my SKR 1.4 builds to the latest bugfix (8bdde8d) and the fans work as they should.

As for the SKR Mini firmware from the BTT repo, it has several issues and is misconfigured.

Closing as this is a hardware failure and not a Marlin bug.

@thisiskeithb
Thank you.
Did not mean to set an false alarm.
But this was my first diagnose, since it happened exactly after updating to the mentioned commit.

Regarding the SKR mini: Would you please provide a well configured ZIP of Configuration.h & Configuraton_adv.h?

And since you are in possession of an SKR 1.4, are you using a BTT TFT as well?
If so, would you mind to flash the TFT with this commit and check, if this issue is caused by it?

You have not to do this though, because this might break your SKR 1.4.

thanks in advance
regards

Regarding the SKR mini: Would you please provide a well configured ZIP of Configuration.h & Configuraton_adv.h?

I bench tested my SKR Mini E3 V1.2 with the Ender-3 config from the Marlin Configurations repo since it's not in a printer right now. The parts cooling fan isn't on unless you command it to be. Just for good measure, I updated my SKR Mini E3 V2.0 build (used in a custom-built Prusa Mini clone) and that also works as it should.

And since you are in possession of an SKR 1.4, are you using a BTT TFT as well?

I have some on printers, but use them in "Marlin Mode" exclusively and don't plan to update for a while due to all the bugs on the "Touch Mode" side. Maybe when things settle down ๐Ÿ™‚

@thisiskeithb
Thank you! ๐Ÿ‘

Was this page helpful?
0 / 5 - 0 ratings

Related issues

otisczech picture otisczech  ยท  3Comments

Tamonir picture Tamonir  ยท  3Comments

spanner888 picture spanner888  ยท  4Comments

ceturan picture ceturan  ยท  4Comments

StefanBruens picture StefanBruens  ยท  4Comments