# Specific 3D Printers, Scanners, & Hardware > RepRap Format Printer Forum > MakerFarm Forum >  Auto Bed Leveling troubles

## dollarz81

So Ive followed zennmasterm's youtube video, then fixed the Z_PROBE_SLED bug https://github.com/Maxigraf/Marlin/c...ee7c45f2ffb2a6

loaded the firmware and now im getting this error:

[ERROR] Error:Printer stopped due to errors. Fix the error and use M999 to restart. (Temperature is reset. Set it after restarting)


Any help please!!!

----------


## dollarz81

It has to be something in the Marlin code. Reloaded the RAMPS firmware and everything is ok.

----------


## dollarz81

Fixed it!!!! wrong motherboard setting!!!


Thanks anyways!!!

----------


## dollarz81

Fix one problem...another arises. Step motors moving super slow. UGh

----------


## dollarz81

When I upload Marlin, I get the following
+Z axis moves extremely slow
-Z axis...no movement; says endstop hit
Same for x and y

Im at a lost here. Any help would be appreciated.

----------


## Roxy

What values do you have for these settings?

//// MOVEMENT SETTINGS
#define NUM_AXIS 4 // The axis order in all axis related arrays is X, Y, Z, E
#define HOMING_FEEDRATE {50*60, 50*60, 150, 0}  // set the homing speeds (mm/min)
#define DEFAULT_AXIS_STEPS_PER_UNIT   {80,80,4000,854.91}  // default steps perunit for ultimaker {78.7402,78.7402,200*8/3,760*1.1}920
#define DEFAULT_MAX_FEEDRATE          {250, 250, 2, 22}    // (mm/sec)

----------


## dollarz81

//// MOVEMENT SETTINGS
#define NUM_AXIS 4 // The axis order in all axis related arrays is X, Y, Z, E
#define HOMING_FEEDRATE {50*60, 50*60, 4*60, 0}  // set the homing speeds (mm/min)

// default settings

#define DEFAULT_AXIS_STEPS_PER_UNIT   {78.7402,78.7402,200.0*8/3,760*1.1}  // default steps per unit for Ultimaker
#define DEFAULT_MAX_FEEDRATE          {500, 500, 5, 25}    // (mm/sec)

----------


## dollarz81

I changed the values to match yours.

When I attempts to move through the different axis, this is what happens.

+Z: endstop hit....no movement
-Z: step motors move a bit slower than normal
+X: endstop hit....no movement
-X: Slow movement
+Y: endstop hit...no movement
-Y: slow movement.


Would it be possible to just post your configuration.h file so I can go through line by line to see where mine has errors?

----------


## dacb

See this thread: http://3dprintboard.com/showthread.p...correct-offset

----------


## Roxy

The fact it won't move at all on the X & Y is probably because you have these set TRUE

#define min_software_endstops false  // If true, axis won't move to coordinates less than HOME_POS.
#define max_software_endstops false  // If true, axis won't move to coordinates greater than the defined lengths below.

My Configuration.h is attached.

Also, it is possible some of the confusion is coming from this if you have the HOME_DIR set to +1.

// ENDSTOP SETTINGS:
// Sets direction of endstops when homing; 1=MAX, -1=MIN
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1

----------


## dollarz81

It fixed the x and y axis, but z motor is still extremely slow.

----------


## Roxy

It is slow during Homing?  Or all the time?   You set that by changing these values:

#define HOMING_FEEDRATE {50*60, 50*60, 4*60, 0}  // set the homing speeds (mm/min)    Set to 7 or 8 *60 if your hardware can handle it.
#define DEFAULT_MAX_FEEDRATE {500, 500, *5*, 25} // (mm/sec)   Bump this up to 50 to go faster...   Or even higher if you dare and have a reason to.
#define DEFAULT_MAX_ACCELERATION {9000,9000,100,10000} // probably 200 or 300 is safe here

----------


## dollarz81

i figured it out!!

It was
 #define DEFAULT_AXIS_STEPS_PER_UNIT   {78.7402,78.7402,400.0*8/3,760*1.1}  // default steps per unit for Ultimaker

Thank you so much for your help Roxy.

----------


## dollarz81

