Auto Level - Auto Calibration Talk

[johnoly99]

Here's a thread started to keep track on all the related information about auto calibration/auto leveling your Rostock MAX or other delta 3D printer

[edward]

So, you think you want/need "auto-level?"

Well, the truth is, in any current form (as of 2013/10/30), what you think is "auto-level" probably isn't going to help fix your Delta machine. Most likely leveling is not what you're after. Let's start with some definitions. This list assumes a basic understanding of the fundamental Delta terms, such as delta or printer radius, diagonal rod (length), build surface, etc.

Definitions

• (End-) Effector: The device or component located at point of final intended movement of a machine or mechanism that interacts with the environment, i.e., the print-head or nozzle.
• Delta (Printer) Calibration: The iterative tuning process whereby setting the origin location for each of the principle motion axes, in combination with modifying the PRINTER/DELTA_RADIUS parameter in the printer controller's firmware, flat movement of the end-effector over the build surface is achieved. The most common method for setting each axis' origin is through adjustment of an end-stop or limit switch, or by adjusting a movable machine element that contacts the end-stop or limit switch, often a screw. There are firmwares available that offer software adjustment of the origin position. Changing the PRINTER/DELTA_RADIUS parameter in the firmware affects the conversion of the linear motion of the effector to the non-linear movement of each axis. The effects of an incorrectly calibrated radius are manifested through a convex or concave motion of the effector (when it should be flat). This process is commonly referred to as a 4-point calibration, derived from the four points used to check machine movement. Three points, one at the base of each axis (tower), and a single point in the very center of the build area. When the machine can repeatably move to exactly the same measured height above the build surface at each of those four points, all of which are commanded to the same Z position, the machine should [1] be calibrated. Flat is the key term here. This calibration process is often referred to as "printer leveling," and while arguably a correct use of the word, this phrase seems as though it might be the source of some confusion when referred to in the context of z-probes. As such, I propose that the community standardize on "printer calibration" instead of "printer leveling."
• Z-probe: In a generic sense, it is a limit switch attached to the end-effector of a machine-tool that can be used to automatically index the surface of a part or work area. Specifically related to a Delta style 3D printer, the Z-probe is often a mechanical micro-switch, just like the Rostock MAX's end-stops, or a non-contact Hall-effect sensor that is often sold as an end-stop. It can be permanently fixed to the end-effector, in which case it must be manually or automatically "deployed" before use, or user-removable. The micro-switch can be used to directly touch the surface of the probed body or it can be integrated into a mechanism that uses an additional tool or item to physically touch, as in the case of a Hall-effect probe. Essentially, a Z-probe is nothing more than a minimum limit switch for the Cartesian Z-axis of movement.
• Auto-Calibration, or Auto-Radius: An automatic method of performing a printer calibration through the use of a controller-accessible measurement device, such as a Z-probe. A functioning auto-calibration or auto-radius (as in PRINTER/DELTA_RADIUS) routine would be able to use an installed z-probe or other device to measure the movement of the end-effector and determine the corresponding physical parameters that describe the motion. These parameters include the location of each axis' origin, the PRINTER/DELTA_RADIUS, and possibly others.
• Auto-Level, or Surface-Mapping: A method of determining the contour of a surface, also called constructing a surface map, to be used in automatically compensating the motion of the end-effector of a machine, such that an intended flat motion follows the contour of the possibly non-flat surface. For 3D printers, auto-leveling the print surface will produce near-perfect first layer width, resulting in vastly improved and uniform adhesion.

Current State-of-the-Art, as of 2013/12/08

THERE IS NO KNOWN-WORKING AUTO-CALIBRATION ROUTINE AVAILABLE IN ANY FIRMWARE.

Read that last sentence again. That was likely the beef you were looking for, as most people (including myself, several months ago) hear the term "auto-level" and rightfully rejoice. There are only a select few that have been able to, or are capable of, constructing a machine and within only a few calibration iterations can have the perfectly flat motion over the entire build surface that we all so desire. Actually, forget even those edge-cases. Just try to move your machine from one room, even one table, to the next. My bet is that you will have calibration issues. How nice it would be to hit a button and have the machine re-tune itself.

There are currently at least two in-development firmwares that are attempting to implement auto-calibration, for which I have not seen any reports of success. One is the 0.90 development version of Repetier-Firmware and the other that I know of is a custom Marlin version by ScribbleJ. There are likely others of which I am not aware.

