Unsolved Mystery. Weird Z0 behavior around build perimeter.

[626Pilot]

I really don't think shimming the bed or adjusting the endstop screws can fix this problem. I suspect the thread would be much shorter if either could. Shimming the bed is good if its surface normal (imagine an arrow pointing up from the bed in the +Z direction) is not pointing straight up relative to the towers. Adjusting the endstops is good when the effector is too high near a tower and too low opposite the same tower, or vice versa, with motion between the two tested points in a predictable (if slanted) straight line.

This problem is different. We see good Z positioning near the tower (same elevation as the bed center), and then it gets too high or low opposite the tower - but not in the same straight line we'd expect if the problem was merely a mis-adjusted endstop. The attached image should make the difference plain.

This should make it obvious why many delta robots use a Z-probe to map the bed. To my way of thinking, taking the slop out of the geometry and getting some firmware with working bed mapping is the best solution.

[bot]

I'm not at all suggesting to shim the bed. I mean "set the height" by causing the hot end to be placed precisely a paper thickness from the bed.

The image you posted is interesting. Is this something you created yourself? Or is this derived from mathematical computation? This does seem to be somewhat representative of the problem... though the perfect triangle shape in the center is interesting.

[626Pilot]

Other people are talking about shimming the bed.

The image came from a mathematical analysis of positioning errors in delta printers. The author has since taken down the source material. He created a virtual delta printer in Mathematica and then had it raster-scan back and forth across the bed with various simulated problems with the printer's geometry. The inside of the triangle is nearly perfect because there, the math works out properly. When the effector is no longer between all three towers - when it has to go "outside the triangle" - you get this.

[bot]

Oh yes, I found the paper. I've attached it to this post for easier reference.

I'm not sure if the paper is quite describing the problem you are having. The picture you posted shows only a 0.012mm error in the Z axis, with one of the setups. Also keep in mind those points that represent the towers are truly the center of the towers... [Edit: Hmm I'm not sure if those points are "virtual columns" and not the centers of the towers. Still... I'm not sure if this accounts for the magnitude of error required to prevent layer adhesion.]

[626Pilot]

The simulation is done on a generic virtual printer with different geometry and an arbitrary amount of error. Neither is accurate to a Rostock MAX, so there is no reason to expect the same level of deviation.

[bot]

Okay so you are saying there is enough excess tolerance in the max design to account for increased error in the "hot" zones? That seems plausible... but what errors in tolerance, specifically, do you think would account for that manifestation?

[626Pilot]

Delta arm lengths being wrong, towers not being exactly 120 degrees apart, each tower not being the exact same distance from the center, possibly others. At the end of the day the carriage opposite the location of the error is either moving too far or not far enough.

[Polygonhell]

My reading of that piece what's the error I that diagram isn't from simulated slop, it's from the fact that steppers have fixed resolution and as the arms move away from the towers basically Z accuracy suffers, by a small ammount, what's misleading is the big flat area in the middle wiphich is also curved, but the author is truncating to 4 decimal places.
That's a completely different form of error.
Unfortunately pretty much any error manifests the same way to varying degrees.
The issue with mapping the bed to correct the error is it ignores the XY error that is also introduced with any Z error.

[bot]

Delta arm lengths being wrong, towers not being exactly 120 degrees apart, each tower not being the exact same distance from the center, possibly others. At the end of the day the carriage opposite the location of the error is either moving too far or not far enough.

Have you measured the delta arms, tower orientation and spacing? It is easy enough to verify. I agree that the tower is either moving too much or too little. Have you tried adjusting each individual tower's steps per mm in firmware?

[bdjohns1]

Other people are talking about shimming the bed.

The image came from a mathematical analysis of positioning errors in delta printers. The author has since taken down the source material. He created a virtual delta printer in Mathematica and then had it raster-scan back and forth across the bed with various simulated problems with the printer's geometry. The inside of the triangle is nearly perfect because there, the math works out properly. When the effector is no longer between all three towers - when it has to go "outside the triangle" - you get this.

And there's your long-term answer. Take all of your motors, tower hardware, etc off the seemecnc frame. Reuse them to build a delta where the build surface boundary is completely inside the triangle defined by the pivot point of the carriages. The Mini Kossel almost satisfies this in a smaller form. The BerryBot nearly does in a larger form.

