Unsolved Mystery. Weird Z0 behavior around build perimeter.

[Eaglezsoar]

A Z-probe is how I get the depths in the first place, but you've given me a good idea. A person with a dial gauge, but no Z-probe, could simply test all the points by hand and feed the depths into the software via G-code.

That is a great idea! Is it possible to do this with the current release of Repetier?

[geneb]

626Pilot, since you're running simulations and not actually moving the machine - would it make sense to run the simulation on the host and then use the machine to make periodic validation runs? Your host calibration routine could change any of the needed parameters on the EEPROM and go from there. That way you're leveraging the monster CPU on your desk to do the heavy lifting instead of that poor ATMega on the RAMBo.

g.

[bdjohns1]

626Pilot, since you're running simulations and not actually moving the machine - would it make sense to run the simulation on the host and then use the machine to make periodic validation runs? Your host calibration routine could change any of the needed parameters on the EEPROM and go from there. That way you're leveraging the monster CPU on your desk to do the heavy lifting instead of that poor ATMega on the RAMBo.

g.

I think 626 and I are both using a Smoothie based hardware at the moment, so an ARM Cortex would be what we'd be stressing.

The only issue with doing all of this with just a z-probe or a dial indicator is that we're only addressing errors in Z. Those are the most critical as you start a print, but it would be interesting to do a bunch of tall columns around the edge of the bed and see how close to perfectly straight they turn out.

[redoverred]

A Z-probe is how I get the depths in the first place, but you've given me a good idea. A person with a dial gauge, but no Z-probe, could simply test all the points by hand and feed the depths into the software via G-code.

That is a great idea! Is it possible to do this with the current release of Repetier?

http://www.repetier.com/documentation/r ... z-probing/

I know repetier supports leveling and does it similar to how MatterControl does it (as per the most recent SeeMeCNC blogpost), but in the firmware. So what I'm thinking is that there has to be some EEPROM settings for each z-probe location where you could input the offset numbers manually for leveling and then use the auto-level firmware feature without running the G31 probing command or whatever it is. I'm going to look at that tonight, but I'm not super familiar with the firmware so It might take me a couple of weeks or months to figure it out.

I would use MatterControl, but I just don't like the hard-to-use method for slicer settings as compared to Repetier Host. I want to set Cura settings based on printer and then filament, but in MC I can't do that unless I go through and set every "quality" and "filament" setting manually. As far as I can see, if I change settings in MC and then go to save them it always saves them in the "default" profile, but I don't want that, I want to save them in a seperate "quality" or "filament" setting! It is so annoying how it works. I don't want to select 27 different separate options from some dropdown menus to make new "quality" or "filament" settings. Also, I can't have a slider for speed, which I like in Repetier Host when using Cura.

[geneb]

MatterControl DOES have the same speed & extrusion multiplier sliders that RH does - they're on the CONTROLS pane.

If you make changes that always save under the -default- label, it's because you're not changing the name when you create a new profile. I'll be covering how this works in the 2nd Ed. manual. It's not that bad, it's just unfamiliar.

g.

[redoverred]

MatterControl DOES have the same speed & extrusion multiplier sliders that RH does - they're on the CONTROLS pane.

If you make changes that always save under the -default- label, it's because you're not changing the name when you create a new profile. I'll be covering how this works in the 2nd Ed. manual. It's not that bad, it's just unfamiliar.

g.

Sweet, I've been trying to figure out how to make other profiles, but it never seems to change the settings when I switch from one to the other. When you get that section done, I'll take a look.

[geneb]

It's done.

g.

[626Pilot]

626Pilot, since you're running simulations and not actually moving the machine - would it make sense to run the simulation on the host and then use the machine to make periodic validation runs? Your host calibration routine could change any of the needed parameters on the EEPROM and go from there. That way you're leveraging the monster CPU on your desk to do the heavy lifting instead of that poor ATMega on the RAMBo.