User 626Pilot has provided well-documented experimentation with the Repetier 0.90 development branch's auto-calibration in this post: http://forum.seemecnc.com/viewtopic.php ... =20#p21833 Still, there are mixed results.

THERE IS AN IMPLEMENTED, AND WORKING [2], AUTO-LEVEL ROUTINE AVAILABLE IN A SPECIFIC BRANCH OF THE MARLIN FIRMWARE.

Auto-Level is currently implemented via the G29 command in Johann Rocholl's deltabot branch of the Marlin firmware (go here: https://github.com/jcrocholl/Marlin and choose the deltabot branch). Johann called his routine (correctly) auto-leveling, and while I have not read it myself, I have seen others state that he mentioned it should correct for doming (concave or convex effector motion due to an improperly calibrated DELTA_RADIUS), and this likely became the initial source of confusion regarding the automatic capabilities afforded by a Z-probe.

Here is why: It is crucial that the parameters in the firmware governing the calculated motion of the printer match exactly the physical characteristics of the machine. If not, where the printer controller "thinks" the end-effector is located when it is commanded to a point WILL NOT match the actual, physical location. This description exactly defines a calibrated printer. There is no way to get flat, linear, movement otherwise. So while it may seem that a simple adjustment of the Z-motion, via automatically-probed points, could correct doming problems, if the printer can't move in exactly a straight line between two points, then how will any algorithm know how much Z adjustment to make?

Using G29 auto-level, Marlin deltabot edition

When using the auto-level G29 code it must be run before every print job. It does not store the surface map anywhere but in RAM, i.e., no persistent storage in EEPROM. Also, while I can't specifically identify the behavior in the code, I recall the map being reset or over-ridden if I executed a G28 after running G29. I'll need to confirm, but until then, I'd recommend not homing after leveling.

The recommended usage is to insert it into your slicer's start-code, such as this:

Code: Select all

G28 ; home all axes
G1 Z15 F6000 ; prepare for auto-level
G29; call the auto-level probing routine
G1 Z12 F6000 ; lift nozzle
G1 X0 Y0 F6000 ; re-center the machine

The code and exact Z-height in the second line will vary depending on your exact implementation of the probe. The probing routine will move at most -20 mm to find the surface, so whatever value you use, be sure that the probing starts with the probe tip within approximately 20 mm of the build plate.

G-code confusion

There is a list of dozens of supposedly standardized G-codes for RepRap controllers that can be found here: http://reprap.org/wiki/G-code. As with several other commands, and as the auto-* routines for Deltas are quite new, these have not been added to the list. As such, the G29 routine found in the Marlin deltabot firmware executes a different set of operations than the G29 routine in the Repetier firmware. The specifics of which code to be called for each firmware will need to be investigated by the user, so it would be best to assume that G-code generated with auto-* codes, generated for one firmware, is NOT portable to another firmware.

What all of this means for you and your non-working printer.

If you can't print over (nearly) the entire build surface, YOUR PRINTER NEEDS TO BE CALIBRATED, AND NO MAGICAL Z-PROBE IS GOING TO HELP YOU (FOR NOW).

Anyway, you are almost certainly looking for AUTO-CALIBRATION, so STOP SAYING YOU WANT AUTO-LEVEL!

Maybe that's not what you were wanting to hear, but that's really the answer. Sorry. I went through all of this Z-probe learning process so that you don't have to. I made the mistake of thinking everything would be magically corrected for me. In the end, I had to track down some tiny errors in my tower positions to fully calibrate my machine. Now I don't need the probe, but I use it to auto-level because it is present.

There are certainly firmware developers working on this problem as without it the Delta platform is going to struggle. Whether it is just to ease the setup for new or inexperienced users or to quickly aid in re-calibration after transporting a machine, everyone has a reason why they want some auto-magic in their Delta firmware. If you are a capable coder or knowledgeable firmware tester, I suggest that you fabricate yourself a Z-probe and test the available offerings that currently attempt to use the new device. Provide feedback to the developers of the firmwares you are testing and discuss your results here or elsewhere.

Due to the very experimental nature of the Z-probe's capabilities in any firmware, you are not likely to find much help using one. If you have the time and desire to experiment, your feedback and results will greatly help the community.

