# Specific 3D Printers, Scanners, & Hardware > RepRap Format Printer Forum > MakerFarm Forum >  Rambo Servo Setup for Auto Bed Leveling for Noobs

## sniffle

*This is a Work in Progress*  

It is assumed that since you are building a 3d printer you have a basic working knowledge of tools, electronics, general basic rules of electricity/physics, and can think intelligently.

*What this guide is:*

This guide is a wiring instruction/firmware setup for a servo motor in the use of Auto Bed Leveling(abl) on the RAMBo board and a supplement to Zennmaster's ABL guide for the Makerfarm Prusa i3 to make corrections necessary for it's use with the RAMBo board

*What this guide is NOT:*
This is not a guide for setting up, installing, firmware configuring, and finding offsets for abl.

look here for a very well documented guide, as well as designs to print in ABS.  It is a 3 (or 4 depending on your working knowledge) part guide to completely setup ABL

http://zennmaster.com/random-things/...nd-basic-setup


*What you will need:
*
An SG90 Servo available on E-bay for cheap and 5 packs are under 15$  I would suggest getting a 5 pack just in case you fry one and it is easy to do
http://www.ebay.com/sch/i.html?_from...=sg90&_sacat=0
As of this posting a 5 pack is $11.99 and ships from the US.

I will be using the servo pack i bought as an example in this guide
http://www.ebay.com/itm/5PCS-x-SG90-...item5d3df51e9e

The spec sheet for the servo's you bought
http://datasheet.sparkgo.com.br/SG90Servo.pdf

The user guide for the RAMBO 1.1b board from reprapelectro
http://reprapelectro.com/wp-content/...ser-Manual.pdf

the spare strip of pins that are provided in the kit

An endstop extension that was provided with the maker farm kit and still has all 3 wires, red black and blue.


*The guide(Hardware):

*Open the servo spec sheet, Inside you will need to find the color code for your respective servo

My servo's were color coded 
Brown - Ground
orange - PWM
red - VCC or constant power

at this point order doesnt matter as long as we know what colors do what

*next:

*Open the Reprapelectro User Guide to page 48

at the bottom of that page you will find the wiring pin outs for MX1-MX3 on the Motor_EXT pins



In the above image:
 the Red pins nearest the tiny "1" are the VCC
the Blue pins are the Ground
and the yellow pins are the PWM

*Next:*

Grab your endstop wiring from the wiring kit.

we will be matching the wires up on the endstop wiring to the servo wiring as follows:

Red will be to VCC
Black will be to Ground
Blue will be to PWM

connect the wires using the means you believe proper, I used the spare pins provided in the kit to make a male plug for the female servo connector and made all the wiring changes there so that in case the servo ever dies i only have to replace the servo and plug it in instead of having to cut and resolder everything.

*CAUTION*
*IF you get the polarity wrong you WILL burn up the control board inside the servo!  DO NOT CONNECT SERVO WHILE THE PRINTER IS POWERED ON!*


At this point you have a servo that will reach the hot end and will be properly wired and able to be plugged into the MX ports in the Motor_EXT pins.  

Go ahead and plug it into the MX port of your choice.

Make sure the red wire on the extension is at the "1" pin. and the blue wire is on the 3rd pin.

on to the software.

*The Guide(Software/Firmware):

*At this point you should be somewhat following along with zennmaster's guide as well, as this post is a supplement to that guide for rambo specifics.

Open the rambo user guide to page 48-49, depending on the which MX pin set you chose you will need to get the PWM pin number for PA0 PA1 or PA2
they are listed on page 49 as either 22, 23, 24.

After downloading the current version of marlin you will need to open the pins.h file in your favorite text editor(i use notepad++)

press Ctrl+F and type in rambo and hit find.  This will take you to the rambo section of the pins.h file.


you will need to paste the following into the pins.h file after #define LARGE_FLASH true



```
#ifdef NUM_SERVOS
 #define SERVO0_PIN <servo PWM pin>  //replace <servo PWM pin> with the corresponding MX pin
 #if NUM_SERVOS > 1
 #define SERVO1_PIN -1
 #endif
 #if NUM_SERVOS > 2
 #define SERVO2_PIN -1
 #endif
 #if NUM_SERVOS > 3
 #define SERVO2_PIN -1
 #endif
#endif
```


If you have been following the zennmaster guide, as well you will have also enabled ABL and copied all of the i3V settign over to the configuration.h file as well.  Once all of that is complete your servo will be working and you can move on to the part 3 of zennmaster's guide which will guide you through the process of retraction angles and offsets.

----------


## sniffle

I may try to go into more detail later if its needed but for now I think this is pretty understandable and step by step.

----------


## rhonal89

Thanks.  Bought the same servo and you.  Right now am just preparing for a paint job on the frame.

----------


## sniffle

So good news, in Marlin accepted my pull request to the development branch that adds notes for the Rambo Fan and best servo pins and Servo support to the Pins.h

So if you are pulling the most recent version of marlin you no longer have to add things to pins.h just change the servo0 if prompt to the pin you are using. :-)

----------


## adamfilip

im using MX3 so my pin is 24

im confused as to what im changing to this

// servo support
#ifdef NUM_SERVOS
 #define SERVO0_PIN 22 //motor header MX1
 #if NUM_SERVOS > 1
 #define SERVO1_PIN 23 //Motor header MX2
 #endif
 #if NUM_SERVOS > 2
 #define SERVO2_PIN 24 //Motor header MX3
 #endif
 #if NUM_SERVOS > 3
 #define SERVO2_PIN 5 //pwm header pin 5
 #endif
#endif

----------


## sniffle

Change 22 to 24

Thats it


If i have some time today i will update this to reflect the changes.

----------


## adamfilip

I keep getting a Endstop hits Z, message when im trying to manually control z height, and its not hitting anything

----------


## sniffle