I want to stay away from using external software if at all possible because that saves me from having to maintain host software on three separate platforms. I want to implement this on Smoothie because it's what I have, and the development stuff is easier in several ways. (Pure C++ rather than Arduino's schizo bastardized version, don't have to go through a janky preschool UI, time to compile and run is around 10 seconds because it uploads at full USB speed, etc.)

After I have all this worked out on Smoothie, it will be available on GitHub for anyone who wants to implement it in Repetier, Marlin, etc. At that point it will just be some straightforward mathematical functions. Those firmwares will need to be modified to support all the offsets I've added. I think Repetier does already. In any case, all the really difficult work will already be done, and all that will remain will be to port it.

Another possibility would be, rather than host software, something running on a web server with a modern processor. You'd type in all the depths for your printer into a form, and the web server would do some math and tell you the optimal settings. This would be my last choice, however, because it would put the solution to an important problem even further from the firmware. I think it's better to teach the firmware to solve its own problems, if it can. (I also want to avoid telling someone whose printer is in a shed or commercial space without internet access that they have to literally scribble numbers on a piece of paper, take them home, feed them into a website, and then try them on the printer the next day. I imagine a lot of these printers reside in buildings with roll-up doors.)

[teoman]

Hnm...

I had a slightly different approach in mind, coming from a Rambo background (which is limited), i was hoping to have Rambo write the findings to the SD card. The card can then be taken to the computer to run the optimization program, later the sd card can be brought back to the rambo and the firmware changes uploaded.
Your approach is ideal but it is slightly more cumbersome to develop (for me, initially that is) because once you have collected the data, you no longer need the printer.

That is once a solution is found all will be easy.

[bot]

I was just the other day having this exact issue. In some of the "across tower" corners of the bed, prints weren't sticking. I fixed it, here's how:

Start by removing the "center" point as a pre-set button on rep-host (what is the center? It's defined by the movement of the three axes.)

I instead set the 5 buttons as follows:

1: under Z tower
2: under Y tower
3: under X tower
4: across from Z tower
5: across from Y tower
and then for the "sixth" I simply copy and paste the g-code for "across from X tower".

Then, by EYE (with the shiny clean glass bed to use the reflection of the nozzle to determine the height of the nozzle. Do not apply glue or hairspray first.) I make the points at the tower and across from the tower equal. I go around, adjusting each tower slightly. It's frustrating because each time you adjust one tower, it makes the others out of whack. Just keep going around until it seems like no matter what the points won't level. Now you have to adjust your radius. What you are essentially doing is defining the center point. The reason the "across" position is raised or lowered is simply because of an incorrect radius setting. The machine, mathematically, thinks it's farther out or closer in than it really is.

After getting each across value and below value as close to each other as possible (THEY WILL NOT ALL BE EXACTLY THE SAME! It does not have to be perfect, but they have to be in equilibrium - ideally, the variation will be within the thickness of a piece of printer paper - as in, you should be able to "feel" the nozzle at ALL points, including the center, with the paper under the nozzle. Some will be FIRM grips, and some won't be as firm. You wan't the firmness to be as spread around and even as possible, ie not a sloped bed.) you adjust the z height so it almost CLAMPS on a piece of printer paper (thicker than lined notebook paper). You should still be able to move it, but it should be hard.

I am printing across the full area of the bed acceptably. Sure, the base layer has thickness variation, but it adheres perfectly across the entire surface and the prints are stunning... so I think that is the best we can hope to achieve. Don't be expecting to print 10" diameter shims with an accuracy of better than +/- 0.05mm. This is terrific in my opinion.

On that note, I reckon the true FULLY cylindrical build volume possible is 260mm in diameter, or 10.2 inches. Beyond that and I think the towers start slightly interfering... It could go beyond 260 in between towers, but we all know how that goes...

Also, if you look closely, you can see my new and improved, high-tech, patent-pending, ultra-closed-source, proprietary (because a lawyer told me so) cable-tie arm-tension system.

I don't want to release too many details yet because I plan on ripping you all off by selling existing technology as proprietary... but I'll give you a hint: it's 4 inch cable ties, 11 inch cable ties, and you have to make sure the nubs don't interfere with the effector and carriage (look at the picture closely).

Beyond that, it's all hush-hush hush. I don't want to reveal too much, but if you ask nicely I'll make a write-up/photo-series/video detailing the highly-unobtainable, proprietary design.

[lbarger]

I have been struggling for weeks to get rid of high spots at the perimeter midway between all three towers. End stops and radius only got me so far. Did not have any clear signal suggesting it was tower rotation as all points were similarly high. I did notice a fair amount of play on the end effector using stock arms. Since I need to print large parts for my business, I broke down and ordered the carbon fiber arms.

After installing the new arms, I noticed the minor play in the end effector was eliminated. I went through the calibration process (base of each tower, 129mm radius) and center. My first print, a star with 1.95mm cylinders every 60 degrees around the perimeter (and other points) yielded completely new results. My points opposite the towers were lower and between the X and Y towers was actually low. Finally I had indication of a tower rotation issue.

I created an Excel spread sheet with both inverse and forward kinematics. Given the values in the firmware for arm length, horizontal radius, radial position of towers and the positions of my printed columns, I determined the skate positions for each tower. I then had additional variables for the actual length of each arm, the horizontal radius and tower angles which I used to see where the end effector would move given introduced deviations from the idea. I could then try different values for each variable to try to match my printed results. This told me to rotate my X tower .4 degrees and to increase my horizontal radius .1mm. Making the changes in firmware and printing again and I'm close. Still need just a bit more fine tuning, but the first layer now sticks on all six points.

This experience has me believing that this issue being seem by some users of lifting between all towers is caused by play on the U-joints. I have not done the math to confirm, just observational conjecture. As a mechanical engineer, I can also note that when you transition from between the towers to outside, you go from having all arms in tension (weight of end effector) to a condition where one arm (to opposite tower) is in compression. If there is play in the joints there can not help but to be some change during the transition.

Sorry for rushing through all this, but I have to leave. Wanted to get this out there for the discussion.

Next step? Try to figure out how to go from printed cylinder height at specific locations to calculated changes to all end stops, horizontal radius and tower rotation. Not sure I have time for that anytime soon.

[bot]

Yeah. Did you read the post I made just before yours? The cable ties eliminate all play in the u joints. The rest is strictly a radius and end stop adjustment.

You seem to have achieved adequate results, what further improvements are you seeking?

[rpress]

I'm not sure if this was mentioned before, but this is what I found when I replaced my arms with ones I built myself.

If the print is too thin (too low) near the towers but not between the towers, the arm length needs to be increased. I had about a 0.15mm thickness variance that I eliminated by lengthening the DELTA_DIAGONAL_ROD by 3mm. After this change PRINTER_RADIUS also needed to be increased by 0.5mm to fix the bowl effect.

[Eaglezsoar]

I'm not sure if this was mentioned before, but this is what I found when I replaced my arms with ones I built myself.

If the print is too thin (too low) near the towers but not between the towers, the arm length needs to be increased. I had about a 0.15mm thickness variance that I eliminated by lengthening the DELTA_DIAGONAL_ROD by 3mm. After this change PRINTER_RADIUS also needed to be increased by 0.5mm to fix the bowl effect.

Thanks for the tip!

[lbarger]

Yeah. Did you read the post I made just before yours? The cable ties eliminate all play in the u joints. The rest is strictly a radius and end stop adjustment.

You seem to have achieved adequate results, what further improvements are you seeking?

I tried rubber bands on the stock arms which helped, but did not eliminate the issue for me. Perhaps they were not tight enough as I was worried about long term deformation of the plastic material.

There is a difference between having a relatively thin part weakly stuck to the bed versus good bed adhesion. Measuring the 19 test points on my most recent (self designed) 'calibration star', I find I currently have 0.16mm variation from low to high. While this is far better than the 0.55mm after initial calibration and 0.35mm after weeks of fine tuning/tweaking I doubt the large piece I need to print in ABS will stick well enough to avoid curling even with my insulated box.

I currently have a spread sheet where I can plug in the values currently set in firmware. I can also enter possible errors for these numbers. By working through a progression of possible errors I can track down what changes I need to make to account for the (now relatively small) errors in my print. I previously found that if I rotated my X tower 0.4 degree clockwise and my Y tower 0.1 degree counter clockwise I should take care of most of the high/low I was seeing at the perimeter. Using my currently measured print I now see that I could stand to 1) Lower the X end stop 0.05mm, 2) raise the Y end stop 0.02mm, 3) raise the Z end stop 0.01mm and 4) decrease the horizontal radius by 0.1mm to eliminate the 0.05mm bowl effect. If I did this, I should reduce my error to about a third its current level.