[1] There are some conditions where the 4-point calibration will "test positive" yet still yield domed motion in certain locations of the build area. If this is happening on your machine, it likely indicates a larger issue with your geometry. Check tower squareness, tower equi-distance, parallelism of the arms, etc. Ask nicely in the forums and you will find help.
[2] The "working" nature of the Marlin auto-level routine has not been universally observed. The reason for resulting "bad" motion on a well calibrated machine is not yet known.

(Last edited 2013/12/09 12:53 EST: Corrected some typos and added link to 626Pilot's Repetier experimentation results.)

[edward]

Please, anyone correct me if I have stated something you find to be clearly wrong. I will do my best to keep the above post up-to-date with relevant information.

Also consider sending me PMs with corrections and keeping the thread for discussion on those changes. PMs will be easier for me to see rather than combing through what could become a lengthy topic.

Thanks!

[geneb]

\o/

g.

[626Pilot]

I'm gonna assume it's worth checking Johann's branch for myself, in order to fully exclude it from the "could work" list. Repetier is definitely on the "doesn't work" list and the guy who develops it hasn't shown interest in fixing it since the bug was reported. I don't know whether it's because I have one arm infinitesimally longer or shorter than its twin, or one of my towers isn't exactly 60 degrees from its neighbors, but I can never do the same printer radius calibration on two towers. My towers were clamped to a metal drafting square and mechanically pulled towards each other and tight up against the grooves before being tightened down, and the height was verified to be the same on all three. I've done everything I know to do with the physical machine. At this point the only solutions I know to try are mathematically moving one of the towers to a different rotation in the firmware, and using auto bed leveling or tower leveling or auto radiusing or whatever you want to call it. So, I'll try both. If they both work, I bet the auto leveling method is going to be easier.

I have Johann's deltabot branch checked out. There is a problem with the X axis pulsing once per second in the most recent move direction. If you have any idea what that might be, let me know.

[edward]

Just remember, Johann coded an auto-level routine as defined above. It is my (very rough) understanding that geometry errors can either manifest themselves in the Cartesian X/Y, the Cartesian Z, or a combination of all three. If you are lucky enough to have an error than only shows in the Z, then the bed auto-leveling might work for you.

Repetier is definitely on the "doesn't work" list and the guy who develops it hasn't shown interest in fixing it since the bug was reported.

Yeah, Roland seems to be a nice guy, but he really wants things done his way. That's fine, it's just that it can make it harder for contributers to fix things without forking the code.

With that said, I would give him a bit of a break on this one. The auto-calibration routine seems to be much more difficult to program into a controller than one might think.

[626Pilot]

Hey, get ready to edit your post. It works

How:
You need a Z-probe, like this one. Then, you need to check out the deltabot repo:

Code: Select all

git clone https://github.com/jcrocholl/Marlin.git --branch deltabot

Put this in Configuration.h: http://pastebin.com/J1NtR72y
Put this in Configuration_adv.h: http://pastebin.com/dSL6AqT7

In Configuration.h:

• Find DELTA_SMOOTH_ROD_OFFSET and set it to your PRINTER_RADIUS.
• Find MANUAL_Z_HOME_POS and set it to your print height. This HAS to be right. Weird, huh? As long as it is, everything else will be OK.
• Set up Z_PROBE_OFFSET according to instructions here.

After the firmware is burned, run the m119 test on all of your endstops AND your Z probe to make sure they're all in order. Send G28 and make sure it tests the endstops correctly. Then, try moving it down to z=300 and have it move from the center out to the edge to make sure it's not severely lensing. It shouldn't, but if it is, you have to fix that before you continue.

Finally, deploy the Z probe, run G28, and then G29. Keep your mouse over the Emergency Stop button in case it head crashes or something.

When that's done, hit the Reset switch. (If you don't, it will move incorrectly. Dunno why.) As long as EEPROM is enabled, it should save the autolevel information. Now, jog the print head down to 1 millimeter and try moving it across the bed in small increments (1 or 10mm at a time.) You should be able to move it to any position without the elevation changing.

[edward]

So you're confirming that the Marlin(deltabot) G29 auto-level has eliminated doming? Or are you just stating that the command functions?

Also, I'm pretty sure nothing gets updated to EEPROM when running the G29 command, though I haven't looked at that specific portion of the code for a while. It is my understanding that you will need to run the G29 command before every print job.

[cope413]