Check the zennmaster videos on youtube... There is an option in the cobfiguration.h to allow going below software endstops and the x y or z can become negative in value.

----------


## adamfilip

i have entered my probe offset but now it wont compile
give me an error

  This report would have more information with
  "Show verbose output during compilation"
  enabled in File > Preferences.
Arduino: 1.0.6 (Windows NT (unknown)), Board: "Arduino Mega 2560 or Mega ADK"
In file included from /Marlin.h:22,
                 from BlinkM.cpp:5:
/Configuration.h:447:9: error: floating constant in preprocessor expression
/Configuration.h:452:13: error: floating constant in preprocessor expression
/Configuration.h:456:9: error: floating constant in preprocessor expression
/Configuration.h:461:13: error: floating constant in preprocessor expression

these are my offsets

  #define X_PROBE_OFFSET_FROM_EXTRUDER 51.5
  #define Y_PROBE_OFFSET_FROM_EXTRUDER -8.6
  #define Z_PROBE_OFFSET_FROM_EXTRUDER -10.4

here is also my endstop settings
can someon have a look over,

#ifndef ENDSTOPPULLUPS
  // fine endstop settings: Individual pullups. will be ignored if ENDSTOPPULLUPS is defined
   #define ENDSTOPPULLUP_XMAX
   #define ENDSTOPPULLUP_YMAX
   #define ENDSTOPPULLUP_ZMAX
   #define ENDSTOPPULLUP_XMIN
   #define ENDSTOPPULLUP_YMIN
  // #define ENDSTOPPULLUP_ZMIN
#endif


#ifdef ENDSTOPPULLUPS
  //#define ENDSTOPPULLUP_XMAX
  //#define ENDSTOPPULLUP_YMAX
  //#define ENDSTOPPULLUP_ZMAX
  #define ENDSTOPPULLUP_XMIN
  #define ENDSTOPPULLUP_YMIN
  #define ENDSTOPPULLUP_ZMIN
#endif


// 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.
//#define DISABLE_MAX_ENDSTOPS
//#define DISABLE_MIN_ENDSTOPS


// Disable max endstops for compatibility with endstop checking routine
#if defined(COREXY) && !defined(DISABLE_MAX_ENDSTOPS)
  #define DISABLE_MAX_ENDSTOPS
#endif


// For Inverting Stepper Enable Pins (Active Low) use 0, Non Inverting (Active High) use 1
#define X_ENABLE_ON 0
#define Y_ENABLE_ON 0
#define Z_ENABLE_ON 0
#define E_ENABLE_ON 0 // For all extruders


// Disables axis when it's not being used.
#define DISABLE_X false
#define DISABLE_Y false
#define DISABLE_Z false
#define DISABLE_E false // For all extruders
#define DISABLE_INACTIVE_EXTRUDER true //disable only inactive extruders and keep active extruder enabled


#define INVERT_X_DIR false    // for Mendel set to false, for Orca set to true
#define INVERT_Y_DIR false    // for Mendel set to true, for Orca set to false
#define INVERT_Z_DIR true     // for Mendel set to false, for Orca set to true
#define INVERT_E0_DIR false   // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E1_DIR false    // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E2_DIR false   // for direct drive extruder v9 set to true, for geared extruder set to false


BTW my X and Y have reversed stepper plugs

----------


## adamfilip

here is my current config h file for reference
Configuration.h

----------


## sniffle

what is the error it throws when you try to compile it?

edit: nevermind i cloned the git repository again and dropped your configuration.h into it.  I know what is causing it, I had the same issue.  Give me a few to test an idea, and i might be able to give you a fix and If it works for you i'll try to push a fix to the main branch as well to permanantly fix it.  I'm at work so i wont be able to test it... you'll have to be my guinea pig :-P

----------


## adamfilip

Sounds good, thanks for your help!

----------


## adamfilip

Do you remove the manual adjustment springs once abl is working?

----------


## sniffle

The issue is in the grid point checking algorithm, that checks to make sure we aren't going to probe outside the bounds of the print surface.  There is a preprocessor check that says you can't compare floating point numbers, and that is what is throwing the error.  I may get Roxy in on this one sice i don't know C that well.

you can comment out that entire block of code, and it will compile/run but it may go out of bounds and the only way to do so is to manually press the endstop

I'm actually running Roxy's version of the firmware right now.  I need to get this figured out...


I left my springs, I just don't adjust them anymore.


and speaking of roxy in case she reads this... 

Roxy here is a link to the code in question as well as the error

http://pastebin.com/mJwSVMqF

----------


## adamfilip

ok i commented out that section and i flashed the firmware
I was able to home all axis but when i try and autolevel the prob tried to find Z off the table to far over X

----------


## adamfilip

i ended up moving my x and y ends stops in so that it wont overhang
but now when i try to home Z it says "z probe out. Bed"

----------


## sniffle

So i talked to @EvdZ|Ultimaker on the #marlin-firmware irc channel, he told me to remove the decimals to make it a whole number, the exact positioning of the probe is not critical.  which somewhat makes sense and makes computations easier.  and when i did this that fixed the problem.


this shoudl be your offset

  #define X_PROBE_OFFSET_FROM_EXTRUDER -51
  #define Y_PROBE_OFFSET_FROM_EXTRUDER 8
  #define Z_PROBE_OFFSET_FROM_EXTRUDER -10

----------


## adamfilip

ok i will try that. i noticed that im recently getting upload errors

Binary sketch size: 162,052 bytes (of a 258,048 byte maximum)
avrdude: stk500v2_recv(): checksum error
avrdude: verification error, first mismatch at byte 0x10f50
         0x31 != 0xdf
avrdude: verification error; content mismatch

----------


## sniffle

That isnt the compiler it is to verify what you jsut compiled, that isnt something that i can fix or find out about.  I compiled it no problem after changing the values

and EvdZ is one of the primary developers of Marlin right now, and obviously works for ultimaker as well

----------


## adamfilip