My comment about additional work is more about creating some sort of tool or guide for the community to help others dial in their delta printers to print large objects. What I have currently is helpful for someone with a little math background and willingness to go through some trial and error. However, with enough calibration points it *should* be possible to create a set of equations that would calculate what changes are needed to end stops, printer radius, horizontal radius, tower rotation and possibly other variables.

After going through the calibration method described in the manual, print a sample piece, measure specific points and enter that data along with the initial firmware parameters into a spread sheet or other program. The computer can then prescribe changes to the firmware settings to get closure to truly calibrated. This would still likely require a little 'rinse and repeat' methodology as for many the first print may not stick between the towers.

[bot]

I think you are all overthinking this.

I can print large prints across the entire surface of the bed with even the smallest little circles sticking perfectly. If be adhesion is te only issue, then it's a simple fix. Granted if you are looking for a perfectly even base layer, you might need a new hobby. I simply don't see why people feel calibrating a delta printer involves so much inverse kinematics, spreadsheets and million probe points.

There are 4 variables at play (generally) in the stock setup. The 3 end stops and the radius. This is all that is needed to print on the entire surface of the bed. It can be calibrated by eye and then by verifying with paper. It's so simple. Why are people making it so complicated?

[teoman]

I think you are not able to appreciate this thread. If you are happy with your printer then you needn't pursue perfection.

But this thread is not about being able to do a single print. It is about adding intelligence to our toys. It is about creating a machine where you can modify it and let it learn the modifications and produce fine prints with minimal user intervention.

[lbarger]

I think you are all overthinking this.

I can print large prints across the entire surface of the bed with even the smallest little circles sticking perfectly. If be adhesion is te only issue, then it's a simple fix. Granted if you are looking for a perfectly even base layer, you might need a new hobby. I simply don't see why people feel calibrating a delta printer involves so much inverse kinematics, spreadsheets and million probe points.

There are 4 variables at play (generally) in the stock setup. The 3 end stops and the radius. This is all that is needed to print on the entire surface of the bed. It can be calibrated by eye and then by verifying with paper. It's so simple. Why are people making it so complicated?

First of all I am a mechanical engineer - I over think many things. It's my nature to want to understand how things work and why. That's part of the joy of selecting a printer kit rather than buying off the shelf. Then, when it does not work quite as expected, I want to determine root cause.

I understand for some users it works just the way you describe. I, unfortunately, was not one of those lucky users (initially). It appears that my set of stock arms had too much play in them which made the initial calibration problematic. I was seeing over .3mm difference at the base of the Y tower based on the direction of approach to the tower. Using the standard sequence of checking X tower stop then moving to Y I would get a good match on height (paper grab) at Y. However, without changing a thing except moving from the Z tower to Y, I suddenly had a huge gap between the nozzle and paper. I also had high spots between each tower at the perimeter which should not be possible (based on geometry) if you have the four standard calibration points correct. In order to not go completely crazy I NEEDED to document every change I made and needed to see what was happening a many points.

