# Changing FAN0 to FAN1 in TriGorilla printer board

I plugged a new fan into the (TriGorilla v1.4) printer board Fan0 which I found out to be broken.

I'm trying to upgrade the part cooling fan for a bigger one. Unfortunately after plugging in the old one, I realize that the fan is constantly "ON". On other forum someone told me that MOSFET might be shorted from plugging in the broken fan.

This triggered my question: "Is there any possible way to change the firmware FAN0 to use FAN1 socket?" and: "Would that work for part cooling model fan?"

Yes you can use another fan port, this requires some editing of the configuration files of the firmware and reflash the firmware.

If you look at the documentation of the board and an overview of the board layout, you will see that there are 3 PWM controlled FAN ports. The answer is therefore yes, you can use another port (e.g. FAN1 or FAN2) to be used for your broken FAN0 port. The most easy solution is to swap the port numbers in the pins configuration of your firmware, so swap pins 'D9' and 'D7'.

How you edit the configuration is depending on the version of the TriGorilla board you have, there is a version 1.3 and a version 1.4.

Basically you need to define the software FAN (0) to be reached at the hardware location Fan1 using pin 7:

#define FAN_PIN        7


Subsequently, FAN1 in software needs to points to Fan0 in hardware

#define FAN1_PIN        9


If you changed this, the software will think that the Fan1 port on the board is the software FAN.

If you are using the v1.4 TriGorilla printer board, the v1,4 specific pin definition is found in pins_TRIGORILLA_14.h. If you look into this file you will see that this is basically a RAMPS board:

#define IS_RAMPS_EFB
...
#include "pins_RAMPS.h"


So editing for you need to redirect the pins 7 and 9, but you only have a single active fan (as per #define IS_RAMPS_EFB)! Luckily we can forget about the second fan as you want to replace the first by the second.

In pins_RAMPS.h you will find:

#ifndef RAMPS_D9_PIN
#define RAMPS_D9_PIN      9
#endif


Note that it is wise not to edit this latter file, instead edit your copy of pins_TRIGORILLA_14.h to include assigning of the pin 7 to the Fan1 header as FAN in the firmware.

If you look closely at the assigning of the RAMPS_D9_PIN pin, it says: #ifndef; so if it has been assigned previously, do not override the value.

Now edit the pins_TRIGORILLA_14.h file to include:

// Comment out this line:
//#define FAN_PIN 9
// And enter this beneath that line
#define RAMPS_D9_PIN 7


or

#define FAN_PIN 7
// this bypasses setting of the RAMPS_D9_PIN constant


From this point on, if the software addresses scheduling of the FAN port, the pin 7 schedules the MOSFET attached to the Fan1 header.

Basically, the above procedure describes how one directs hardware ports by changing the addressing in the firmware configuration.

If this does not work, there might be more things broken on your board.

• I'm 90% sure that I have 1.4 version. I edit script like you show me. Unfortunately nothings changed. In script there is "#include "pins_RAMPS.h" Should I change there pins as well?
– JAKE
Dec 19 '18 at 23:01
• @JAKE you need to take care where you put it else it is overridden, several pins.h files are read subsequently. It should work, I have done this several times. I've updated the answer for you, this works for me.
– 0scar
Dec 20 '18 at 8:16
• Is it possible that even if i modify Fan0 to Fan1 and other way around, it will still use MOSFET from Fan0 which I have problem with? I did exactly how you said above. #define FAN_PIN 7 #define FAN1_PIN 9
– JAKE
Dec 20 '18 at 9:54
• Pin 9 is physically attached to the gain of the MOSFET of Fan0, pin 7 physically attached to the gain of the MOSFET of Fan1 (if the documentation is right!). So if it is swapped in the firmware you should not be using the Fan0 header anymore. Strange that it does not work for you, maybe there are more things broken on your board.
– 0scar
Dec 20 '18 at 10:00
• You might be right :(
– JAKE
Dec 20 '18 at 10:19