hits counter

Upgrading the Makerfarm Prusa i3 to a new version of Marlin:

So you’ve got your new Makerfarm Prusa i3 3D printer all set up, printing, and maybe even tuned so it’s singing just beautifully.

Now you hear there’s some new feature of the Marlin firmware that isn’t implemented on the version you’ve got installed.  Can you just download the new version, flash it to your printer via the Arduino IDE and just roll right along?

Probably not.

The thing is, Marlin, by default, is set up for the Ultimaker, which is a great printer, but is actually quite a bit different from the Prusa RepRap family, which includes the i3.

Fear not, there is hope!

The front Page of ErikZalm's Marlin repository on Github.

The front Page of ErikZalm’s Marlin repository on Github.

In reality, Marlin is highly configurable, and with only a few quick and easy modifications, you can be running the latest and greatest version.

There are two things you’ll need to get your hands on:

  1. The current version of Marlin.  You can get that at ErikZalm’s GitHub respository.Click the “Download ZIP” button, and save and extract the file to a convenient location.  You’ll be modifying and flashing these files, so put them somewhere where you’ll be able to work with them.
  2. The most recent firmware from the Makerfarm website (look under “Build Instructions”, and then look for “RAMPS Download”.  Download the file, and extract the folder that matches your printer Mine is “Marlin_RAMPS-EPCOS_i3-8inch”.

Now that you’ve got both versions, the “Standard” current Marlin, and the pre-configured Makerfarm version, you’re going to be looking for a file called “Configuration.h”.

IMPORTANT NOTE:  The Arduino IDE is going to insist that, within both of these projects, the file names need to be the same.  Resist the temptation to rename one file something like “Configuration-old.h”, it won’t work.  Keep both of these sets of files in different directories, and be EXTREMELY careful to keep them straight and separate.

Once you’ve got both “Configuration.h” files opened, you’re basically going to be going through each one, and whenever a value is different between them, you’re going to replace the value in the “Vanilla” file with the one in the Makerfarm file.

Two versions of the Marlin Configuration.h file - On the right, the Pre-configured Makerfarm version, and on the left, the unchanged default Marlin version.  To get a new version of Marlin running properly on the Makerfarm Prusa i3, we'll be replacing the default values with those in the Makerfarm-specific file.

Two versions of the Marlin Configuration.h file – On the right, the Pre-configured Makerfarm version, and on the left, the unchanged default Marlin version. To get a new version of Marlin running properly on the Makerfarm Prusa i3, we’ll be replacing the default values with those in the Makerfarm-specific file.

At this point, I highly recommend creating another text file to record all the changes you make.  If something stops working, you’ve got a trail of breadcrumbs you can follow to fix whatever went wrong. In days past, the general practice was to record the line number, so you could easily see exactly where you made the changes.  In the last couple of updates to Marlin, however, significant blocks of code have been added or removed, so the line numbers don’t match up well.  I now recommend just recording the names of the variables you’ve altered, as well as the new and old values, so it no longer matters where they may have been moved within the file.

Also, I have found it to be a good use of time to just explore the innards of the Configuration.h, just to get a feel for what is there.

You’re not going to do that?  Okay, okay, I understand.  Here is a list of the crucial changes you’ll need to make to get things running.  Find these settings in the new Marlin file, and make these changes:

#define MOTHERBOARD 33  (Default is 7, which is the Ultimaker)

#define TEMP_SENSOR_0 1 (Default is -1, which is again for the Ultimaker)
(IMPORTANT: You can use sensor #6, which is what is actually specified in the Makerfarm file, but you’ll need to use the thermistortables.h file from the Makerfarm distribution.  Makerfarm’s tables are significantly different from those in the standard Marlin distribution!)

#define TEMP_SENSOR_1 0
(Default is -1, which is, again, for the Ultimaker)

#define TEMP_SENSOR_BED 1 (Default is 0) (see the important note above)

#define HEATER_0_MAXTEMP 235 (235 for the J-head, higher for the Magma or other all-metal hotend)

#define BED_MAXTEMP 125 (default is 150, which is probably too high)

Under the heading Mechanical Settings There are few values to change.

Look for:


There will be six #defines immediately under this statement (Make sure you’re looking at the #ifdef, and not the #ifndef right above it).

Comment out the top three, which are the ones involving XMAX,YMAX and ZMAX endstops. When you’re done, the whole section should look like this:



Next are a series of Endstop inverting statements:

These are all set to “true”, which won’t work with the stock Makerfarm i3, so set them all to “false”:

const bool X_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
const bool Y_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
const bool Z_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
const bool X_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
const bool Y_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
const bool Z_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.

#define min_software_endstops false // If true, axis won't move to coordinates less than HOME_POS.

(this is set to “true” by default.  It won’t catastrophically fail if it’s on, but it will be an annoyance later on.)

// Travel limits after homing
(the defaults are set just a bit higher, you don’t want to try to set a position beyond the physical edge of the printer’s travel!)
#define X_MAX_POS 200
#define X_MIN_POS 0
#define Y_MAX_POS 200
#define Y_MIN_POS 0
#define Z_MAX_POS 185
#define Z_MIN_POS 0

#define HOMING_FEEDRATE {50*60, 50*60, 150, 0}  // set the homing speeds (mm/min)

#define DEFAULT_AXIS_STEPS_PER_UNIT   {80,80,4000,945} (this one is REALLY IMPORTANT!)

#define DEFAULT_MAX_ACCELERATION      {9000,9000,20,10000}

The EEPROM settings are disabled by default.  I think these features are incredibly useful, so I recommend uncommenting the following lines:



The Makerfarm comes with the RepRap Discount LCD controller, so you’ll want to uncomment the following define:


This should get you running nicely with all the new features of Marlin!

I do not guarantee that there are no mistakes here, or that this is a complete guide.

I will keep this post updated as new features become available, and please feel free to contact me if you see that I’ve missed something important.

80 comments to Upgrading the Makerfarm Prusa i3 to a new version of Marlin:


    if i use board 33 it errors something about the thermistors being wrong. sorry to bother you but i thought you might know something. if i set the board to 34 works fine but i lose fan and it think i have an extra extruder. i can go into further detail if needed thank you for your time…

    • That is indeed strange. The only real differences I have found between the RAMPS motherboards are all in the pins.h file, and the only difference there is a pin assignment for the fan or second heater. At first blush, I’d suggest double checking your wiring. Can you be more specific about that thermistor error?

  • Another thought: This -shouldn’t- do anything, but give it a shot: Copy over the thermistortables.h file from the Makerfarm-configured Marlin into your new Marlin folder. Change your hotend and bed thermistors to #6 in configuration.h and re-flash.

    See what that does…

  • Larry

    I’m sorry I was trying to use board 34 board 33 works fine. I wanted control over my fan though and if I try to use board 34 ( extruder, fan, bed) is gives a dip error or somthing like that any info you have would be much appreciated.

  • Aha, I see what’s going on. 33 is extruder, fan, bed. 34 is extruder0, extruder1, bed.

    The pins.h file is where all these assignments happen. 33 uses pin 9 for the fan, and 34 reassigns pin 9 to the heater on extruder1 (the second hotend), so using 34, two things are going to happen:

    1) The RAMPS board is going to try to heat a second hotend with your fan, which isn’t going to work.
    2) The RAMPS board is going to be looking for a thermistor on pin 15, which probably doesn’t have anything atatched to it (it’s either for a second hotend thermistor or a Y-axis MAX endstop). Thats’ probably why your getting a thermistor error.

    In any case, motherboard 34 doesn’t assign a pin to control a fan (this would be for something like a Magma installation, where the fan needs to be running at full speed all the time, so it’s generally wired directly to the power supply).

    If your fan isn’t working with motherboard #33, there is something else going on. Where is your fan connected?

  • tango

    Have you thought of creating a github fork of Marlin source and putting these changes there? That might be nice for us prusa i3 users out there.

  • Tim

    I followed the instructions and thought I successfully got it all working until I tried printing a calibration cube. When printing the calibration cube I noticed that the bottom layers are compressed in certain corners giving me an uneven print and a print height that is shorter than expected. Using a mini cube stairway calibration print I noticed it was only compression on the first few layers as only the first cubes on the stairway are too short and the rest are the correct height. It looked like the bed leveling compensation is happening too much.

    I tried reducing the amount of correction by moving the 3 point probes closer to the centre without any difference in the calibration cube until I eventually make the printer probe the same spot when measuring the z height of the 3 points and noticed the z value was not the same but actually kept increasing in value by 4.

    Bed x: 100 y: 100 z: 14.33
    Bed x: 100 y: 100 z: 18.68
    Bed x: 100 y: 100 z: 22.99
    echo:endstops hit: Z:22.99

    My guess is there is a bug in the latest firmware causing the leveling to measure the 3 points incorrectly. The same point should be the exact same value.

    Have you experienced any issues with z height of your prints after enabling the feature?

    Since you have a working copy of the firmware, can I get your copy of the firmware zipped up somewhere?

    Thank you.

  • Tim

    I spent a while debugging the firmware code and traced down the bug to the #define Z_RAISE_BETWEEN_PROBINGS line in the configuration.h. Seems this caused the constant increase of 4 for each probe test. Not sure why it increases by the Z_RAISE_BETWEEN_PROBINGS each measurement but changing the value to 0.01 seems to have resolved my incorrect bed measurement issue. Now even with the probes occurring at the edges of my print bed, the probe values are now reporting an almost leveled bed instead of a quite out of level bed.

  • Excelllent work!

    I’m curious, though, do you see the same “plus 4” behavior when the probe points are further apart?

    There has been a litte bit of what you describe going around, that has generally been ascribed to a non-planar (IE: warped) print bed surface. The idea has been that the bed-leveling has assumed an uneven, but still flat surface. If you are using three or four clips to hold your glass in place, you may actually be bending the plane a little bit, causing it to warp, thus throwing off the geometry. The solutiuon has been to use just two clips, front and back, to attach the glass.

    Of course, your discovery would explain things a lot more clearly, and has the potential to offer a much more effective solution!

    Thanks for sharing!

  • John

    I have some questions about these values…

    #define HOMING_FEEDRATE {50*60, 50*60, 150, 0} // set the homing speeds (mm/min)
    my makerfarm values are 50*60, 50*60, 50, 0 Why the large 150?

    #define DEFAULT_AXIS_STEPS_PER_UNIT {80,80,4000,945} (this one is REALLY IMPORTANT!)
    my makerfarm values are 80, 80, 4000, 841 Why do you have 945?

    #define DEFAULT_MAX_ACCELERATION {9000,9000,20,10000}
    my makerfarm values are 1000, 1000, 5, 1000 Why are yours set so high?

    Do I really need to change to the settings you have? My makerfarm settings are very different and it seems like things would come out incorrectly… Any ideas?

    • The values that I changed are actually cut and pasted from a copy of the Makerfarm firmware that I downloaded directly from Makerfarm. What you are doing is actually the method I recommended at the beginning of the post: Poke around and see what’s different. If your printer is running like it should, then by all means copy over the values that are working!

  • John

    Hmmm, I’ve uploaded everything and it homes and auto levels perfectly. BUT… When trying to print something it starts fine but a little in to the print, and the arm tries to come down constantly… Anyone seen this?

  • Mortorojo

    Just wondering what this changes,
    #define DEFAULT_AXIS_STEPS_PER_UNIT {80,80,4000,945} (this one is REALLY IMPORTANT!)
    as my original was
    #define DEFAULT_AXIS_STEPS_PER_UNIT {80,80,4000,841}

    • I guess the copy of the Makerfarm firmware that I was using is older or newer than what you’ve got. If the 841 value is working, then by all means use it!

    • Oh, and to answer the question you ACTUALLY asked: That value is steps for the extruder, often called E-steps. There is a very good, but somewhat cumbersome method to set this, whereby you mark your filament, then tell the printer to extrude, for example, 100mm of filament. You then measure how far your mark moved. It should be, in this case, 100mm. If not, adjust that value until the actual extrusion matches the requested extrusion.

      I’ve actually got an easier way, and I’ll be posting about it soon.

  • John

    Thanks! I looked at the gcode of a part I printed and took out the G28 commands (Homing) in the beginning. I retried the print and it worked fine. Don’t know if it was a coincidence or not, but it worked.

    This is the best print I’ve had to date. The others were good, just this was the best, and with MUCH less work!

  • Mortorojo

    After looking around I noticed that the values you have posted are defaults in RAMPS\Marlin-Graphical LCD\Marlin-Marlin_v1\Marlin\Configuration.h
    while what the other guy and I posted is in
    I believe the Marlin_RAMPS_EPCOS_i38 is what comes pre-installed on the ramps board. While the Marlin-Grphical LCD is an update to the marlin firmware, though not as new an update as the version you linked, as it appears to be missing the bed leveling from the configuration.

    Now as far as uploading the the new firmware I’m under the impression that after making changes to the configuration.h I just launch the arduino IDE open the .pde and begin the upload.

    • Right. The firmware that is on the Makerfarm site is from before the time when the auto leveling was merged. Good catch.

      Right again. Just to make sure, though, before you upload, you might want to look at Configuration.h in the IDE, just to make sure the values are the ones you want.

  • Matt

    When I put in the G28 command in Pronterface it homes all the axis as it should. But then I do a G29 command and the Z axis gets so close to the bed that when the servo arm cant be properly deployed and my hotend nozzle hits glass before the servo arm trys to drop. One thing I’d like to mention, when I am finding the offset of my axis’s from the micro switch on the servo arm the values I come up with are similar to your except my Z value is 29.08 when yours was 8.4. I know the values are different with every machine, but mine seems way off and may be contributing to my issues. Any thoughts??

    • Hmm, there are a couple of things here: First, let me make sure I have this right: You run the G28, and the X&Y axes home, then the servo arm extends and the Z axis homes and the servo arm retracts. When you run the G29, the hotend lowers BEFORE the servo arm extends? It sounds like you may be experiencing a Z-reversal that some folks are seeing. A couple of things to try: If you have RAISE_BEFORE_HOMING set in your Configuration.h, set it to zero, and see if you still get the strange movement. Also, check to see that the connection to your Z-axis endstop is still solid. Mine has broken on me several times, and it always causes strange behavior (I’m working on a different design).

      Let me know if you have any success, otherwise I’ll investigate further.

  • Matt

    Well, I was able to solve this by changing the RAISE_BEFORE_HOMING and RAISE_BEFORE_PROBING to higher values. Now it raises 20 steps before deploying the servo arm and then continues to level the bed. So I have this figured out. Although, when I tried a test print, the Z axis barely raised between layers and I ended up printing a smeared blob of ABS. I think for some reason the Z axis thinks its raising up enough steps, but is way off. Like i said earlier “when I am finding the offset of my axis’s from the micro switch on the servo arm the values I come up with are similar to your except my Z value is 29.08 when yours was 8.4”

    I may be wrong, but is the #define DEFAULT_AXIS_STEPS_PER_UNIT determine how many steps are a millimeter? I tried using the values from the makerfarm firmware and the values you had suggested in your post, same results..

    • That is indeed a large Z-offset. There is an easy sanity check though: Does the probe really look like it’s 3 CM lower than the nozzle of the hotend? Also, jyst to make sure, you did reverse the sign on the offset? IE: 8.4 becomes -8.4.

      With an offset that large, I suspect what might be happening is your printer is trying to start your print below the level of the print bed, so while the Z-axis will shift upward, it’s still basically just sitting on the glass. Again, as a sanity check, try setting the Z-offset to something like -5. If your print now starts way too high above the print bed, we’ll know the offset is the issue.

      As for the #define DEFAULT_AXIS_STEPS_PER_UNIT values, yes, the Z-steps are how many motor steps equals 1 mm of travel along the axis. The vales are, in order, for X,Y,Z, and E. Your Z should be 4000 if you’re using the standard Makerfarm Z setup (Specifically, the formula is: Steps/mm = (motor_steps_per_rev * driver_microstep) / thread_pitch. That works out to be (200 * 16)/0.8 = 4000).

      Again, you can check this by simply using Pronterface or the LCD controller to raise your Z-axis by 1mm, and measuring how far it actually travels.

  • Matt

    Ok, after running into a million issues I decided to start from scratch and make sure I followed every step lined out here and in your videos. So now everything seems to work fine as for the bed leveling process. I ended up with a Z offset of -5.2. But now my Z Stepper Motors sound horrible. Im almost afraid to print with it. So I re-flashed the arduino with the stock MakerFarm code and my Z motors sounded normal. So once again, I re-flashed with the Marlin code I have been working on. And my Z motors sound like garbage disposals. Any idea what could cause that? And thank you so much for taking the time to help out. 🙂

    • There are two possibilities for this: If the motors aren’t moving AT ALL, they are skipping all the steps. Try reducing the Z-value in the #define DEFAULT_MAX_FEEDRATE. I have mine set at 5. If that doesn’t fix it, then you have the “Other problem”. A few people seem to be getting that one, and I’m not sure there is a consistent fix for that one as yet. There are enough people experienceing it, though, that I’m sure something will be along shortly.

  • Matt

    Ok, I’ll play around with the feedrate a bit. Looks like the #define DEFAULT_MAX_FEEDRATE for the Z is set to 2 in both plain copy of Marlin and the Makerfarm firmware. What made you decide to change it to 5? Are there any other changes you made that were not listed in your tutorial? Thanks Michael.

    • Oops. Weird typo or autocorrect or something. That should have been “2.5”, not “5”. Are you sure you’re looking at the right line? This is the one I got from the Marlin github about a minute ago: #define DEFAULT_MAX_FEEDRATE {500, 500, 5, 25} // (mm/sec). I cut the 5 in half to get my motion back. Of course, it appears that things are changing quite rapidly with Marlin, to the point where it seems that my tutorial may be out of date. (“Accurate Bed Leveling”, with additional probing points has been merged!) I didn’t include that value simply because it’s the kind of issue that probably won’t affect every installation. Anecdotally, it seems relatively uncommon at this point.

  • Matt

    I am reading the right line. This is what mine says:

    #define DEFAULT_MAX_FEEDRATE {250, 250, 2, 22}

    I got these values from Marlin v1. They are also the same values in Makerfarms version of firmware. I’ll see if changing those makes a difference.

  • Glenn

    Hi im a little confused ,do i need to copy the thermistortables.h file in the makerfarm map and copy to marlin map and replace the file ?

    • If you are going to be using Thermistor #6 in your Configuration.h, then you will need to use the thermistortables.h from the Makerfarm firmware. To do this, replace the thermistortables.h from the github version of Marlin with the version you downloaded from Makerfarm, and flash Marlin.pde (or Marlin.ino) with the Arduino IDE.

      If you’re using thermistors other than the ones that came with your Makerfarm printer, then you don’t need to use Makerfarm’s table, you can just select the appropriate options from the menu in Configuration.h.

      Does that help?

  • Glenn

    i,m going to try this ,also when im seeing in the makerfarm config (MOTHERBOARD 34)in stead of the 33.
    so i use the 34?

    • The difference between 33 and 34 is simply that 33 expects a controllable fan, while 34 gives up the controllable fan in favor of a second extruder. 34 is the default for the Magma hotend, since it needs to have fan cooling all the time anyway, so the fan is hard-wired to the power supply. That’s really it. If you are using a J-head and want control over your fan, use 33. If you’re using the Magma or other hotend that neds to be constantly cooled, go for 34 and leave the option open for a second extruder.

  • Glenn

    34 it is , thanks for your quik reply!! i will try it

  • Glenn

    flashes my makerfarm with succes but on my display it says mendel ready do you know where to change it ?

  • Glenn

    never mind found it already

  • Glenn

    everything works ok the auto bed level also but when a print started than it is not in the middle of my print bed its like 10 mm more to the richt side is this normal?

    • For a while I was seeing that as well. In my case, it was caused by the “Safe Bed Leveling” option. For some reason, when it moved into the “Safe” zone, it crept slowly along all three axes, effectively shifting the print area about 10mm in the +X direction. I turned the option off and haven’t had a problem since. The version of Marlin I am running, though, is about a month old, which means lots and lots of stuff has changed! 🙂

  • Glenn

    ok i will shut down the safe home,and see wats how its respond

  • Glenn

    strange, i did uncomment the safe bed function and it homes now perfectly in the old position but when i print something it is still +/-1 cm off

  • Glenn

    what kind of e-steps setting do you use on a e3d v5 hot end?

  • Glenn

    I have a problem , when i see your video when you are putting a g28 command it perfectly homes in the corner ,when i hit g28 it set the x on 0 and y on 0 then z moves 1 cm back when z have to raise for the probe at the same time and then measures z . then when im m typing m114 it says x0y0z0 (but it isnt)

    when i put a g28 x0 y0 then it stays in the corner and mm14 it says also x0 y0

    my probe settings are x-22.90 y0.00 z1.27

  • Glenn

    i mean my y bed moves 1cm back ,not my z

  • Glenn

    i did disabled it but still does that, strange isnt it?

    • TAZ427

      Glenn, I’m having the same issue. Both my X and Y axis are printing off by +10mm.

      I checked the GCODE on what I’m printing and then did the some physical measurements and the X and Y axis are both off +10mm.

      This is giving me fits because I’m trying to print something that w/ the Brim (really needed as it curls w/o it.) it’s 204mm along the Y axis (and 160 along the X axis) Tried to do it on a 45 (as it theoretically fits) and found out that servo motor hits the X motor bracket at about 198mm mark (toss in the 10mm offset and this isn’t good.)

  • Greg

    Hi Can you please clarify what the differences (as far as #6) are in thermistortables.h between maker farm’s EPCOS AND maker farm’s full graphical AND marlin’s vanilla table? I can see they are different but why? are they different thermistors or has the EPCOS one been differently calibrated?

    • Good question. Here goes:

      Really, the best way to create a thermistor table is to place a probe inside the hotend, and measure the resistance at a number of (at least three) temperatures. That’s what a thermistor table actually is.

      The table in the standard Makerfarm firmware is one that was made specifically for the thermistor included with the kit. The one in the LCD version, as well as the vanilla Marlin (it appears that the LCD version was not modified) is a secondary table for thermistor #1. The problem, is, if you compare the #6 tables, you can see that the unmodified version will almost certainly allow the hotend to get significantly hotter than the firmware thinks it is. In the best case, this will lead to some confusing indicated print temperatures, and in the worst case, could exceed the hotend’s melting point (especially if the hotend is not all-metal). I am not entirely sure where the unmodified table #6 came from. I’ve heard rumors that it was measured from the outside of the hotend, which seems plausible, but I can’t say for sure.

      The final part of the answer is that “EPCOS 100k” describes a number of different thermistors, and I’m not completely sure which one is included with the kit. The good news is that Colin did generate a thermistor table for it.

  • Greg

    Wow ok, well thanks for the news. Seems a bit of a slippery slope if you didnt know and just read 100k EPCOS and went with that. Would it be better if Colin’s table was actually say 6b rather than replacing 6 all together?

    so as far as replacing the table do we need just the following if statement or are there other sneaky surprises?
    #if (THERMISTORHEATER_0 == 6) || ….

    • As far as I can tell, you should be good to go. Of course, unless you’re creating your own table, the best move is just to copy over the entire file into you newer installation.

  • Dave

    I’m having an issue and can’t figure it out. It seems like everything is working great. The bed leveling routing runs, my numbers are spot on and everything works like it’s supposed to…except when I try to print. I added the G29 code to my Slic3r custom G-Code settings after the G28 command. It heats everything up, runs the bed leveling routine…then just starts printing without lowering the printhead at all.

    The LCD shows that it’s however high off the bed (my probe was a 4.7mm z-offset) but it doesn’t lower .35 or anything. It just prints from there…and obviously doesn’t work.

    Am I missing something?

  • James

    Its been a few months since the last discussion on this. Is this still the easiest method for upgrading the makerfarm Prusa I3 firmware to latest version? Specifically I am interested in the M600 change filament command in the newer version of marlin. Thanks for the support!

    • Hi James –

      The easiest and best method is always going to be the one I suggested at the beginning of the post: Take a Configuration.h that works, and copy all the values into a Configuration.h for the newer version.

      I’m not sure about the history of the M600 command that made it into the official Marlin tree, but I was talking briefly with a user who was working on it. His idea was brilliantly simple, and if it’s the one Marlin is using, I’m sure it will work flawlessly.

  • Matt T

    Thank you very much for the thermistor table information here. It solved a mystery for me while trying to get to a newer “vanilla” release. I was noticing that it wasn’t heating, then during one test, I reflashed to the Makerfarm firmware and the temperature on the LCD immediately “jumped” up 15 degrees. That gave me the hint that it wasn’t actually the heating, but something else – now you’ve completed the picture for me – thanks!

  • Natasha

    I’m looking at enabling the EEPROM in Arduino, but I’m a little confused. Currently mine looks like: //#define EEPROM_SETTINGS
    if I click to comment/uncomment it bolds the text and looks like: #define EEPROM_SETTINGS . Is the #define EEPROM_SETTINGS what I want?


  • Natasha

    Awesome! Thanks!

  • james

    Hello! So I flashed without issue. Everything seems functional for the most part. however, it seems like it takes a LOT longer for my bed to reach 100* temp. Upwards of 20mins. I know it didnt take this long before. I double checked the BEDPID settings and they are set at 255, makerfarm file was 256 but it looked like the max setting was 255 for this version of marlin. Is there any thing else I could be checking? Would the thermistor tables have any affect? You mentioned using “6” and copying the old tables over.

    Thanks for the help

  • james

    I may have answered my own question.. I was using TEMP_SENSOR 6 but didn’t copy over the old temptables file!

    Thanks for the walkthrough!!

  • don

    Hello i followed directions and i try to verify and upload to the board i have prusa i3v printer x endstops inverting was not declared in the scope Marlin_main.cpp:1270: error: ‘X_ENDSTOPS_INVERTING’ was not declared in this scope
    Marlin_main.cpp:1274: error: ‘X_ENDSTOPS_INVERTING’ was not declared in this scope
    Marlin_main.cpp:1278: error: ‘Y_ENDSTOPS_INVERTING’ was not declared in this scope
    Marlin_main.cpp:1282: error: ‘Y_ENDSTOPS_INVERTING’ was not declared in this scope
    Marlin_main.cpp:1286: error: ‘Z_ENDSTOPS_INVERTING’ was not declared in this scope
    Marlin_main.cpp:1290: error: ‘Z_ENDSTOPS_INVERTING’ was not declared in this scope

    • It sounds like you have the inverting lines commented out instead of being defined as “False”. Look for these lines:

      const bool X_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
      const bool Y_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
      const bool Z_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
      const bool X_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
      const bool Y_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
      const bool Z_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.

      Make sure they are set to “false”, but they should not be commented out.

  • Jon

    Were you able to get Marlin working on the i3v with similar steps?

  • don

    Here is what i have
    // The pullups are needed if you directly connect a mechanical endswitch between the signal and ground pins.
    const bool X_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
    const bool Y_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
    const bool Z_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
    const bool X_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
    const bool Y_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
    const bool Z_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.

  • don

    can i email you the config.h file

  • john

    I have done everything you have explain on this tutorial on my prusa i2 and I have a problem with my z axis is not lift after the first layer.
    could you please can give some info to lead me to a solution.

    I will appreciate any subjection from anyone

  • António

    Thank you for your tips.

    I got this error: “rx_buffer” not declared on this scope. What shall I do? Best

  • Don

    how come my post was removed

    • It wasn’t removed. All comments on my blog are moderated as an anti-spam measure. Anything posted has to be looked at and approved by me before it is visible.

  • don

    can i get you to look at my config.h file how can i get it to you

    • It might be a while, but if you want to post your Configuration.h either in the comments here, or in an email via the “Contact Us” link, I’ll try to take a look at it.

  • hello,
    everything works great! thanks very much for the tutorials!

    I am wondering if it possible to slightly change the homing sequence. after the homing is done and before the probe arm is raised, I want to raise the z axis by 1mm so that the back of the probe doesnt catch…is there somewhere in the files where i could change the homing sequence? I tried looking, but i am not quite at this level of programming to understand.


  • I have a prusa i3v with a hexagon .4 hotend (3mm).

    I had issues with my thermistor and temp readouts as well. The temp during a print fluctuates about 10-12 degrees below the set temp….still, but i can work around it. At least it will heat up whereas when i used the prusa makerfarm i3v thermistor file with table 6 it didn’t work at all and would take forever to heat up.

    After the upgrade, taking both the tutorial and all that is mentioned above, my hotend and bed seem too take forever to heat up, the hotend especially. I tried switching back to the original firmware for the i3v and it seemed to go back to normal…After many tests with different configurations of thermistor.h files I decided to go with table 1 with the newest marlin thermistor.h file. it’s ok for now.

    otherwise all is well!
    thanks again!

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>