Once I switched out the arms, eliminating the play that was reeking havoc, it WAS a simple matter to calibrate. Since I had developed a crude tool for my less than perfect system I used it to dial in the printer. I'm happy with my current results.

The purpose of posting my particular trials and tribulations on this thread was initially to get help from the community and then to provide an update on my situation and hopefully point out things for others, who have not been able to dial in their printers to their satisfaction, to check. Also, it seems that it has only recently be mentioned that play in the joints can cause the high spots opposite each tower. I wanted to point out/confirm that this was the source of my problems.

Also, the process of calibration is still a rather iterative process. I propose that once a user's calibration is 'close', it may be possible to develop a tool that upon printing sample part and measuring the resulting output, one can quickly jump to the proper settings for their system. The main reason it may take multiple iterations with such a guide would be if the initial print did not adhere to the bed which would result in poor measurements. How many data points you need will depend on how many variables you want to analyze. You will need at least one data point for every variable. Having more than that would allow you to account for minor errors in measuring individual points rather like a check sum.

Since my results where not matching most posts I'd seen, I wanted to test as many conditions as I could. As such I planned for radial and angular displacement of each tower, variation in length of each pair of arms, changes to the horizontal radius for each tower and changes to end stops, about 12 variables total. Turns out it was much more than needed, but it's simpler to include up front than add in later. Should I now choose to build a custom printer later, I can use this spread sheet to optimize it.

Finally, for me this printer is not a hobby. I design and build prototypes for a living and this machine is a tool. For me it is worth the effort to get it as close as I can to 'perfect'. Also, I'm trying to print large objects in ABS which can be problematic if things are just a little out of sorts.

[bot]

Fair enough.

Are you still having trouble getting full bed adhesion with ABS? I can help you. I now have the problem of getting the last ABS part I printed to come UN stuck from the glass.

It will take, as you say, many iterations, but the only variables you will be adjusting are the end stops and the radius. I don't really wan't to de-calibrate my printer, but I may have to so I can demonstrate how to fix the issue easily without any advanced math or algorithms.

Also teoman, how do you define perfection? The mathematics that allow for our printers to work do not allow for perfection. You have obviously seen the research paper that has been attached in this thread previously, right? The plane of a delta bot will never be perfect. It is not possible.

[teoman]

Perfection is when you are happy with your printer. It is not really a mathematical concept in this context. I am aware of parallel kinematic mechanisms, we have built a few including all electronics and software.

Let us not dilute this thread further by discussing if it is a worthy pursuit. Even if it is futile, we are enjoying it and in the worst case learning something.

[bot]

But please, tell me what you are pursuing. Simply full bed adhesion? What tolerance do you want for points on the bed, and how many points, and where? Don't you think it's useful to set attainable goals, rather than unattainable ones?

[Jimustanguitar]

I think you are all overthinking this.

There are 4 variables at play (generally) in the stock setup. The 3 end stops and the radius. This is all that is needed to print on the entire surface of the bed. It can be calibrated by eye and then by verifying with paper. It's so simple. Why are people making it so complicated?

When I started this thread, I had the points directly under all 3 towers and at the center of the bed all within the width of the needle on my dial indicator... The 4 variables you mention were absolutely perfect, but I still had 26 thousandths of height variation between other points on the bed. It was truly impossible to print anything larger than a few inches. That's the problem.

[bot]

Yes. That is the problem. And if you read my post again you'll see how to fix it. You must level points across from the tower bases to be as close as possible to the same level as at the tower bases. Then from
There you adjust the radius and squish down the z height. If you have excessive play in your ujoints. You'll want to get risk of that by adding tension on the arms.

[626Pilot]

I think you are all overthinking this.

