Makerbot Replicator – Using the ‘EXTRA_FET’

This is a compilation of some notes and test to understand how to use the FET labeled ‘extra’ on the Replicator’s Mighty Board.

In the previous versions of the Makerbot printers, the firmware and driver were written in such a way that it was relatively easy to make use of the extruder controller board FETs.  People used this for various things, including Frostruding.  Having the opportunity to play with a Replicator, I was quickly drawn to this little extra FET waiting to be exploited!  Well, how can one trace if it is even possible to access this? Well, first thing is just to plug something in and test it!  I hooked up a multimeter and sent some M codes I had been spying, a lo and behold, I got the answer I was looking for: the current MightyBoard firmware and ReplicatorG driver are set up to use this Mosfet… But, whats under the hood?

Well, get ready for some traveling through the Replicator G Replicator driver and the Mighty Board firmware…

I decided it would be best to start looking in the firmware as it’s what loaded on the Mighty Board.  If there is a gateway to the extra fet here, then at least we do not have to modify the firmware.  Digging in the Github Repository for the MightyBoard firmware, I found this in the Motherboard.cc file:

void Motherboard::setValve(bool on) {
  ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
    //setUsingPlatform(false);
    //pwmHBP_On(false);
    EXTRA_FET.setDirection(true);
    EXTRA_FET.setValue(on);
  }
}

Ok! So at least in the firmware, there is some method that references the ‘EXTRA_FET.’  So is this hooked into anything?  It is.  I found a call to the method in the Command.cc file:

 

case SLAVE_CMD_TOGGLE_VALVE:
  board.setValve((pop8() & 0x01) != 0);
  return true;

 

This is also present in an older version of the Host.cc File:

case SLAVE_CMD_TOGGLE_VALVE:
  board.setValve((from_host.read8(3) & 0x01) != 0);
  return true;

Note: I did not find this in the current version of the Host.cc file in the official repository.  Seems around July 12th, 2012 some changes occurred which I need to dig into…

In any case, we keep going! The SLAVE_CMD_TOGGLE_VALVE is defined in the shared Commands.hh file as such:

 

#define SLAVE_CMD_TOGGLE_VALVE          13

Ok, so it seems there is a way to send a command to the firmware which is connected to the hardware.  Now, how to we get there from software?  Well, for this we need to dig into the Replicator G source.  Digging into the gen3 drivers, we fine this little nugget in the ToolCommandCode.java file:

 

TOGGLE_VALVE  13

 

Which is called in the Sanguino3GDriver.java:

   public void openValve(int toolhead) throws RetryException {
    Base.logger.fine("Opening valve");
    /// toolhead -1 indicate auto-detect.Fast hack to get software out..
    if(toolhead == -1 ) toolhead = machine.currentTool().getIndex();
    PacketBuilder pb = new PacketBuilder(
    MotherboardCommandCode.TOOL_COMMAND.getCode());
    pb.add8((byte) toolhead );
    pb.add8(ToolCommandCode.TOGGLE_VALVE.getCode());
    pb.add8((byte) 1); // payload length
    pb.add8((byte) 1); // enable
    runCommand(pb.getPacket());
    super.openValve(toolhead);
   }

Which is called up in the DriverCommands:

public class OpenValve implements DriverCommand {

    @Override
    public void run(Driver driver) throws RetryException {
        driver.openValve();
    }
}

 

Note: Seems in recent versions of Replicator G, these methods have been set up in small classes.  Here is the OpenValve.java:

package replicatorg.drivers.commands;
import replicatorg.drivers.Driver;
import replicatorg.drivers.RetryException;
public class OpenValve implements DriverCommand {
    @Override
    public void run(Driver driver) throws RetryException {
    driver.openValve();
    }
}

 

And the CloseValve.java:

package replicatorg.drivers.commands;
import replicatorg.drivers.Driver;
import replicatorg.drivers.RetryException;
public class CloseValve implements DriverCommand {
    @Override
    public void run(Driver driver) throws RetryException {
           driver.closeValve();
    }
}

 

Which are both enumerated in the GCodeEnumeration.java file:

    
M126("M", 126, "Valve Open"),
M127("M", 127, "Valve Close"),

 

And more importantly, are present in the GCodeParser.java file:

    // valve open

    case M126:

    commands.add(new replicatorg.drivers.commands.OpenValve());

    break;

    // valve close

    case M127:

    commands.add(new replicatorg.drivers.commands.CloseValve());

    break;

 

Phew!  The conclusion should be that if I hook up a compatible [insert awesome thing here] to this extra FET and send M126 / M127 to open and close the valve respectively I should be able to, well, turn something on or off.  Is this the case!? The short answer is yes!  Video coming soon…



One Comment

  1. Manson wrote:

    What software are you used to modify the firmware ?

Leave a Reply