If you really want to test whether or not your machine is level and there is no doming, you should use a machinist's parallel or 2 (with no greater than .00002in/in variance), and trace your hotend along that. No cheating and keeping your finger on the on/off switch either. Just set the gcode and let it go.

I got the parallels... not sure if I have the balls (or the calibration) to do it yet

[lordbinky]

I know I wouldn't have it in me to drag a metal nozzle across a machinist's parallel. Then again I don't think I need to worry about ever acquiring one I could do that to.

[626Pilot]

So you're confirming that the Marlin(deltabot) G29 auto-level has eliminated doming? Or are you just stating that the command functions?

The command functions, and the resulting calibration works partially. I can wedge something under one side of the build surface and it will be mapped correctly, and the nozzle will travel over the surface at an angle. However, there is still some doming near one tower. Messing with the DELTA_DIAGONAL_ROD seems to make this better, but not perfect.

I'm going to do a full realignment and try again, and if that doesn't make it better I'm going to try mathematically changing tower positions.

[edward]

Thanks for the clarification. I'll be anxious to see the results if you perform an offline calibration of the tower positions. I've seen two reported successes of such a method so far.

[626Pilot]

I realigned everything but Marlin is back to doing that thing where it moves the axes in the wrong direction after running G29. I don't know what the deal is with that. Pretty irritating. Marlin overall seems more glitchy than Repetier.

Without autolevel, even after the realignment, it STILL acts weird around the X axis. I tried rotating the X and Y towers to 59 and 61 degrees but that didn't fix it. (I want to leave Z alone and use it as the reference tower, so it's level with the center, and then bring X and Y in line with it, because it's mathematically simpler.) Maybe I need to try something more aggressive.

At this point I find it unlikely that a Z-probe can take any of the work out of aligning a Rostock MAX by itself. I'm going to keep trying, but the results so far are not encouraging. Rotating tower positions is the only thing I find likely to work, and even that hasn't shown results yet. Maybe I'll stumble into some other solution.

I think the best autolevel system would be fully closed-loop during calibration. Three Hall effect sensors, one one each tower, a neodymium magnet on the effector, and a Z-probe as well. The firmware moves the effector to various positions and triangulates where it actually ends up using the Hall sensors, which would probably have to be plugged into the three unused thermistor inputs. (Hall-O boards have a raw signal line in addition to the "stop" line, which is strictly either high or low.) Since it can move the effector to a theoretical position and then measure the actual position with the Hall sensors, it can figure out the error between where it thinks it is and where it actually is at any point. With this we can derive the printer radius and delta arm length, and correct for any geometry errors. Additionally, the Z-probe lets it map the surface of the build platform, so it also knows exactly where it's laying down filament.

[626Pilot]

Alright, I mounted a depth gauge to the platform and tried again.

The Hall-O mount I made seems to have an accuracy of ~0.1mm, possibly because there is a small amount of sideways play. I learned this by observing successive bed probes - it dumps the Z height for each point, each time. 0.1mm of accuracy is about 1/5 as good as it needs to be, so that's not good enough. Printing it with a slightly higher filament multiplier might solve the problem. The SeeMe probe is probably better since it uses an endstop switch.

I resolved the issue with the carriages moving upward after G29 by changing some of the endstop settings. However, because of the accuracy issue, running G29 actually made positioning LESS accurate than it was already. There was still the odd behavior near the X axis, whether I ran G29 or not. G29 did make the head track at an angle if I propped the print surface up on one side, so it is doing its job - it just needs a better sensor.

With the autolevel matrix cleared, I tried mathematically moving towers again. I started by adding SIN_59, COS_59, SIN_61, and COS_61 to Configuration.h where it defines the three towers:

Code: Select all

// Effective X/Y positions of the three vertical towers.
#define SIN_59 0.85716730070211228747
#define COS_59 0.51503807491005421008
#define SIN_60 0.8660254037844386
#define COS_60 0.5
#define SIN_61 0.87461970713939580028
#define COS_61 0.48480962024633702908
#define DELTA_TOWER1_X -SIN_60*DELTA_RADIUS // front left (X) tower
#define DELTA_TOWER1_Y -COS_60*DELTA_RADIUS
#define DELTA_TOWER2_X SIN_61*DELTA_RADIUS // front right (Y) tower
#define DELTA_TOWER2_Y -COS_61*DELTA_RADIUS
#define DELTA_TOWER3_X 0.0 // back middle (Z) tower
#define DELTA_TOWER3_Y DELTA_RADIUS