Ugh.....troubles never end!!!!!

The servo does not retract before printing begins.

Help please!!

----------


## Roxy

Can you engage and retract the server using the M280 command?    Can you post your Configuration.h file please.

----------


## dollarz81

Yes the M280 command works.

----------


## Roxy

Did you do a G29 ?   That should retract it.   But I know what you are seeing.  I just fixed it in my copy of the code 30 minutes before you posted.    In Marlin_main.cpp search for

static void homeaxis(int axis) {

Go about 70 lines further down in the file.    Change the code block:


#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
    if (axis==Z_AXIS) { 
        do_blocking_move_relative(0, 0, Z_RAISE_BETWEEN_PROBINGS);
   retract_z_probe();
}
#endif

to include the retract_z_probe(); function call.  You will need to add everything in RED.

----------


## dollarz81

do_blocking_move_relative(0, 0, Z_RAISE_BETWEEN_PROBINGS);

was not in my code

----------


## dollarz81

ok, i get what your saying

----------


## dollarz81

And more troubles. I am going to give up on auto leveling soon. Takes less time to manually level the bed. 

The nozzle starts printing a few mm above the bed.

----------


## Roxy

So...  You need to tweek the Z-Probe Offset.   Make it a bigger negative number.   But go small...  You don't want to drive the nozzle into the bed.

A couple of changes, compiles and firmware loads and you will be there.

----------


## dollarz81

I think Im having the same issue as Pronus is having in the other thread. 

I pick a point on the bed and set it to x0 y0 z0 with the G92 command. 
Then set the z probe to that same spot and get the values of x-30 y7 z8.10
enter those in marlin as x30 y-7 z-8.10 and upload

Then enter g28 code....here the nozzle first goes to the back right of the bed, where the endstops and then moves to the point that I entered as the g92 location....except its shifted a bit. Then I manually put the nozzle back to the initial point on the bed and hit m114 and I get x106.60 y133.30 z-4.30

----------


## dollarz81

So when i manually find x0 y0 z0 it is in the back right corner now

----------


## Roxy

> I think Im having the same issue as Pronus is having in the other thread. 
> 
> I pick a point on the bed and set it to x0 y0 z0 with the G92 command. 
> Then set the z probe to that same spot and get the values of x-30 y7 z8.10
> enter those in marlin as x30 y-7 z-8.10 and upload
> 
> Then enter g28 code....here the nozzle first goes to the back right of  the bed, where the endstops and then moves to the point that I entered  as the g92 location....except its shifted a bit. Then I manually put the  nozzle back to the initial point on the bed and hit m114 and I get  x106.60 y133.30 z-4.30


Dollarz81, can you turn off your EEPROM settings in Configuration.h ?     Rebuild it and load the firmware into your printer.   And see if the problem is still there.   And then post your Configuration.h file?

----------


## dollarz81

Still not working

----------


## Roxy

EEPROM is still turned on in that Configuration.h file.

#define EEPROM_SETTINGS
//to disable EEPROM Serial responses and decrease program space by ~1700 byte: comment this out:
// please keep turned on if you can.
#define EEPROM_CHITCHAT

Can you post a picture of your bed and nozzle with the probe down?   I'm wondering if your probe offsets are inverted.

----------


## dollarz81

Eeprom were undefined the whole time....oops. I turned them on and tried it. Still the same. Is the G92 command supposed to set the home position on eeprom?

----------


## Roxy

EEPROM is still turned on in that Configuration.h file.   To turn it off add the RED comments:

//#define EEPROM_SETTINGS
//to disable EEPROM Serial responses and decrease program space by ~1700 byte: comment this out:
// please keep turned on if you can.
//#define EEPROM_CHITCHAT

*Can you post a picture of your bed and nozzle with the probe down?   
I'm wondering if your probe offsets are inverted.*

----------


## Pronus

Dollarz81,

I responded to your question in the thread I started, but I also have a question for you. When you run G28, is the hotend staying at X0,Y0 to probe the Z axis? That is how I wasn't noticing the contact of the x endstop. With G28 my hotend was moving to X0/Y0 and would just move up and down to probe the Z axis and not move to the middle of the bed. So when I would do a G29, it would just go up and back down to make the first probing point because the x endstop was already activated. When I swapped to Roxy's code base, G28 would move to X0,Y0 and then move the x/y axis to the middle of the bed to probe the Z axis because of the change in Z Safe Homing in the configuration.h. Then doing a G29 made it obvious that I was making contact with x endstop on the first probing point. Although it was obvious, it took me a while to notice it  :Wink: 

The change I found out was in the 

#ifdef Z_SAFE_HOMING

    #define Z_SAFE_HOMING_X_POINT (X_MAX_LENGTH/2)    // X point for Z homing when homing all axis (G28)
    #define Z_SAFE_HOMING_Y_POINT (Y_MAX_LENGTH/2)    // Y point for Z homing when homing all axis (G28)

Before switching to Roxy's code base, my x and y axis z safe homing points were set to 0

----------


## dollarz81

Roxy, 
     EEPROM was turned off before I posted the config.h file. I turned it on before I posted it. EEPROM was turned off this whole time. 


Here is a video of what happens when I hit the g28 code. 

http://youtu.be/bhh-fVncnjU

----------


## Roxy

That doesn't look too crazy.    You have:

  #define X_PROBE_OFFSET_FROM_EXTRUDER 30
  #define Y_PROBE_OFFSET_FROM_EXTRUDER -6.30
  #define Z_PROBE_OFFSET_FROM_EXTRUDER -7.60

The depth perspective is difficult to access from the picture and video.  But it looks like you have the origin in the back right corner.  That means with the 

#define Y_PROBE_OFFSET_FROM_EXTRUDER -6.30

definition the probe should be further back than the nozzle by 6.3mm.  Is that correct?

----------


## dollarz81

yes thats correct

----------


## Roxy

> Eeprom were undefined the whole time....oops. I turned them on and tried it. Still the same. Is the G92 command supposed to set the home position on eeprom?


I just reviewed the G92 code.  It does not save the settings to EEPROM.   Can you explain why you are using the G92?  It doesn't seem like you should need to use that.   What happens when you try to print?

----------


## dollarz81

I'm using the G92 code to save the X0 Y0 Z0 home position per zennmaster video. When I try to print, it prints about 8 mm above the bed.

----------


## dacb

Did you already G28 X0 Y0 Z0?

Edit: Maybe that is isn't relevant, but I always proceed every leveling operation with the G28 including Z0 so that there is an approximate baseline to begin with.  Before I began doing this, the other probing commands might not find the bed and would complete a probing cycling without every finding a true Z0 and prints would just spaghetti into the air.

----------


## dollarz81

Yes I always g28 before and after g29. It's when I do the first g28 after I set g92 that it looses the X0 Y0 Z0.

----------


## Roxy

> Yes I always g28 before and after g29. It's when I do the first g28 after I set g92 that it looses the X0 Y0 Z0.


This is wrong!   The G28 sets the Bed Level Correction matrix to unity.  You may as well not do a G29 if you are going to follow it with a G28.

And in fact, it is worse than that...   I forget who was involved, but somebody said even hitting a 'Home' button in PronterFace would wipe out the matrix and reset it to unity.   I added some code to print the matrix upon request just so I could verify if that was true.  It was true.  The PronterFace Home buttons do G28's with a specific axis and the first thing the G28 does is set that matrix to unity.

----------


## dollarz81

Ok let go over the procedures to see if I'm missing something. 

Make a point on the bed to set as home position.
Manually put the nozzle to that point and enter G92 X0 Y0 Z0
Manually put the Z probe to that exact point and enter M114 to get offset values....which are X-30 Y6.30 Z7.60.....enter these in Marlin as X30 Y-6.30 Z-7.60

Now when I enter G28 the nozzle moves to the back, right corner then returns to the original point, except x y z no longer 0. xyz are all off. When I manually find 0 it is in the back right corner. When I try to print it goes to the point I created but starts printing about 10mm above the bed.

----------


## Pronus

I watched the video and you don't have the same issue I did. I noticed though that you don't have any zip ties on your Z motors. It might be a good idea to zip tie the tubing to the z motors and another zip tie for the tubing on the threaded rods. When the z motors warm up the tube can and often will slip. This is especially true with all the extra moving that the Z motors do with bed auto leveling.

----------


## dollarz81

So do I start my print after the G29?

----------


## Roxy

> Now when I enter G28 the nozzle moves to the back, right corner then returns to the original point, except x y z no longer 0. xyz are all off. When I manually find 0 it is in the back right corner. When I try to print it goes to the point I created but starts printing about 10mm above the bed.


That is how it should be...  Unless you need it to be different, when you home an axis, it will set it to 0.0 at that corner.   If you really have a need to put (0,0) some where else like the center of the bed, this can be done.   But you have to mess with Configuration.h settings and very possibly make matching changes to your slicer.

----------


## Roxy

> So do I start my print after the G29?


Yes.   You should put a G28 and a G29 in the startup code of your Slicer.   Along with what ever else you need to get the bed temp and nozzle temp correct.

----------


## dollarz81

Should EEPROM be on?

----------


## dollarz81

IT'S WORKING!!!..........Except once it starts printing the nozzle is still like .03mm too high above the bed.

----------


## dacb

Have you rechecked your nozzle to foot distance?

----------


## dollarz81

I think its the first layer height. It was set to 3.5. I just set to 1.5 and testing now.

----------


## dollarz81

Now its like the extrusion isnt fast enough

----------


## Roxy

> I think its the first layer height. It was set to 3.5. I* just set to 1.5 and* testing now.


This sounds awful high.    If you have standard stepper motors, it would make sense to start about 3/4 of your nozzle diameter.

----------


## dollarz81

Didn't work anyways. Plus it's not extruding any filament for the first 2 layers or so. I'm about to give up.

----------


## Roxy

> Didn't work anyways. Plus it's not extruding any filament for the first 2 layers or so. I'm about to give up.


If you are using Slicer, what I do is this:   Goto 'Print Settings' and then on the 'Skirt and Brim' page, I set 'Minimum Extrusion Length' to 10mm.  What this does is run a circle around your print for 10mm of filament.    For me...  And probably for you...   That is enough to make sure any drip of filament out of the hot nozzle is replaced with fresh filament.  You may be fighting a problem where having the nozzle hot and just sitting there causes the filament to ooooze out so it is not there and ready to go...

----------


## dollarz81

Increasing the skirt did help with extrusion. But the nozzle is sitting approximately 1.45mm above the bed when printing starts. Ive changed the Z_PROBE_OFFSET but the nozzle stays the same distance.

----------


## Roxy

> Increasing the skirt did help with extrusion. But the nozzle is sitting approximately 1.45mm above the bed when printing starts. Ive changed the Z_PROBE_OFFSET but the nozzle stays the same distance.


If the EEPROM is turned off...  The only place it can get a distance from is the Configuration.h file.   Please verify both EEPROM #define's are turned off and that firmware is loaded in the board.    If this is the case, changing  #define Z_PROBE_OFFSET_FROM_EXTRUDER in the Configuration.h file will move the nozzle up and down.

----------


## dollarz81

Yep.....Its working now!! I really appreciate all the help Roxy.

----------


## dollarz81

Only now my bed wont reach the set temp

----------


## Roxy

> Only now my bed wont reach the set temp


Are you using PronterFace?   Does it heat up at all?   Do you have the right thermistors specified in the Configuration.h file?

And you will need to print a few 'first layers' to get the Z-Height correct.   Once it is close, you still need to move it a little at a time until it is perfect.    And unfortunately, you almost have to learn for yourself what that is by watching it.   With that said, once you get it dialed in...  Almost always, the first layer of a print will go down perfect.

----------


## dollarz81

I'm using repetier. It does heat up but stops at 87. I'll check on thermistor settings.

----------


## dollarz81

I don't see anything wrong in the configuration.h file. But what do i know. Can you take a look at it for me.

----------


## printbus

> I don't see anything wrong in the configuration.h file. But what do i know. Can you take a look at it for me.


Elaborate on the error.  Is it that you can't set the temp higher than 87 or that the temp won't go above that even if you set it higher? An earlier picture implies you have an i3v.  What is the display showing as far as set & actual temp when this is happening? What happens if you try and set the bed temp higher using the LCD panel instead of repetier?

----------


## Pronus

You might be experiencing a similar problem that I did with my heat bed.  Try hard wiring the heat bed straight to your power supply and see if it will reach above 87C. If it gets up to temperature then the problem is not the heat bed itself. Hard wiring it like that is just for testing purposes though and you will not have any way of controlling it. 

I think your problem could be from switching to a newer version of Marlin to use auto bed leveling. I found out Makerfarm uses a different thermistortables.h file than the newer versions of Marlin. Copying my old thermistortables.h file from my original Markerfarm configured version of Marlin over to the new version of Marlin with bed auto leveling fixed my problem with the bed not heating up right.

----------


## dollarz81

With original RAMPS firmware I had no problem getting above 90. With Marlin I have the bed set at 100 for ABS but it stops at like 87

----------


## Roxy

> I found out Makerfarm uses a different thermistortables.h file than the newer versions of Marlin. Copying my old thermistortables.h file from my original Markerfarm configured version of Marlin over to the new version of Marlin with bed auto leveling fixed my problem with the bed not heating up right.





> With original RAMPS firmware I had no problem getting above 90. With Marlin I have the bed set at 100 for ABS but it stops at like 87


I think it would be wise to check the ThermistorTables.h file and see if you have similar values now compared to what used to be there.  Do you know the constants for your thermistor?   I suspect if you change your thermistor type the problem can be remedied.

----------


## Pronus

From what I understand Makerfarm I3 and I3V's use a 100k EPCOS thermistor. It even says in the configuration.h file (100k EPCOS - Not as accurate as table 1 (created using a fluke thermocouple) (4.7k pullup)

I remember figuring out the problem when I had my original firmware from Markerfarm loaded and I had my bed turned up to around 90C. I turned off the printer and quickly uploaded to the newer version of Marlin with the bed auto leveling. When I turned my printer back on the bed was actually reading at least 10 degrees higher than before I even turned off the printer. I knew there was no way I turned off the printer for about a minute and the bed actually got hotter lol.

As soon as I copied over the thermistortable.h file to my newer version of Marlin, it totally fixed my issues.

----------


## Roxy

> As soon as I copied over the thermistortable.h file to my newer version of Marlin, it totally fixed my issues.


The only bad thing is you don't want to be copying old files into new releases all the time.  I bet there is a thermistor type in the new file that accurately models what you have.  If that could be figured out, it would be safer and cleaner to just change the thermistor types in Configuration.h to the type that is correct.  It kind of sounds like the type declared for the Makefarm isn't right ???

----------


## dacb

IIRC, table six is different. I don't copy the table over, I have a diff that I patch in to fix the table, but that's the best I've been able to find. Here is my diff with that table: http://3dprintboard.com/showthread.p...ll=1#post26056

----------


## Roxy

You are using a Type-6 Thermistor???   Can you post the old?    I went through this a little bit ago because my thermistor broke one time I was unclogging my nozzle.  I ordered some thermistors off of eBay but could not get exactly what I needed at first.   So...  I ended up having to learn about all the constants and how the table is constructed.   If you post the old (working) and confirm it is a Type-6 Thermistor I'll take a look.

I just compared the Type-1 to Type-6 which are supposedly for the same thermistor.   There is a lot of deviation once you get above 150 C.

----------


## dollarz81

Everything is working great. I really appreciate all the help.

----------


## TopJimmyCooks

Going from memory here, but Zennmasterm in one of his videos about upgrading marlin for a makerfarm i3 mentioned that thermistor table 6 is what comes with the stock makerfarm firmware based on the supplied currently shipping thermistors, but when upgrading to newer Marlin it is safe to switch to table 1.  Check the video though.

----------


## printbus

The Type-1 vs Type-6 issue here is, IMO, a classic example of what can go wrong in open source firmware where people can make whatever changes they want.  

1) Both type 1 and type 6 are for the same thermistor type.  There's a comment in the configuration.h file that reads "// 6 is 100k EPCOS - Not as accurate as table 1 (created using a fluke thermocouple) (4.7k pullup)".  Why are there two definitions for the same thermistor?  Someone _wants_ to use the less accurate one?  