[bot]

You mean just use a smaller build area? Why the need to replace the SeeMeCNC frame?

[bdjohns1]

You mean just use a smaller build area? Why the need to replace the SeeMeCNC frame?

I'm assuming 626 wants the 11" build volume.

[bot]

Oh right, I see what you mean. I think the paper also outlines that as the arms get longer, the errors move around and become arguably worse.

[bdjohns1]

If memory serves from reading that paper a while back, the "correct" arm length to use is a function of the size of the tower triangle - there are plots in the paper showing how the errors change as a function of the tower spacing and arm length. If you keep the right proportion of arm length to tower spacing (assuming perfect construction), the error plot should look the same (with errors in magnitude possibly cropping up due to stepper resolution). I'm guessing that the "correct" arm length gives you the same angle between the tower and the arms at home position as the base Rostock/Kossel designs.

If you're going to go all out on the resolution front, you might as well go closed-loop on your control system and use a proper servo motor with a reduction gearbox. I've got some Allen-Bradley servos at work that can be spec'd to provide up to 2 million encoder pulses per shaft revolution. Throw a reduction gearbox on that to get truly ridiculous resolution.

[teoman]

Million encoder pulses per revolution is nice.

You would need a duo based rambo or something with much more computational power to compute.

[bdjohns1]

Million encoder pulses per revolution is nice.

You would need a duo based rambo or something with much more computational power to compute.

Of course. In the case of our setups at work, you've got an Allen-Bradley PLC ($7K list) doing the motion planning. I don't know the list price for A-B's Kinetix servo controllers, but I know they're north of $3-4K per drive. Granted, those are big enough to drive up to a 5 kW (3-4 HP) servo, which itself is a $3-4K item.

It makes what the RepRap community's done with cheap AVR / ARM processors and stepper motors all the more impressive.

[rlang59]

I have an acrylic V1 kit. I was first in line to buy the V2 upgrade when it was made available, but after another user told me the kit didn't fix this problem I realized it would be a waste of money. I was pretty sad about that. I have been thinking about designing a replacement for the top and bottom pieces that hold the towers in place, something that would exactly fit everything else and fully capture the towers with a very narrow tolerance. I think it also might be wise to completely replace the top plate with something much stiffer, like a T-slot triangle.

I had this issue with my V1 and after screwing with it for oh so many hours I decided to roll the dice and go with the V2 upgrade kit. In my case it did fix the problem but like anything your mileage may vary.

[bdjohns1]

I've got one of the very last v1 printers (I bought a couple of weeks before v2 was released). Using 626's quadrant method with a digital dial indicator mounted on the effector, I was able to get the bed level to less than 0.07mm absolute deviation between the quadrants (one at +0.04, one at -0.03), although I forced my test to possibly be worse by setting my test points at 70mm out from the origin in X and Y. I don't know if that got me "outside the triangle" on quadrant 1 (70,70) and quadrant 2 (-70,70), but I've had pretty good luck sticking things to the bed. I can see a little variation in the "fatness" of the extrusion on my first layer if I do a long straight line, but it's still getting decent adhesion. I ended up needing to rotate 1 tower 0.25 degrees. I have a rather large square - I borrowed a really good large machinist's square from a friend, then went to my local home improvement store and went through all of their 12" squares to find one that was good to within less than a thou at 12". My towers are all squared up that well, and I actually used a piece of aluminum angle to set the height of the top at each tower, so I've probably got mine assembled about as accurate as I possibly could.

The problem I'm currently fighting is more about the extruder's mount to the effector. I'm actually using 626's design off thingiverse, but somehow over time and/or running the print head into something, I've picked up a little slop in the mount. So, I've got one of tricklaser's wooden mounts on order at the moment to really lock it down.

[626Pilot]

The problem I'm currently fighting is more about the extruder's mount to the effector. I'm actually using 626's design off thingiverse, but somehow over time and/or running the print head into something, I've picked up a little slop in the mount. So, I've got one of tricklaser's wooden mounts on order at the moment to really lock it down.

