Auto Level - Auto Calibration Talk

[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.

[geneb]

626Pilot & Edward, if you'd be interested in writing an "extended calibration" procedure that can start from where my basic calibration ends, I'd be happy to include it in the manual with attribution.

g.

[edward]

I certainly don't reject the idea of contributing...let's just say that there are one or two things on my list before I would get to that.

[626Pilot]

I would like to have some coherent troubleshooting steps in the wiki, based on the above. I found someone in Troubleshooting who is having a problem similar to mine and I sent a link to this thread. If it works for that person, cool, and if not maybe we can figure out some refinements.

Once there is something coherent and well-structured in the wiki, I'd say just copy and paste it into the manual. There will probably be a bunch of minor changes along that path so I don't know if you'd want to take what's here now.

[artexmg]

I would like to have some coherent troubleshooting steps in the wiki, based on the above. I found someone in Troubleshooting who is having a problem similar to mine and I sent a link to this thread. If it works for that person, cool, and if not maybe we can figure out some refinements.

Once there is something coherent and well-structured in the wiki, I'd say just copy and paste it into the manual. There will probably be a bunch of minor changes along that path so I don't know if you'd want to take what's here now.

626Pilot, what's the link to the wiki? sorry, I'm new here, so I didn't even know there was a wiki!

I'm testing this method, with help of some schematics I draw and a chart (trying to do it repeatable and systematic). If it works, i will report there.

By the way, modifying the height in the tower via the parameters in config.h shouldn't be the same as of psychically adjusting the screws?

[dpmacri]

626Pilot, what's the link to the wiki? sorry, I'm new here, so I didn't even know there was a wiki!

http://wiki.seemecnc.com

It's pretty new so there's not a ton out there...yet

[626Pilot]

By the way, modifying the height in the tower via the parameters in config.h shouldn't be the same as of psychically adjusting the screws?

That typo is funny.

Changing the Z tower height in EEPROM and adjusting all the endstop screws in precisely the same way are functionally equivalent. They both tell the printer how many steps it should take to get from the max height to the print surface if it was moving down in a straight line.

[artexmg]

By the way, modifying the height in the tower via the parameters in config.h shouldn't be the same as of psychically adjusting the screws?

That typo is funny.

Changing the Z tower height in EEPROM and adjusting all the endstop screws in precisely the same way are functionally equivalent. They both tell the printer how many steps it should take to get from the max height to the print surface if it was moving down in a straight line.

Great, I thought that, and that's what my "experiments" had shown so far, but I good to know that from somebody who knows better.

That is PSYCHICALLY GREAT!

[artexmg]

By the way, modifying the height in the tower via the parameters in config.h shouldn't be the same as of psychically adjusting the screws?

That typo is funny.

Changing the Z tower height in EEPROM and adjusting all the endstop screws in precisely the same way are functionally equivalent. They both tell the printer how many steps it should take to get from the max height to the print surface if it was moving down in a straight line.

Great, I thought that (and that's what my "experiments" have shown so far), but it is good to know that from somebody who knows better.

That is PSYCHICALLY GREAT!

[mcosman]

What am I missing? Is the rotation adjustment just tweaking the height of the towers in software to obtain a differential between towers?

[cope413]

No, the rotation adjustment tweaks the rotation of the towers

Ideally, each tower is perfectly squared to the center of the build plate, and 120 degrees from the other towers. That's not the case because of tolerances and other build factors, and if it's off enough, it affects accuracy. The rotational adjustment fixes that so that the machine knows exactly where it is and where it's supposed to be.

[mcosman]

So where in the software does one adjust that. I have been searching through the Arduino config and I'm not seeing it. Sorry for being dense.

[cope413]

It's not really just an "adjustment", or at least I don't think it should be. 626 and/or edward have detailed posts about the best way to do this. I would suggest going through their posts before you start adjusting your printer geometry

[626Pilot]

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. I will edit the original post.

[mrbi11]

Not to throw a monkey wrench into the thread, but I ran into a BIG discrepancy depending on how one gets from point a to b

G28
G0 Z1 F3500
G0 Z0 X-77.94 Y-45 F3500

Above is the manual calibration for the X tower.
It should reach the same physical position with or without the red intermediate vertical move,
but the measurement on my machine is almost a millimeter off vertically- with or without the red Gcode line.

Printing always drops vertically first, to the calibration with 3 steps is closer to printing, and for me yielded much better results.
My avatar is the before shot of a really big brim. The after is a perfect brim.

So whatever constants get thrown in the mix, if you are using the manual calibrations, it may be your calibrations do not reflect
movements during a print.

Although I got variations on all 3 towers, the X tower difference was by far the largest. The other two were less than 0.2 mm.

[626Pilot]

Not to throw a monkey wrench into the thread, but I ran into a BIG discrepancy depending on how one gets from point a to b

Can you rewrite this post? I can't understand what you're saying.

[mrbi11]

I had huge problems with 1st layers on large prints, even after carefully calibrating per manual.

The manual's calibration in front of X tower is:
G28
G0 Z0 X-77.94 Y-45 F3500

The manuals calibration movement is diagonal.
Prints move down vertically to begin, then move horizontally. Never diagonal.

This is the same calibration, the way prints would do them. Vertical first.
G28
G0 Z1 F3500 ; This moved down vertically before horizontal move
G0 Z0 X-77.94 Y-45 F3500

=======

So what I'm saying is, if you are using the manual's calibration methods, and if your machine is like mine, those calibrations have
NOTHING to do with where the print head will be during a print, given the same coordinates.
They should be the same, but are not.
On my machine (see my avatar picture) the two calibration sequences are almost a millimeter different Z (height.)

So before adjusting any constants, my suggestion is you check the calibration measurements themselves, which on my machine had huge errors.

I spent hours re-calibrating and swapping parts and on and on, till I found the problem was not where I was looking.

It appears to me, the machine is incorrectly moving on large (vertical) diagonal measurements.
So I stopped using (vertical) diagonal movements.

Sorry, I'm not a good writer. I hope that was clearer.

[626Pilot]

Oh, I think I understand now. I calibrated my printer like this:

G28
G1 Z5 F5000
G1 Xn Yn F5000

So it moves on Z first, then on X/Y. Then I would lower it by hand to snag the paper.

When the printer starts printing something, it just goes direct on whatever diagonal is necessary. Both ways are functionally equivalent. The calibration circles I print come out fine, even though the printer starts on a diagonal rather than moving Z first and then X/Y.

If your printer is showing a millimeter of error based on whether it moves diagonally or Z first, something is either loose or too tight, possibly your delta arms at the U-joints.

[mrbi11]

I agree they should be functionally equivalent.

I've spent weeks measuring and tightening and calibrating.

The measurements repeat within 0.1 mm every time.
I can push and pull while its moving, they end the same place.

If the stepper motors end in the same place, the tip should be in the same place.
I'm reasonably sure the stepper motors don't end up at the same spot, or maybe same count is the right term.

It sounds like the calibration method you use is the one I get correct results from.
It would be interesting if you tried the diagonal on you machine, to see if you get a close match.

The default Slicr's first move is to move vertical to Z5.
If yours is going diagonal, you may have customized it. Its in the preamble in printer settings.
Or maybe you dont use slicr.

Have you tried the diagonal calibration move?
I betcha 2 cents it doesnt match.

[626Pilot]

What I'm saying is that I calibrate it Z first, then X/Y, but when it prints it moves diagonally, and the results are the same. I use KISSlicer. If the results were different, I would have had to change my calibration to use diagonal moves instead of straight moves.

[mrbi11]

I think we are talking past each other.

When I am talking about diagonal, I mean from top of print volume to calibration point, with mainly z axis travel.
Horizontal diagonal works fine.

I am saying if you go home, g28, then go diagonal to the calibration coordinates, you end up somewhere slightly different
than if you go home, then down, then to the same coordinates.

So when you calibrate the tower points, do you go back to g28, then diagonally back down, or do you
stay at the bottom and move horizontally. If that is what you are doing, that is what on my machine gives accurate results.

And of the 2 ways to calibrate, going vertically down, then horizontal, is what prints do.
They start at the bottom, and move around on the same level.

Horizontal diagonal works fine. Vertical diagonal has errors, at least on my machine.