2) Comments in the code are unclear.  Does the "created using a fluke thermocouple" apply to the type 6 data or is it explaining why the type 1 table is better? If it applies to type 6, it's hard to believe it would be less accurate than type 1.  If it is explaining why type 1 is better, why in the heck isn't the comment placed with the type 1 data?  

3) Somewhere along the way, MakerFarm picked up data for Type 6 that differs from the Marlin baseline.  Dacb has posted the diff info.  Is it just old data and the "not so accurate" type 6 data has been improved in newer Marlin versions?  Did MakerFarm (or their supplier) tailor the table data for Type 6? 

4) Assuming MakerFarm had some reason to modify the data for Type 6, comments in the code explaining the change would have been nice. Same as it would have been nice for other places MakerFarm tailored things to have been commented.  Without comments, we have no way to know whether the changes are because they're using something other than an EPCOS, had some test data to indicate they could improve on the "not so accurate" Type 6, or had some reason to want temperatures to be "scaled" from reality.  

<rant off>

----------


## TopJimmyCooks

I agree with this rant. ^^^

The only thing that I might add is that the epcos 100K thermistor seems to be very widely used and well understood.  Should be some consensus on how to table it.  

Another item:  makerfarm sells their own version of the prusa version X bed heater pcb, perhaps changes were made to better reflect measured temperatures of this heater.  would be nice if that data was made known.