Wherever the printer screwed up on height, I looked at the tower it was near and I watched how fast each carriage moved as the effector moved in and out of the trouble area. I did this for a good ten or fifteen minutes, just to get an intuitive sense of what the printer was doing and where it was probably going wrong. It was OK near the Y axis, but near the X axis it would lift. I noticed that in the problem area, the X tower carriage doesn't move much but the Y and Z do, especially the Y. Eventually I came to believe that the Y tower was slightly counterclockwise to where it's supposed to be, reasoning that if I mathematically pushed it in that direction that the firmware would compensate by pushing or pulling it just a little bit more during moves near the X tower. The increased push would bring the nozzle closer to the surface.

I ran several tests. I set DELTA_TOWER2_X and DELTA_TOWER2_Y to the sin/cos of 59, 60, and 61, and each time I did this I probed near each tower and made a note of how high or low each one was relative to the reference (Z tower in my case.) With three sampling points, I could see the effect of rotating the tower clockwise and counterclockwise. Sure enough, 59 degrees made it worse and 61 degrees made it better, so I left it at 61. I was then able to print the Onyx bed leveling aid successfully for the first time, ever.

Long story short: IF you have a sufficiently accurate Z probe, and IF you have your printer properly aligned (which may involve mathematically moving one or more towers around), Marlin's bed probing routine will automatically level the bed. I haven't tried Repetier's endstop leveling with the rotated Y tower yet, but I'm assuming it's probably the same story. As long as the geometry is solid, it's worth it to have a Z probe so you don't have to worry about manually setting the height or fiddling with the endstop screws.

[edward]

Nice

I'm thrilled to hear that someone else has been able to manually adjust the tower positions and see improved results! I was hating feeling the "works for me" attitude, because with the little information presented I can't know enough about a machine to offer sound advice.

As a reminder, Roland did accept my "commit" into Repetier 0.90alpha for EEPROM adjustment of the angular tower positions. He didn't include the radial adjustments...maybe I should get back to him on that. Since you seem to be the experimenting type, I'd be interested in how things work if you "copy" these tower positions into the Repetier development branch and experiment with the calibration routines. I'd like to, but the new job isn't leaving much time for these things

[626Pilot]

Part of "works for me" is that the tower position is just one thing that can screw it up. The delta arm length and printer radius have to coincide with all three tower positions or there will be problems. If someone takes this method and applies it to their printer, but their radius is 0.3mm off, maybe it won't work. You also have to redo the center height, all the endstop screws, and the printer radius after you move the tower. Hopefully you know how long your delta arms are. The only way I know to test that is to try printing something really tall and see whether it messes up halfway in.

I'm going to try moving back to Repetier. I'll let you know if the "endstop leveling" is worth the effort.

[edward]

The delta arm length and printer radius have to coincide with all three tower positions or there will be problems.

I'm not sure this statement is helpful. The delta arm length and tower positions are not directly related, i.e., adjustments to one won't affect the other. Printer radius and tower positions are...

If someone takes this method and applies it to their printer, but their radius is 0.3mm off, maybe it won't work.

I think it would work, but you would be chasing the correct values for many more iterations than necessary. I had a good 4-point calibration when I started, effectively eliminating a variable. I'm not sure how you would positively identify the "bad" spots without a bare-minimum good calibration, because with an in-spec machine, 4-points is all that should be required. While I did end up making a minor tweak to the printer radius in the end, that was only after I moved my Z-tower +0.15 mm radially, which ultimately required a correction of the radius by approximately +0.075 mm.

Hopefully you know how long your delta arms are. The only way I know to test that is to try printing something really tall and see whether it messes up halfway in.

I would suggest measuring if there is any doubt. Arbitrarily changing this value will cause scaling issues that you surely don't want.

[626Pilot]

The delta arm length and tower positions are not directly related, i.e., adjustments to one won't affect the other. Printer radius and tower positions are...

If you adjust one parameter, the effect of the others is also changed. They are all used to figure out how far to push or pull in order to get a desired position, and they're all compromised to the degree that any of them is inaccurate. In other words, none of these variables is an island.

I'm not sure how you would positively identify the "bad" spots without a bare-minimum good calibration