If adjusting the endstops and delta radius would fix every last Rostock MAX, we wouldn't need this thread. As I look at my printer I can see gaps on both sides of the Y tower, and on only one side of the X and Z towers. That suggests to me that they aren't right on the numbers, which means the math is off by that much. I would, at a minimum, want to look into that before deciding that the tower rotations didn't need to be adjusted. As it happens, adjusting tower rotations gave me the best calibration I ever had.

Indeed, from studying statistical analysis I can tell you that a sample size of one is rarely enough to guarantee a conclusion about the population. wolfmanjm told me he wouldn't accept my firmware upgrades unless I could prove that they work on more than just my printer, and I agree with him. We've both run a "perfect" delta calibration routine that worked great for the author, but failed to converge on a solution for either of us. In fact, it got progressively worse!

As to what we want, I don't know what the others are after, but for myself I'd like a printer that has as much accuracy as possible in the X, Y, and Z dimensions. Z might be enough if I just wanted to print statues all day, but I want to print gears that can fit together - but if the shape of a gear is excessively influenced by its position on the print surface, I can't have that. The gear I print in quadrant 2 may not mesh with a matching gear printed in quadrant 4. I've found PLA is pretty good with gears, and that it will self-adjust as gears engage with each other, but I want to take as much slop out of the equation as possible. People pay me for the work I do with this machine, and I want to give them the absolute best I can.

[redoverred]

I've read the whole thread pretty thoroughly now, but I'm not seeing a set of enhancements or calibration steps that will result in a decent setup. I can see that using something on the arms to tension them is very helpful as well as making sure that everything is tight as far as screws, belts, etc. go. I also see that running the endstops and horizontal radius cycle until the radius is perfect is a good thing. I've done those things.

One thing I'm confused by is how to adjust the tower rotations. I know the physical reason for adjusting them and the location at which I adjust them in the EEPROM, but I am not sure what direction I should adjust them to or which one I should adjust.

Right now I am getting halfway decent adhesion at 100C for ABS on Elmer's purple glue stick and sort-of-okay first layer thickness on the very outer perimeter of the ~280mm diameter test print pattern, but some areas are thin and some are thick and some don't adhere properly. Furthermore, I've artifically "fixed" those issues by setting the Z0.0 height to be way lower than it should be, so basically at Z0.0 the nozzle is RIGHT at the glass bed, which basically means I adjusted it until it was catching the paper and then lowered it another 0.15mm until the paper was not quite pinned but almost pinned.

Let's say I'm getting thin areas between the X and Y towers (front 2) but further towards the Y tower (right front) and then I also get thinner spots on either side of the Z tower closer to it than the other towers. Would that mean I need to adjust the X tower and Y tower or X and Z or what?

Not that I am complaining, you guys are doing good work figuring out this stuff, but I sure wish there was an extensive guide on what, when, and how much to adjust each of the calibration items (endstops, tower rotations, horizontal radius, etc.) and formulas for how to adjust them. I suppose that I should just get into the kinematics of the thing and try and do it myself if no one else is going to, but I have enough maths to deal with in school on a daily basis :)

Anyways, what I found is I am getting the best adhesion ever from simply adjusting the Z0.0 height down by .10mm or .15mm below the height from the "paper test" artificially and also adding some zip ties to the middle of the twin arms to hold both ends tighter (Basically just threaded them through the arms and tightened a bit).

Additionally, I'm wondering why we're offloading these calculations to the RAMBO? Why would we not have the PC that is creating the g-code create it directly in delta-compatible code? Then we wouldn't need to have all these calculations running on the RAMBO in firmware and could probably do some more advanced calculations and optimizations based on some input numbers from the physical machine. The slicer would still produce normal g-code, we'd just have a second run of the g-code through a delta-computer that could optimize the movements and then the RAMBO would just output the XYZ commands directly as linear actuation of the cheapskates in XYZ delta space rather than in physical XYZ cartesian space.