----------


## Roxy

> 1) Both type 1 and type 6 are for the same thermistor type.  There's a comment in the configuration.h file that reads "// 6 is 100k EPCOS - Not as accurate as table 1 (created using a fluke thermocouple) (4.7k pullup)".  Why are there two definitions for the same thermistor?  Someone _wants_ to use the less accurate one?


It was a while ago...  I don't remember everything I went through (and learned).   But I think the answer is close to this:   Depending upon what pull up resistor value you use, you get a table with different numbers.   While Type-1 and Type-6 are for the same thermistor,  my guess is they were generated with different pull up resistor values and as a result, you get different numbers in the table.

I don't know that this is true, but if so...   It should be much better documented so this kind of confusion doesn't happen.

----------


## printbus

Both type 1 and type 6 are for 4.7K pullups.  

Well, at least if you put any faith in the comments....

----------


## Roxy

> Both type 1 and type 6 are for 4.7K pullups.  
> 
> Well, at least if you put any faith in the comments....


OK!  I didn't see that.   Obviously...  one of those entries should be removed.

----------


## printbus

OK, maybe more rant. Perhaps someone finds it amusing.  

I think the lesson here is to put more faith in your *relative* temperature results than in the *absolute* values.  Pay more attention to the results you are getting and adjust accordingly than what others are using for temperature settings and what filament manufacturers offer as recommended temperatures.