You wouldn't.

I would suggest measuring if there is any doubt. Arbitrarily changing this value will cause scaling issues that you surely don't want.

My calipers aren't super accurate. When I was having problems printing objects more than a few inches tall, I resolved the issue by increasing my delta arm length in steps until I could bracket the right setting.

[626Pilot]

Roland had this to say in an update to the ticket today:

I rewrote the z-leveling for delta. It is now working correctly and no iterative solution is needed. Please read the docs on my homepage on the new calibration procedure.

Anyone tried this yet?

[Eaglezsoar]

Roland had this to say in an update to the ticket today:

I rewrote the z-leveling for delta. It is now working correctly and no iterative solution is needed. Please read the docs on my homepage on the new calibration procedure.

Anyone tried this yet?

I'm waiting for SeeMeCNC to get it working and come out with a kit from that neat looking sampler they made.
May be a long wait.

[edward]

Anyone tried this yet?

I've been travelling all week. I haven't turned on my printer for something like 2+ weeks. Can't say when I'll get to it myself, but I'm interested in hearing any results if someone else tries.

Edit: Also, where'd you read this?

[626Pilot]

Anyone tried this yet?

I've been travelling all week. I haven't turned on my printer for something like 2+ weeks. Can't say when I'll get to it myself, but I'm interested in hearing any results if someone else tries.

Edit: Also, where'd you read this?

Ticket #120 in the "Issues" area of the Repetier github. If anyone wants to try it, the command is git pull (URL to Repetier repository) --branch=development. If you don't supply that last part you will just get the current production code, which doesn't have these fixes.

Anyway, bed leveling on top of the fix for stalling mid-print are both available in the development branch now. I compiled it and tested. Sure enough, it DOES NOT freeze on something that it was freezing on before. However, the bed leveling is a different story. TLDR: It still doesn't seem to work, but the documentation is missing some paragraphs so I don't know for sure.

There is an interesting new procedure for leveling the towers, one that could be useful to us even without bed leveling. He instructs you to disable the steppers and use a ruler to space all of the carriages exactly the same distance from the top of the towers, the idea being that if they're all precisely the same distance then the effector is exactly "centered." I did this by putting a ruler on its side between the carriage top and the endstop mount, at an angle across the carriage top in order to get a better level. He also says you can use a ruler to make them all the same distance from the bottom (of the tower, not the bed), which I suppose is the same thing. Then he has you run a custom G-code that is like G28, but it counts steps along the way to see how far each carriage is from the top when it's centered. So that levels the endstops, and from then on running G28 will cause the carriage to "bounce" a little after homing in order to center itself.

After that you're supposed to run other G-code to level the bed, but he forgot to type up that part. I tried the Cartesian instructions but they had exactly the same "raise on one side and dip on the other" as before. When I tried clearing the bed level data and just going off tower leveling, the calibration was worse than it was before. I have a feeling tower leveling is supposed to work in concert with bed leveling because Roland asked specifically, "How do you find the center?" in the GitHub ticket.

[626Pilot]

The Github ticket I mentioned is not #120. It's this one: https://github.com/repetier/Repetier-Fi ... issues/167

I ran six tests with various configurations and put the results in that ticket. Here's the breaks: With the towers leveled using the endstop screws (NOT THE SOFTWARE ENDSTOP LEVELING) and the bed leveling, it's about as accurate as no calibration. Software endstop leveling by itself leads to worse performance than before. The height measurement consistently comes up a couple mm short whether the endstops are leveled in software or not. Additionally, the trick of changing rotation of the towers HAS to be used on my printer (increased Y tower from 330 to 331 degrees), so it will not correct for that.

Since you have to level the endstops by hand in order to get the PRINTER_RADIUS set up right, software endstop leveling doesn't work (maybe due to my technique), and even the bed height probing is broken, I can't recommend using bed leveling at this time unless everything else you try has failed. Rotating the towers in firmware got me perfect first layers, even at .08mm layer height. If you have done the "four-point calibration" and set up your printer radius correctly, but you notice the radius is only good on one tower (e.g., you set the printer radius with the X tower but the Y/Z towers come up too high or low) the answer is probably to rotate one of the towers in firmware. At this time I don't think anything short of a closed loop position sensor (like the magnetic field triangulation I mentioned above) will correct for weird arm lengths, towers at slightly wrong rotations, etc.