here is my current Config.h file
i will post a video of how the system is working right now
in a few min

Configuration.h

----------


## printbus

avrdude is the tool used to program the flash memory inside the MEGA2560 processor, so that's where something is going wrong.  Have you tried to upload from the Arduino IDE a second time?  Have you previously been able to upload OK?

----------


## adamfilip

right now there is a large space between the hotend and the bed, after it completes the ABL

----------


## adamfilip

> avrdude is the tool used to program the flash memory inside the MEGA2560 processor, so that's where something is going wrong.  Have you tried to upload from the Arduino IDE a second time?  Have you previously been able to upload OK?


i have done it many times just fine, but just recently its been giving me these errors, every time now.

----------


## sniffle

there will be a space between the hot end and the bed if you are running G29 stand alone.  Try doing a calibration cube or something small with G29 added to the custom G-code after the G28 and see if it prints properly.

That's odd that your having trouble with it flashing the memory, Just to cover all of your bases be sure to use the short USB cable provided by Colin, because interefence can be had with longer cables,  If that doesnt help there is a chance that there could be an issue with the flash.  If that's the case contacting Colin for a replacement board will be your only option just test extensively

----------


## adamfilip

i did restart Arduino and it uploaded fine
I do have a long usb cord, but i need it to reach my desktop machine

here is the video

https://www.youtube.com/watch?v=ld9Cl6ysiLA

----------


## adamfilip

so now how to i expand the probing area to cover most of my bed

----------


## sniffle

Ok, so when you setup ABL, it doesnt home like it traditionally would when using a regular Z endstop, obviously.  

ABL is meant to be used in conjunction with G28, as you have setup.

on slic3r, cura, and kisslicer, sorry no experience with simplify3d, there is an area for custom start and end G-code i would expect simplify3d would as well.  You print something quick like a single wall cube, and add G29 just after the G28 in the startup G-code.  So that after heating the printer will home then auto level, after auto leveling it should go to the start position drop down to the bed and begin printing.  At least that's what mine does.

I wish i was at home to take a video and show you mine as well, but sadly i'm at work...


Oh and i'm a little jealous of your cold end... The color i got was brown...

----------


## sniffle

> so now how to i expand the probing area to cover most of my bed



Configuration.h 

Lines 380-384

That defines the area to probe in.

----------


## adamfilip

Video of first test print
https://www.youtube.com/watch?v=BqXocqHU7qY

----------


## sniffle

Has anyone thought about setting up a makerfarm chat somewhere like IRC?  not that many people would be there all the time or anything... just a thought

----------


## adamfilip

i think it would be great, if that was available

----------


## sniffle

> Video of first test print
> https://www.youtube.com/watch?v=BqXocqHU7qY



very nice, Where did you get your glass?  I'm using the 2ml 3$ a sheet glass from lowes, and i have a LOT more clips on mine than you do mainly to hold the heater to the glass more securely so that it will heat up more evenly

----------


## adamfilip

I got the glass here

http://www.mcmaster.com/#8476k23/=vicokw

I ended up cutting the corners with a dremel with diamond saw blade, worked great
its very stiff/flat, takes some time for the heat to sink in.

I noticed that since the probe is offset from the hotend it can only probe a portion of the glass

i got the 1/4"

----------


## sniffle

Yeah I have mine set to 0 and 250 i believe, as close to the clips as i can get, I also have my endstops adjusted so that 0,0 is just inside the clips.

----------


## adamfilip

Stupid question: So now, i adjust the gap between the glass and the head
I assume in the slicer, and only in the slicer?

so if i set first layer heigth to .2mm it should be .2mm??

Thank you so much for all your help, I really do appreciate it

----------


## printbus

FYI - Mini binder clips take up less of the glass and also don't stick up as high as the common small binder clips.

----------


## sniffle

I didn't look at the code close enough, the decimal points only needed to be removed from the X and Y offset points, you still need full accuracy on the Z offset, so add the decimal point back to the Z offset.  Also to make adjustments, as a general rule, the more negative you make the number the closer to the bed you are getting, the more positive it is the further away you are.  I have been getting my offset lately and then making it roughly .15 more negative jsut to get it closer to the bed.  That's jsut me though.

----------


## adamfilip

I noticed that when its doing the autolevelling

it seems to do the middle twice and doesnt do the back right at all.

----------


## adamfilip

tried another print..
hmmmm weird.. not great

.2mm layer
auto width
80% first layer height
110% first layer width

----------


## adamfilip

> I didn't look at the code close enough, the decimal points only needed to be removed from the X and Y offset points, you still need full accuracy on the Z offset, so add the decimal point back to the Z offset.  Also to make adjustments, as a general rule, the more negative you make the number the closer to the bed you are getting, the more positive it is the further away you are.  I have been getting my offset lately and then making it roughly .15 more negative jsut to get it closer to the bed.  That's jsut me though.


ok i will try that, thanks

----------


## adamfilip

hmm adding the decimal place seemed to make the hotend closer and it was worse. not sure what i should be adjusting at this point.

----------


## sniffle

> hmm adding the decimal place seemed to make the hotend closer and it was worse. not sure what i should be adjusting at this point.


 -10 to -10.4 is more negative and closer to the bed, try backing it off to -9.5  that's .9 further above the bed than -10.4

----------


## adamfilip

Thats what I ended up doing.. thanks!

----------


## sniffle

no problem, i actually had work to do at work so my reply was slow

----------


## adamfilip

for anyone interested this is my current config.h file for my i3v 12" with RAMBO

Configuration.h

----------


## adamfilip

Thanks again, my success rate for printing, as increased dramatically. I love ABL lol!

----------


## sniffle

i'm the same as you :-)  and no problem.  I see us as a community and communities help each other

----------


## beerdart

Any fix for this? 


> I keep getting a Endstop hits Z, message when im trying to manually control z height, and its not hitting anything

----------


## sniffle