Some day, I may revamp what I use in the thermistor tables based on data from a manufacturer for a thermistor I've purchased from a trusted component supplier.  These are all typically 1% parts, and IMO 1% manufacturer specs are going to potentially be far more accurate than what some guy (like me) measured in his basement or home oven with some cheap IR thermometer or other questionable calibration scheme.  Frankly, I'd rather want to see and be working with true measurement data (and likely throwing out everything I had previously learned about temperatures on my printer) than temperatures that have been biased in an attempt to compensate for heating and/or measurement errors, whatever the source.  But even this gets challenging.  I've noticed most reprap suppliers indicate they are providing EPCOS part number B57560G104F thermistors, since that's the reprap "standard".  As best I can tell, TDK/EPCOS made that an obsolete part number years ago.  So, are these suppliers "helping" by translating to the current part number behind the scenes for us?  Or are they really obtaining their thermistors from some low cost "EPCOS compatible" source and the parts are really of unknown specs? And of course, the code comments only say the tables are for an EPCOS 100K NTC thermistor.  Jeez - I think they have about a dozen different ones.    

Finally, having done my own temperature-control designs, I had to sort of chuckle when I first saw the 1K or 4.7K pull-up voltage-divider approach used on the reprap boards.  This simple approach sets up the possibility for measurement errors due to self-heating in the thermistor (current flowing through a resistance dissipates heat).  It might work "OK" for the higher temperatures we're using in the printers, but can be unbelievably inaccurate at measuring lower free-air temperatures. Feel free to search on "thermistor self heating" for more info.

