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.
Printable View
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.
Thats what I ended up doing.. thanks!
no problem, i actually had work to do at work so my reply was slow
for anyone interested this is my current config.h file for my i3v 12" with RAMBO
Attachment 4450
Thanks again, my success rate for printing, as increased dramatically. I love ABL lol!
i'm the same as you :-) and no problem. I see us as a community and communities help each other
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
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
Attachment 4483here 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?
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.
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.
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?
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.
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
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.
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?
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
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.
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.
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?
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.
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.
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?
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.
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.