Rambo Servo Setup for Auto Bed Leveling for Noobs

[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

[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