Thanks for pointing that out. I discovered over the weekend that the E3D v6's bottom mounting plate needs to be about 0.45mm taller, as they changed the mounting profile on the heat sink. (I didn't think that was legit, aren't all groove mount parts supposed to have the same mounting dimensions?)

Anyway, I have a test part printed and I'll fit it later and update the Thingiverse model. If you are not "watching" the mount I recommend doing so, so you can stay up to date with any changes.

[bvandiepenbos]

Okay, I'm going to suggest what I remember my steps for resolving this were:

1) set the 0,0 point at your desired height (paper thickness).

2) Set all three tower points at the same height. This should now mean the plane is level? Not necessarily.

3) Move the hot end from A tower position and 0,0, watching very closely to the path of the nozzle. Does it travel STRAIGHT across the bed? Or does it lift up and then back down from the tower to the center point? Adjust your firmware settings until this is FLAT. My making this flat, your plane will likely be sloped in an odd direction. That's okay.

4) Re-set every tower height as in step 2.

5) Now you will move the hot end from the tower points to "opposite" tower points. As in the point of the bed directly across from the tower, in between the other two. You now have to set these opposite heights by adjusting the physical end stop screws. Continually adjust the screws, set all the height points, move the hot end across the bed.

6) Repeat steps 1-5 until you are happy with results. By repeatedly adjusting these variables, you will slowly bring your machine closer and closer into spec. When adjusting this, you'll maybe want to bring the hot end farther away from the bed and use the firmware movements of 1mm and .1mm to "measure."

If any of this is unclear let me know... it's possible you've tried repeating this procedure, but it was what lead to my solution. When I get my max v2 kit I'll take pictures and detail my calibration process (if it even works).

Thank you for the detailed description, I think you are pretty much right on. I do very much the same thing.
Yes, it can be very tedious and time consuming , but worth the effort. And far better than any auto probing routine I have seen so far.

[Flateric]

I know many of you may think this is obvious, while others may not be aware.

So I believe it is worth re-mentioning.

Any and all calibrations should be performed with the heated bed at your working temp as well as the hotend at working temp. Between the two the cold distances and calibrations will be different enough to affect your quality in prints and success.

[bdjohns1]

Okay, I'm going to suggest what I remember my steps for resolving this were:

1) set the 0,0 point at your desired height (paper thickness).

(snip)

Thank you for the detailed description, I think you are pretty much right on. I do very much the same thing.
Yes, it can be very tedious and time consuming , but worth the effort. And far better than any auto probing routine I have seen so far.

I think a better option once you get the end stop screws set approximately right is to use the software offsets for the endstops, which are accessible in the EEPROM. That way you've got a more controlled adjustment than trying to get the exact right amount of rotation on a screw head (and good luck if the head of your screw isn't perfectly symmetric about its rotation). That was a part of 626's method of calibration that I found to be a big timesaver. That eliminates one more variable from your setup.

[bot]

I think adjusting endstop offsets in firmware causes the problems... this is precisely the variable we want to eliminate - math errors by the controller board. The arduino/Rambo struggles already, adding decimal places lead to rounding errors and over-worked controllers. I had great success getting a flat plane without adjusting firmware endstop offsets.

[626Pilot]

I think adjusting endstop offsets in firmware causes the problems... this is precisely the variable we want to eliminate - math errors by the controller board.

Firmware carriage offsets are not factored into actual motion planning. When you G28 the printer and it hits the endstops and backs off, it moves the carriages down by some number of steps according to the firmware settings. If you only use the adjustment screws, that number is 0. Otherwise, it's some other number, with each step repeatable to ~0.01mm or better depending on microstepping and how many teeth your pulleys have. (Try getting 0.01mm accuracy on those screws. You might get it, but it'll take way longer.) Whether the carriage is at 403.8461mm purely because of adjustment screws, or adjustment screws + firmware offsets, makes no difference. As soon as the carriages get where they're going, that becomes "relative zero" and the printer's coordinate system is initialized. After that, the printer doesn't use the carriage offsets in any calculation until G28 is run again.

[bot]

If that is the case, then I guess there is no harm in going that route. I haven't perused the firmware source code myself so I wasn't aware how it worked.