> Any fix for this?


you have to disable software min endstop

----------


## beerdart

Could you please be more specific? 


> you have to disable software min endstop

----------


## sniffle

I cant right now omw home so i cant give you a line number but if memmory serves the actual define is DISABLE_MIN_SOFTWARE_ENDSTOP false and it needs to be true

----------


## shook

> for anyone interested this is my current config.h file for my i3v 12" with RAMBO
> 
> Attachment 4450


I used your config file and it flashed it my printer. the only problem i'm having now is that when i try to command the servo from pronterface to move, it doesn't respond. the servo moves when i plug the printer in, so i know it works. can you post your pins.h file too plz? thanks

----------


## adamfilip

pins.hhere you go.

Use as your own risk  :Smile:

----------


## shook

> pins.hhere you go.
> 
> Use as your own risk


I figured out that i needed to have the power going to usb on the board in order to use the servo, but now my problem is when i hit Y home it just moves a tiny bit instead of homing, and when i keep clicking y home it eventually just crashes into the y endstop

my current probe offsets are: 
X_PROBE_OFFSET_FROM_EXTRUDER 0  #define Y_PROBE_OFFSET_FROM_EXTRUDER 8 
  #define Z_PROBE_OFFSET_FROM_EXTRUDER -9.85

any help?

----------


## sniffle

> I figured out that i needed to have the power going to usb on the board in order to use the servo, but now my problem is when i hit Y home it just moves a tiny bit instead of homing, and when i keep clicking y home it eventually just crashes into the y endstop
> 
> my current probe offsets are: 
> X_PROBE_OFFSET_FROM_EXTRUDER 0  #define Y_PROBE_OFFSET_FROM_EXTRUDER 8 
>   #define Z_PROBE_OFFSET_FROM_EXTRUDER -9.85
> 
> any help?


umm, your servo offsets shouldnt make a difference as to why your y bed is barely moving, if it crashes into the endstop but doesnt actually recognize that it hit the endstop then that means your endstop isnt making a circuit somewhere, wither a wire broke off the servo tab or it has come uplugged from the rambo board.

----------


## shook

> umm, your servo offsets shouldnt make a difference as to why your y bed is barely moving, if it crashes into the endstop but doesnt actually recognize that it hit the endstop then that means your endstop isnt making a circuit somewhere, wither a wire broke off the servo tab or it has come uplugged from the rambo board.


Homing all fixed the problem. The problem I'm having now though is when I enter my probe offsets it comes back with an error when i try to compile to lines 447 and 452, this part of the code:

 #ifdef AUTO_BED_LEVELING_GRID	// Check if Probe_Offset * Grid Points is greater than Probing Range
    #if X_PROBE_OFFSET_FROM_EXTRUDER < 0
      #if (-(X_PROBE_OFFSET_FROM_EXTRUDER * (AUTO_BED_LEVELING_GRID_POINTS-1)) >= (RIGHT_PROBE_BED_POSITION - LEFT_PROBE_BED_POSITION))
	     #error "The X axis probing range is not enough to fit all the points defined in AUTO_BED_LEVELING_GRID_POINTS"
	  #endif
	#else
      #if ((X_PROBE_OFFSET_FROM_EXTRUDER * (AUTO_BED_LEVELING_GRID_POINTS-1)) >= (RIGHT_PROBE_BED_POSITION - LEFT_PROBE_BED_POSITION))
	     #error "The X axis probing range is not enough to fit all the points defined in AUTO_BED_LEVELING_GRID_POINTS"
	  #endif
	#endif
    #if Y_PROBE_OFFSET_FROM_EXTRUDER < 0
      #if (-(Y_PROBE_OFFSET_FROM_EXTRUDER * (AUTO_BED_LEVELING_GRID_POINTS-1)) >= (BACK_PROBE_BED_POSITION - FRONT_PROBE_BED_POSITION))
	     #error "The Y axis probing range is not enough to fit all the points defined in AUTO_BED_LEVELING_GRID_POINTS"
	  #endif
	#else
      #if ((Y_PROBE_OFFSET_FROM_EXTRUDER * (AUTO_BED_LEVELING_GRID_POINTS-1)) >= (BACK_PROBE_BED_POSITION - FRONT_PROBE_BED_POSITION))
	     #error "The Y axis probing range is not enough to fit all the points defined in AUTO_BED_LEVELING_GRID_POINTS"
	  #endif
	#endif
*
I tried uncommenting it, which worked for compiling, but then would not let me control the servo through pronterface anymore....


*My probe offsets are:
#define X_PROBE_OFFSET_FROM_EXTRUDER 31.6
  #define Y_PROBE_OFFSET_FROM_EXTRUDER 4
  #define Z_PROBE_OFFSET_FROM_EXTRUDER -8.1

Please help, thanks.

----------


## sniffle

X and y offsets must be whole numbers which was discovered and posted i believe on page 4 or 5.

----------


## Roxy

> X and y offsets must be whole numbers which was discovered and posted i believe on page 4 or 5.


If you care...  With a simple change you can use fractional (with decimal point) numbers:

#if (( (double)X_PROBE_OFFSET_FROM_EXTRUDER * ((double)AUTO_BED_LEVELING_GRID_POINTS-1)) >= ((double)RIGHT_PROBE_BED_POSITION - (double)LEFT_PROBE_BED_POSITION))

That is more casts than needed, but it will eliminate the issue.

----------


## sniffle

You sure roxy?  I was getting a precompiler error for comparing two floats.  Making it a double would truncate it making it still a whole number?

----------


## adamfilip

Im running into a funny error.

If i do a print using ABL it prints fine.
and then after its done. i proceed to run another print using ABL
The head starts homing X & Y
but when its homing X it travels to the endstop and just stops, it doesnt tap it a second time
(Normally when its Homing the X will slide over and hit the Endstop twice)
then once Y hit. the head doesnt travel to the middle of the bed (as it normally would)
it stays at the X stop position. and starts the ABL routine with it hanging off the bed
at this point i have to manually trigger the Z endstops and cancel the job

