Welcome! Log In Create A New Profile

Advanced

MKS BASE - procedure to diagnose / swap bad mosfet

Posted by david784 
MKS BASE - procedure to diagnose / swap bad mosfet
September 11, 2017 01:15PM
I recently built a printer which used the MKS BASE 1.4 controller. (Tevo Tarantula). Everything worked great, except when I tried to heat up the hotend for the first time, the heater mosfet failed (always on).

It took me a couple of days to figure out for sure what had happend, and another couple of days to change my (marlin) firmware to use the second extruder mosfet instead of the bad one.

But once I was all done, the actual procedure to do all of this really wasn't that hard...it just took me a long time to find all the info. So I thought I'd create a thread with everything I learned along the way, in the hopes that maybe it might help someone else out in a similar situation.
Diagnosing the mosfet
September 11, 2017 01:17PM
Quick summary: what the mosfet does. The adurino chip that controls the printer uses various control pins to either send or receive signals to control your printer. One of these digital pins is used to control when the heater turns on. However, this control signal is very low powered; it can't possibly power a heater. Enter mosfet: it receives a "gate" signal (low power) and uses it to control a high power circuit.

NOTE: Before checking these things, you'll probably want to disconnect the heater from the screw terminals.

The mosfet is a little chip with a metal tab at the "top," and three pins at the "bottom." (On my board the top of the chip is facing downward). The metal tab and the middle pin are both for the output (aka "drain"), the left pin is the "gate" signal (from the arduino), and the right pin is the input (aka "source," in this case ground). It's probably pretty close to the screw terminal block where you attach the heater(s) and fan(s).

  • In the case of the MKS BASE heater mosfets, the mosfet is on the "ground" side of the circuit. So the first thing to check is: do you always have 12V on the positive side, when compared with the main ground terminal for the board? If you don't, the polyfuse has probably blown. If you have a good 12V signal, time to check the mosfet itself.
  • Check to make sure that the mosfet right pin has good ground (check the resistance between that pin and the main ground on the board). If it doesn't, something is wrong with the board.
  • Then check to make sure that the tab/center pin has a good connection with the minus/ground screw terminal. Should be essentially no resistance. If the connection is bad, that's most likely the problem.
  • Check your "gate" signal on the right pin. If the heater is off, you should have essentially 0V on this pin (measured with reference to board's ground terminal). When heater is on, this should read about 3V. If this signal isn't right, the problem is probably somewhere else (either the board or the arduino).
  • Now we're ready to check the main mosfet function. Assuming everything else works up to this point, when you measure no "gate" signal, the left pin and the tab/middle pin should have a very high resistance value (megaohms or infinity). When you have a gate signal, you should have a very low (probably close to zero) resistance.

In my case, I had good 12V signal, good ground going into the mosfet, and a good gate signal coming from the arduino. However, the resistance between the input and the output was always essentially zero...the mosfet was stuck in the on position.
Finding pins for mosfet(s) (and other things)
September 11, 2017 01:18PM
This assumes you are using the Marlin firmware, and that your board supports at least two hotends, and that you aren't using all the hotends your board supports. In my case, my board supports two hotends, and I only have one.

The first thing we need to do is figure out which arduino pins we're dealing with. To do this, you'll need to download the marlin source code, hopefully with the correct configuration files for your printer. In my case, I was using this source:
[github.com]

Once you've got it, and assuming you're dealing with an MKS BASE board or similar, you're going to be primarily interested in the pins_RAMPS.h file. You're wanting to find values for HEATER_0_PIN, and also for HEATER_1_PIN.

You'll need to tell your firmware that you have two extruders (at least for the moment), so that we can verify which pin controls the second extruder's heater mosfet. In my firmware it was as simple as uncommenting one line in my configuration.h:
//#define DUAL_EXTRUDER

Once you've done this, the absolute easiest way to get the pin assignments for HEATER_0_PIN and HEATER_1_PIN is to use gcc, if you can. You can use the following command to do all the precompiler work

gcc -E -dD -C -I ~/3d/arduino/arduino-1.8.4/hardware/tools/avr/avr/include/ -I ~/3d/arduino/arduino-1.8.4/hardware/arduino/avr/cores/arduino/ -I ~/3d/arduino/arduino-1.8.4/hardware/arduino/avr/variants/mega/ -D'__AVR_ATmega2560__=1' -D'AVR_ATmega2560_FAMILY=1' Marlin_main.cpp
There is a lot going on here, but basically the -E tells the compiler to only analyze precompiler commands, and then output the results. The -dD tells it to leave in the "#define" precompiler commands (after it has reduced them to their simplest form). That way you get something like:
#define HEATER_0_PIN     10
instead of
#define HEATER_0_PIN     RAMPS_D10_PIN
It will also evaluate and remove unneeded #if/#elif statements, so that you're only seeing the ones that evaluate to true. Makes it much simpler.

The rest of the options: the -C tells it to leave in comment lines. All of the -I flags are to include certain directories...I found these by trial and error. You would have to change these to point to the equivalent directories in your own arduino installation. Finally the two -D flags set the value of a couple of compiler constants. I think these are automatically set in the arduino development environment, but of course wouldn't be set automatically when using the gcc default linux compiler.

You can just output this to a text file or something, and then search out the parameters you're interested in (like HEATER_1_PIN).

Also, I'm sure it goes without saying that you wouldn't want to actually compile the code outside the arduino environment, but all we're doing is analyzing the precompiler options.


If you can't do this, you can go to the bottom of your Marlin.ino file and add some compiler if's of your own. This is an iterative process: as far as I know you can't actually print constant values at compile-time in the arduino development environment, but you can print messages, and you can evaluate if statements.
#if HEATER_0_PIN<10
   #pragma message "HEATER_0_PIN <10"
#endif
So you can start of with <10. If the pragma message shows up when you compile, then the condition is true. Next check <5, and keep splitting the difference until you get it narrowed down to a single pin. It's a little more tedious than the gcc method, but you can get it done. It's also much harder to find out if something else is using that pin...
modifying the pins in the firmware
September 11, 2017 01:21PM
In my case, I found that HEATER_0 was 10, and HEATER_1 was 7. However, I also found that when I turned dual extruders back off, that the FAN1_PIN was being set to 7. From this section:
  #if HOTENDS == 1
    #define FAN1_PIN     MOSFET_D_PIN

This is important: you don't want the firmware to try to control two different things using the same pin. Before I found the FAN1_PIN, my heater had very weird behavior.

EDIT: One thing you can check to see if you're double-assigning pins is to look at the SENSITIVE_PINS constant. It is defined in pins.h, and if you use the gcc method I mentioned above you should be able to see all of the pin values. That's how I finally found my FAN1 issue on pin 7.

SENSITIVE_PINS is an array of all the major pins used by things like heaters, stepper motors, etc. (It is used to prevent an "M42: Change pin status via GCode" being issued on any of those pins. So in my case, I was looking at pin 7, and I saw two different 7's in that array. Then it was just a matter of figuring out where the other 7 was coming from.

So once you've figured all this out, you can just change the pins_RAMPS.h. In my case, I ended up changing two lines:
#define HEATER_0_PIN     7 //RAMPS_D10_PIN
    #define FAN1_PIN     -1 //MOSFET_D_PIN
(lines 165 and 185, respectively) I left the original values in as comments, just so I'd remember what I changed.

Then compile, upload, and try turning on your heater! If the mosfet works correctly, the LED for that mosfet should come on (or you should measure 12V across the plus/minus terminals for that mosfet). If it works, power down, connect the heater to the new mosfet, and power back up, and give it a try!

Edited 2 time(s). Last edit at 09/11/2017 01:29PM by david784.
Sorry, only registered users may post in this forum.

Click here to login