----------


## Roxy

> I think the lesson here is to put more faith in your *relative* temperature results than in the *absolute* values.  Pay more attention to the results you are getting and adjust accordingly than what others are using for temperature settings and what filament manufacturers offer as recommended temperatures.


Agreed.   It is kind of like when I was younger, my mother would always set the oven 5 or 10 degrees hotter because that was what was necessary to get things to bake right.  You just knew that was the case and adjusted things.

----------


## TopJimmyCooks

Is there a defined testing methodology described somewhere?  Hell, I've got a fluke multimeter with a thermocouple somewhere . . . I'm not saying for everyone to calibrate their own, but i would be happy to publish my Epcos clone thermistor and makerfarm 8" bed results.  control a few variables like ambient temp and top surface of bed/type of glass and it should be close enough.

----------


## printbus

> Agreed.   It is kind of like when I was younger, my mother would always set the oven 5 or 10 degrees hotter because that was what was necessary to get things to bake right.  You just knew that was the case and adjusted things.


Exactly. BTW, if that was an oven with the old mechanical type knob, there would have likely been a screw on the back of the knob that allowed the knob dial to be adjusted for calibration. I offered to set my mom's dial once, but she refused since it would have thrown off everything she knew about baking in that oven.  




> Is there a defined testing methodology described somewhere?  Hell, I've got a fluke multimeter with a thermocouple somewhere . . . I'm not saying for everyone to calibrate their own, but i would be happy to publish my Epcos clone thermistor and makerfarm 8" bed results.  control a few variables like ambient temp and top surface of bed/type of glass and it should be close enough.