when i manually move the head over away from the endstop and try again it homes and starts ABL fine.

----------


## sniffle

i use z safe homing so it hits x and y then moves to the center of the bed to home z... havent had an issue with it... not sure why your having issues

----------


## Roxy

> You sure roxy?  I was getting a precompiler error for comparing two floats.  Making it a double would truncate it making it still a whole number?


Well...  I didn't actually make the 'suggested changes' and compile it.   But if you have a number without a decimal point it is considered an integer.  By putting the (double) cast in front of it you do not truncate the integer.  You convert it to an equivalent double precision floating point number.   So, in the modified line, I forced the conversion of every number to (double) precision floating point so there would be no issues doing the comparison.

I don't actually know that the Arduino compiler tolerates floating point comparisons in the #if preprocessor statements.  

I messed up and got a cast in a 'less than proper' place:

#if (( (double)X_PROBE_OFFSET_FROM_EXTRUDER * (double)(AUTO_BED_LEVELING_GRID_POINTS-1)) >= ((double)RIGHT_PROBE_BED_POSITION - (double)LEFT_PROBE_BED_POSITION))

*UPDATE:*  It looks like the #if preprocessor directives in the Arduino Compiler are not tolerant of floating point comparisons.  That seems pretty bogus.  Obviously the compiler can handle floating point numbers and do floating point comparisons.  But for some reason the pre-processor says "I'm crippled and can only do integer comparisons."   What is this world coming to?  Oh well...   It can be worked around.

----------


## adamfilip

> i use z safe homing so it hits x and y then moves to the center of the bed to home z... havent had an issue with it... not sure why your having issues


I am also using Safe homing.

----------


## shook

> X and y offsets must be whole numbers which was discovered and posted i believe on page 4 or 5.


yes, sorry. i did read this whole thread several times, but in my tired state i didnt quite understand that. thanks  :Smile:

----------


## sniffle

> Well...  I didn't actually make the 'suggested changes' and compile it.   But if you have a number without a decimal point it is considered an integer.  By putting the (double) cast in front of it you do not truncate the integer.  You convert it to an equivalent double precision floating point number.   So, in the modified line, I forced the conversion of every number to (double) precision floating point so there would be no issues doing the comparison.
> 
> I don't actually know that the Arduino compiler tolerates floating point comparisons in the #if preprocessor statements.  
> 
> I messed up and got a cast in a 'less than proper' place:
> 
> #if (( (double)X_PROBE_OFFSET_FROM_EXTRUDER * (double)(AUTO_BED_LEVELING_GRID_POINTS-1)) >= ((double)RIGHT_PROBE_BED_POSITION - (double)LEFT_PROBE_BED_POSITION))
> 
> *UPDATE:*  It looks like the #if preprocessor directives in the Arduino Compiler are not tolerant of floating point comparisons.  That seems pretty bogus.  Obviously the compiler can handle floating point numbers and do floating point comparisons.  But for some reason the pre-processor says "I'm crippled and can only do integer comparisons."   What is this world coming to?  Oh well...   It can be worked around.


Thats what i was thinking i was actually trying to multiply it *100 and then cast to an int and even that was falling flat...

----------


## shook

i've got everything working with the auto bed leveling now, athough with the new version of marlin, my heated bed takes much longer to heat up, anyone know a fix for this?

----------


## Roxy

> i've got everything working with the auto bed leveling now, athough with the new version of marlin, my heated bed takes much longer to heat up, anyone know a fix for this?


Ah...  Your PID control algorithm is set very passively? You need to change the values used for P, I, & D.

----------


## shook

> Ah...  Your PID control algorithm is set very passively? You need to change the values used for P, I, & D.


thats what i thought at first too, but i have the same ones as the original makerfarm marlin firmware, someone else was suggesting it has to do with the thermistor tables, but it doesn't seem wise to copy over the thermistortable file from the makerfarm marlin since the new one has over 4000 more lines of code in it. 


I believe these are the values you are referring to:

    #define  DEFAULT_bedKp 402.00
    #define  DEFAULT_bedKi 78.92
    #define  DEFAULT_bedKd 511.90

----------


## printbus

> thats what i thought at first too, but i have the same ones as the original makerfarm marlin firmware, someone else was suggesting it has to do with the thermistor tables, but it doesn't seem wise to copy over the thermistortable file from the makerfarm marlin since the new one has over 4000 more lines of code in it.


What values do you have in configuration.h for TEMP_SENSOR_0 and TEMP_SENSOR_BED?  If they are 6, change them to 1 and you can ignore the concern about what is in the thermistortables.h file for the Type 6 thermistor.

----------


## shook

> What values do you have in configuration.h for TEMP_SENSOR_0 and TEMP_SENSOR_BED?  If they are 6, change them to 1 and you can ignore the concern about what is in the thermistortables.h file for the Type 6 thermistor.


#define TEMP_SENSOR_0 1
#define TEMP_SENSOR_1 0
#define TEMP_SENSOR_2 0
#define TEMP_SENSOR_BED 1
This is what it's currently at

----------


## printbus

> #define TEMP_SENSOR_0 1
> #define TEMP_SENSOR_1 0
> #define TEMP_SENSOR_2 0
> #define TEMP_SENSOR_BED 1
> This is what it's currently at


Well, then you at least shouldn't be battling the problem we used to have with MakerFarm's manipulation of Type 6 thermistor table data leading to problems when that table was replaced in a firmware upgrade.  

I'll have to try and find some older posts. We've been through thisrecently. I just don't remember the cause being something that was different in the firmware upgrade. 

FOLLOWUP COMMENT: Came up short in looking for prior posts to reference.  One thread did remind us how a slight change in room temperature or any drafts can mean a significant difference in the bed's ability to reach a high temperature.  