If Repetier had the ability to get the height measurement correct, that would be cool. The rest is a waste of time, at least for now, because the printer radius has to be correct and you can't get it without leveling the endstops by hand anyway.

[edward]

Hey 626pilot, thanks for the detailed responses here. I finally read everything you've referenced here and elsewhere and, as I'm certain you felt the same, was disappointed to see the results of the revised Repetier leveling functions. I haven't seen much discussion any other place, so we'll have to take your experience as representative for now.

I'm am quite delighted to read that the option of modifying your tower positions in the Configuration.h file has shown improvements. Now I'm not the only one Unfortunately, that method still requires quite a bit of patience, as I'm sure you can attest.

I've been printing a bit more lately, but don't want to experiment too much as things are working nicely and the current stuff is for work. I'm currently in the build phase with the 3DR that I printed two months ago, so hopefully soon I'll have another Delta that I can use for experimentation.

[626Pilot]

I'm am quite delighted to read that the option of modifying your tower positions in the Configuration.h file has shown improvements. Now I'm not the only one Unfortunately, that method still requires quite a bit of patience, as I'm sure you can attest.

Let me see if I can distill it a little.

There are three kinds of error that can happen, and they are each caused by different phenomena that can interfere with the delta math. The three possible adjustments are the endstop screws, the tower rotation, and the printer radius. It's important to understand how each one plays into the delta calculations. (Not necessarily in the sense of the math, but concerning cause-and-effect relationships that explain how the error changes as the platform tracks across the entire surface.) There is also some counter-intuitive thinking that takes time to learn.

The endstop screws handle the rotation of the plane of the build surface first and foremost. The rotations must all be correct for the bed to be level. Imagine drawing a "T" across the build platform. You start out at the X tower, then draw a line to the center of the platform, and that's the vertical line of the T. Then you draw a perpendicular line across the top of that one, forming the horizontal line of the T, stretching from one side of the build platform to the other. That line becomes the axis about which the platform is rotated when you turn the X endstop screw. The phenomenon to be aware of is that RAISING the platform near a tower LOWERS it at the opposite edge, and vice versa.

The software tower rotation and printer radius determine how far the carriages move, and that amount increases with distance from the tower. This is because a carriage barely moves at all when the effector is close to the carriage's tower, but it must move progressively faster the further away it gets, or it won't push far enough to hold the effector at the same elevation. The reason a bad printer radius setting (on an otherwise perfectly calibrated machine) will cause lensing is that the carriage is either moving too far or coming up short. On the other hand, if a tower is at the wrong rotation, the printer will think it's starting from a different position than it really is, and then it will either move the carriage too far or not far enough depending on which direction the tower needs to be rotated.

Golden question: How do you tell the difference and what do you do about it?

• If you find that the carriage lifts or dips close to one tower and does the opposite close to the opposite side of the build platform, it's probably the endstop screw on the tower it's close to. For example, if the carriage always dips near X and raises on the half of the platform opposite X, tightening the X endstop screw by the right amount should correct it.
• If you find that the carriage lifts or dips close to one tower and does the opposite next to one of its neighbors, it's probably the rotation on the remaining tower. Look for Alpha A, B, and C in the EEPROM. You will see the values 210, 330, and 90. Reducing a number rotates the tower clockwise and increasing it rotates the tower counter-clockwise. You should only need to change the rotation by 1/2 to one degree. This is where you have to think of terms of pushing and pulling. On my printer, it was lifting near the X tower and dipping near Z. Y was OK, so I assumed it was the culprit. Changing Y's rotation from 330 to 331 fixed the problem, because that gave Repetier a better idea of where it was starting from. It then knew to move the Y tower a little faster when going towards X, and a little slower going towards Z.
• If you're doing the PRINTER_RADIUS calibration according to the manual, and you find that it calibrates fine to one tower but not all of them, you should suspect that something's funny with the tower rotations.

There is also the delta arm length. I never messed with that to fix these problems. The one time I did was to fix a tendency to fail after the piece got to a certain height, and that did work. This is not something you usually need to mess with, and once you have it figured out it can stay the same even if you redo the tower alignment. I have Trick Laser arms, and they are a little different. With SeeMeCNC arms, you'd just use their recommended length and not change it unless you also have problems with your pieces getting knocked around by the nozzle or air-printing, and even then, only if it constantly happens at the same height.