There probably is, but it's likely buried in blogs or the reprap wiki.  And you'd have to start with the fundamental question about whether the thermistortables file is meant to capture theoretical temperature measurement data for just the thermistor by itself, or is meant to include compensation for real-world losses affecting the net temperature gain from the heaters involved.  

--------

I couldn't resist the temptation and spent some time digging into the data, starting with truth data direct from TDK/EPCOS.  This was quite interesting.  The amount of raw data is a bit overwhelming. If I think of a way to compile the info, I'll start another thread to share it. Here, however, is a summary.  

The type 1 data in the thermistortables file closely follows the resistance-vs-temperature data provided by EPCOS, after converting for the simple voltage-divider approach feeding a 10-bit analog to digital conversion in the Arduino Mega processor.  This suggests that the thermistortables data is intended to reflect data for just the thermistor by itself, not factoring for any real-world effects on the measurement.  I'm not saying this is particularly good or bad - it's just the approach being used.  

As Roxy pointed out, the type 6 data IN THE MARLIN BASELINE differs considerably for the higher end of the temperature curve.  My conjecture is that Type 6 was originally someone's attempt at coming up with a set of data that did reflect real-world effects on the measurement. This is supported by the comment in configuration.h for Type 6 where it says "created using a fluke thermocouple".  

And then there's the type 6 thermistortable data provided by MakerFarm. It turns out that this data is very close to being the same curve data as for Type 1.  Here I conjecture that MakerFarm (or their firmware source) started using the Marlin type 6 data and found it undesirable. For whatever reason, the type 6 thermistortable data was altered instead of just changing configuration.h to specify use of the type1 data.  Comments in the MakerFarm configuration.h file that imply the type 6 thermistor data is not as accurate as type 1 are wrong, since the comments refer to thermistortable data that has been changed in the MakerFarm baseline.

I doubt anyone would notice the difference between using Type 1, or using Type 6 as long as the MakerFarm thermistortable alterations go along with it.    I would NOT, however, pull in the Marlin thermistortables.h file and stick with the Type 6 setting in configuration.h.  That'll give you some wonky temperature results, as Pronus indicated earlier. You'd still be able to make it work - your "oven knob" would just be off more than it should be and it might take you a while to get used to adjusting the temps correctly. I can't help but wonder how many people have unknowingly struggled with that.

FOLLOWUP COMMENT: The compilation of data is now available here - http://3dprintboard.com/showthread.p...rtables-h-data

----------