Easy stuff to check: make sure all screw terminals in the heat bed wiring path are tight; the stranded wires have a tendency to shift over time and loosen up.  Loose connections lead to high resistance, causing reduction of power applied to the heat bed and melted screw terminals.  If you can see between the heat bed and your insulation material, try to make sure the heat bed thermistor is still snug to the heat bed; if it separates at all it could start to read low/slow.  Ideally, the insulation material should not press up against the insulation - depending on the insulation material, that could draw heat out of the thermistor and cause it to read low.  

Another possibility is that through a difference in bed leveling or a difference in where the clips are placed around the glass, you've shifted where the heat bed does & doesn't actually touch the glass.  If there's even a slight bit of a gap between the thermistor area of the bed and the glass, that localized area (of the actual heat bed, not the glass) will heat up faster than if the heat bed in that area is pressing up against the glass.

----------


## adamfilip

running into weird glitches during the abl routine
sometimes it will decide to forget to move X between probings. other times its fine.
i dont get it.

----------


## shook

> running into weird glitches during the abl routine
> sometimes it will decide to forget to move X between probings. other times its fine.
> i dont get it.


ya im having a terrible time with my abl too, ive changed 3 servos now, shit is so unreliable

----------


## shook

hey adam, how did you mount your servo on the inside of the xcarriage with the arm going out? did you change your fan shroud?

----------


## sniffle

Its odd to me you guys are having such a hard time with abl.  It makes me wonder what your doing differently...

I havent had an issue with my abl servo since the twiching broke the internal gears and i replaced it rerouting the wires away from the extruder motor when i did so.  Havent had a twitch since.  I also havent had any issues with the servo hitting the bed when extending but i think my raise before homing keeps that from happening.

----------


## TopJimmyCooks

In my experience the cheapest 9G servos by TowerPro fail quickly if they hit the bed at a bad angle one or two time, which happens to everybody sooner or later.  They are also twitchy and make small moves that weren't requested by ramps.  I may have had a bad batch of examples because others have used them successfully. I had problems with literally 3 towerpro's before switching to a hexatronics for $2 more.  

I also rearranged the wires for the servo to get them to the other side of the bundle from the extruder motor wires, not sure if that contributed to the fix or not but I was paranoid about some type of induction messing with things.

----------


## walkercreations

I am late coming to all of this and hope there are some folks still around this thread. I am just starting to wrap my head around the whole Auto Bed Leveling thing and understand how and where the servo plugs into the Rambo. I'm not sure where the Probe plugs in though. Does it take the place of the Z-Endstop or plug in somewhere else on the board?

----------


## Roxy

> I'm not sure where the Probe plugs in though. Does it take the place of the Z-Endstop or plug in somewhere else on the board?


There are a couple of options.  But typically, in most cases, people connect the switch for the Z_Probe to where the Z-Endstop used to be.   If you do this, the Z-Endstop can just be left where ever it is on the printer just in case you want to back up to the way it used to be.  The firmware will use the Servo to engage the Z_Probe and use the switch mounted on the probe leg instead of using the Z-Endstop.

----------


## walkercreations

Thank you very much. One other question, since I will be using a fresh version of Marlin Firmware and not the one supplied by Colin at MakerFarm, will the only files I need to modify the Configuration.h and Pins.h?

----------


## Roxy

> Thank you very much. One other question, since I will be using a fresh version of Marlin Firmware and not the one supplied by Colin at MakerFarm, will the only files I need to modify the Configuration.h and Pins.h?


Pretty much...  Yes, those are the only files you will have to modify.   And you may not even need to touch Pins.h but I don't know the answer to that off the top of my head.   The biggest reason you would have to mess with Pins.h is to make it agree with where ever you connect the servo to the electronics.

----------


## walkercreations

Thanks again Roxy. I plan on plugging my Servo into MX1 and from the manual for my board it would be PWM pin PA0. Not sure if that info has been put into Configuration.h or not. I'm at work so can't check it. I do know from the OP that it is or was in Pins.h

----------


## sniffle

You only have to edit pins_Rambo.h if you plan to use a servo other than on mx1 or to change the fan pins around.  I committed it to the main trunk that way.

----------


## walkercreations

So instead of Pins.h the info I need to change is in pins_Rambo.h? When I get home this afternoon I will take a look and see if it is included in the firmware I downloaded. I don't recall seeing that file. And thanks for the help. It is greatly appreciated.

----------


## sniffle

Depending on where and when you downloaded the firmware depends on if it is pins.h or pins_Rambo.h in the last couple months they broke all of the individual boards into there own pin files.  

If its still only pins.h you will need to check and make sure that it has the code for the servos mentioned in the first post in the Rambo section.  If you are getting the firmware directly from the marlin firmware github and it is fairly recent then what I said will hold true.

I really need to update this post when I have time... Which I never have :-P I'm starting to try and get the neurosurgeons at the hospital I work at to try 3d printing for preoperative planning :-D

----------


## walkercreations

I saw a thing on YouTube recently where they are 3D Printing Human Organs. Pretty amazing stuff. Kinda makes the little bits and bobs I have been putting out look like childs toys. I did download the firmware from the Marlin Github Repository but only took an early look at the Configuration.h file. I have ordered all of the electronics pieces and am just waiting on them to arrive to implement ABL.

----------


## printbus

> ...since I will be using a fresh version of Marlin Firmware and not the one supplied by Colin at MakerFarm, will the only files I need to modify the Configuration.h and Pins.h?


Clarification - if the MakerFarm configuration.h file you have been using defines any of the TEMP_SENSOR_x entries as value 6, do yourself a favor and change those to value of 1 for use with the new Marlin firmware.  Just do it, but here's the explanation - Comparison of Type 1 and Type 6 thermistortables.h data

----------


## walkercreations

The Configuration.h I am currently using from MakerFarm is using Thermistor Type 1 for Extruder and Heat Bed. Also I noticed that in the MakerFarm version Colin has stuff in there to define Delta Kinematics and the default Marlin has it as an option. I'm not sure if it is necessary or required, but when I do edit the new version of Marlin I will include it just in case to avoid possible problems. I'm sure Colin had a reason for adding it, I'm just knowledgeable enough at this point to know. Of course, having it in there could cause problems as well, but I think the likelihood is less.

I am finally home from work and the firmware I downloaded does have pins_RAMBO.h. Looking at the file, I see that in the first part of Servo support the arguments:

#define SERVO0_PIN       22 //motor header MX1
  #if NUM_SERVOS > 1

define the pin I will be plugging my servo into. What will I need to change there? The PWM that corresponds to that pin as I understand it is PA0. Do I change the number 22 to PA0 or do I even need to change anything in that file?

----------


## sniffle

If you plan to use mx1 you don't need to change anything... And the delta kinematica aren't needed

----------


## voodoo28

How reliable is ABL now?

----------


## sniffle

How big are you printing?  Right now it seems small prints are fine but larger prints seem to be off a little

----------


## voodoo28

My prints vary in size. Are you refering to tall or large on the platform?

----------


## sniffle

> My prints vary in size. Are you refering to tall or large on the platform?



large in the x y direction, edges seem to be more of an issue compared tyo teh outer edxges.

----------


## walkercreations

I was trying to compile the configuration.h file tonight in preparation for Auto Bed Leveling and I get the following errors when compiling. I know nothing about this stuff so I am hoping someone who does know something about it can help me out. Below is the output:



```
Arduino: 1.6.1 (Windows XP), Board: "Arduino Mega or Mega 2560, ATmega2560 (Mega 2560)"

Marlin_main.cpp:958:7: error: 'X_MAX_LENGTH' was not declared in this scope

     { X_##CONFIG, Y_##CONFIG, Z_##CONFIG };     \

       ^

Marlin_main.cpp:965:1: note: in expansion of macro 'XYZ_CONSTS_FROM_CONFIG'

 XYZ_CONSTS_FROM_CONFIG(float, max_length,      MAX_LENGTH);

 ^

Marlin_main.cpp:958:19: error: 'Y_MAX_LENGTH' was not declared in this scope

     { X_##CONFIG, Y_##CONFIG, Z_##CONFIG };     \

                   ^

Marlin_main.cpp:965:1: note: in expansion of macro 'XYZ_CONSTS_FROM_CONFIG'

 XYZ_CONSTS_FROM_CONFIG(float, max_length,      MAX_LENGTH);

 ^

Marlin_main.cpp:958:31: error: 'Z_MAX_LENGTH' was not declared in this scope

     { X_##CONFIG, Y_##CONFIG, Z_##CONFIG };     \

                               ^

Marlin_main.cpp:965:1: note: in expansion of macro 'XYZ_CONSTS_FROM_CONFIG'

 XYZ_CONSTS_FROM_CONFIG(float, max_length,      MAX_LENGTH);

 ^

In file included from Marlin.h:30:0,

                 from Marlin_main.cpp:30:

Marlin_main.cpp: In function 'void gcode_G28()':

Configuration.h:486:36: error: 'X_MAX_LENGTH' was not declared in this scope

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

                                    ^

C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:88:24: note: in definition of macro 'round'

 #define round(x)     ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))

                        ^

Marlin_main.cpp:1892:39: note: in expansion of macro 'Z_SAFE_HOMING_X_POINT'

           destination[X_AXIS] = round(Z_SAFE_HOMING_X_POINT - X_PROBE_OFFSET_FROM_EXTRUDER);

                                       ^

Configuration.h:487:36: error: 'Y_MAX_LENGTH' was not declared in this scope

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

                                    ^

C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:88:24: note: in definition of macro 'round'

 #define round(x)     ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))

                        ^

Marlin_main.cpp:1893:39: note: in expansion of macro 'Z_SAFE_HOMING_Y_POINT'

           destination[Y_AXIS] = round(Z_SAFE_HOMING_Y_POINT - Y_PROBE_OFFSET_FROM_EXTRUDER);

                                       ^

Marlin_main.cpp: In function 'void gcode_M48()':

Marlin_main.cpp:2943:51: error: 'X_MAX_LENGTH' was not declared in this scope

         radius = (unsigned long)millis() % (long)(X_MAX_LENGTH / 4);      // limit how far out to go

                                                   ^

Error compiling.

  This report would have more information with
  "Show verbose output during compilation"
  enabled in File > Preferences.

I have attached my Configuration.h file if someone could take a look at it and see if maybe I missed something. Thanks
```

Configuration.zip

----------


## sniffle

> I was trying to compile the configuration.h file tonight in preparation for Auto Bed Leveling and I get the following errors when compiling. I know nothing about this stuff so I am hoping someone who does know something about it can help me out. Below is the output:
> 
> 
> 
> ```
> Arduino: 1.6.1 (Windows XP), Board: "Arduino Mega or Mega 2560, ATmega2560 (Mega 2560)"
> 
> Marlin_main.cpp:958:7: error: 'X_MAX_LENGTH' was not declared in this scope
> 
> ...



get arduino 1.06 and see if that fixes the issue.  I don't think 1.6 is supported right now.  you'll also want to compile for the Rambo board not the arduino mega.  

In the reprapelectro user manual they explain how to setup arduino so that it will give the option for a rambo board instead of just the base mega

----------


## walkercreations

Thanks sniffle. I will give that a try. I just got to work so it will be later this afternoon before I can try it but will let you all know if that fixes it.

Update:

I was able to use a laptop at work to compile it and it does work with Arduino 1.0.6 without any errors. Many thanks sniffle for that bit of info.

I have one last question before moving on to the last part of implementing Auto Bed Leveling. I have installed the hardware, flashed the firmware, and have done preliminary tests to make sure that it is all working as expected. I can extend and retract the probe. Something I have noticed is that when I Extend the probe I get no warning or anything on the lcd. When I Retract the probe, I noticed that I get a message on the lcd of something like "endstop hit z" I was wondering if that is normal prior to moving on to the next step or do I need to change something in the firmware prior? When that error is showing on the lcd, i can not move the printer until I reset it.

----------


## walkercreations

Update:

I have spent the last 2 hours trying to get this setup and working. I go through the steps per Zennmaster's 3rd video and get my offsets. I enter them into the Configuration.h and when I try to upload it to my printer I get the following error:



```
  This report would have more information with
  "Show verbose output during compilation"
  enabled in File > Preferences.
Arduino: 1.0.6 (Windows NT (unknown)), Board: "RAMBo"
In file included from /Configuration_adv.h:502,
                 from /Configuration.h:733,
                 from /Marlin.h:22,
                 from BlinkM.cpp:5:
/SanityCheck.h:106:37: error: floating constant in preprocessor expression
/SanityCheck.h:106:37: error: floating constant in preprocessor expression
/SanityCheck.h:108:40: error: floating constant in preprocessor expression
/SanityCheck.h:108:40: error: floating constant in preprocessor expression
/SanityCheck.h:110:40: error: floating constant in preprocessor expression
/SanityCheck.h:110:40: error: floating constant in preprocessor expression
/SanityCheck.h:112:39: error: floating constant in preprocessor expression
/SanityCheck.h:112:39: error: floating constant in preprocessor expression
/SanityCheck.h:120:11: error: floating constant in preprocessor expression
/SanityCheck.h:124:13: error: floating constant in preprocessor expression
/SanityCheck.h:130:11: error: floating constant in preprocessor expression
/SanityCheck.h:134:13: error: floating constant in preprocessor expression
```

Any ideas on what I may be doing wrong?

----------


## Schnupp

Can you post your configuration.h so we can take a look at it?

----------


## walkercreations

Below is what I am trying to flash:

Configuration.h

----------


## Roxy

The error being flagged is in SanityCheck.h   We need to see that file too.

----------


## Schnupp

In the auto bed leveling section try removing the decimals of  #define X_PROBE_OFFSET_FROM_EXTRUDER 30.00  and  #define Y_PROBE_OFFSET_FROM_EXTRUDER 9.90 so that they are 30 and 10

----------


## sniffle

X and y probe offsets must be whole numbers z offset is the only one allowed to have high accuracy

----------


## TechMasterJoe

> X and y probe offsets must be whole numbers z offset is the only one allowed to have high accuracy


while true the firmware will use decimal values without error only the math in sanitycheck.h req integers

warning
for the advanced users
commenting out the check routine will bypass the problem BUT
make 100% sure that probe zone + offset will not crash the machine that includes hitting clips holding the glass or what not
for me all my probes are done 50mm from the edge of bed as my largest offset is 43mm (ya a lot i know working on another method using a steel pin and inductive sensor)

i'm only saying this because some people might have very sharp points on the tip of the probe they are using and precession never kilohertz lol
but you might run in to an odd error at random where is freezes on the last probe point this is a rounding problem that locks up the math loop that corrects the bed plane
 in turn never returns with "ok" so it never moves reconnecting or resetting will free it while annoying it has only happen twice for me this month so apx 1:50~60 prints
this is error happens from time to time even with use of integers but no where near as offen 

99.9% of marlin users just use integers.

----------


## walkercreations

Thanks everyone for the replies. It is very much appreciated. I'm at work on an overtime day so will have to try the whole numbers bit this afternoon. If that doesn't work, I will upload my SanityCheck.h to see if that is any help.

----------


## sniffle

I ran into this trouble as well... it will fix it :-)

----------


## walkercreations

The whole numbers thing did work. Now I don't understand how this is supposed to work. When setting it up, I told the Rambo the Zero point was where I made the mark on my Heated Bed. I made the mark near the center of my Bed and followed the procedure like Michael's video's instructed. After I did all that I home all the axis. The X and Y Axis go to their End Stop positions and the Extruder goes to the Back Right Corner where the original Home Position was before installing Bed Leveling. I enter G29 to go into the Bed Leveling Routine and the Probe only comes down at the Home Position and that's it. In Pronterface it tells me the Auto Bed Leveling has been done and gives me some coordinates. I get a message on my LCD saying "endstops hit: Z" and that is it. It is supposed to do the Grid pattern as I have it set it up. Any ideas what I may have missed or done wrong? I homed everything and did another G92 X0 Y0 Z0 and still no luck. I'm at a loss.

Any help or information is greatly appreciated.

----------


## voodoo28

I think my printer has become possessed...!!

ABL was working perfectly 2 days ago...i turn it on today for the first time since and..the G28 and G29 commands make the z carriage move up instead of towards the bed..BUT...if i press the negative Z in Simplify3D controller it moves in the correct direction. So ,that means the wires are not inverted nor is the direction of the steppers in Marlin. Ive reloaded Marlin several times from a fresh download and NADA!

What can it be???


Sorry for the double post it the Itty Bitty Flex  Thread..

----------


## sniffle

> I think my printer has become possessed...!!
> 
> ABL was working perfectly 2 days ago...i turn it on today for the first time since and..the G28 and G29 commands make the z carriage move up instead of towards the bed..BUT...if i press the negative Z in Simplify3D controller it moves in the correct direction. So ,that means the wires are not inverted nor is the direction of the steppers in Marlin. Ive reloaded Marlin several times from a fresh download and NADA!
> 
> What can it be???
> 
> 
> Sorry for the double post it the Itty Bitty Flex  Thread..


doublecheck that a z endtop wire isnt broken

----------


## rhonal89

@sniffle I see what you did there.  :Cool:  check those wires and see if they are broken @voodoo28.

----------


## voodoo28

It was a broken wire...   :Wink: 


> doublecheck that a z endtop wire isnt broken

----------

