Big Delta, Marlin or Arduino percision limitation?

Hi all,

This is my first post here, and english is not my native language, so please bear with me. I'm facing a nasty problem where I hope to get an answer here.

Over the past twelve months, I designed and built two delta 3d printers (one for me, one for a friend). The important parts are lasered aluminium plates, aluminium tubes for the towers and linear rails for the sliders. The printer is a bit bigger than most deltas. Build room is ~16 inches dieameter and 16 inches height. In order to get the mecanics precise and right I designed and built all sorts of helper devices and gauges etc. The print head (single bowden extruder to keep things light weight and simple) can easily be replaced and one "head" is actually just a platform to hold a dial indicator to help leveling and calibrate the printer. The towers are exactly 120 degrees from eachother, exactly perpendicular to the build platform and paralell to each others. I spend a huge amount of time just to assure that the mecanics are precise enough. The arm joints are high quality and have no play. The arms were made to the vey same length using a custom built gauge.

The printer came out quite nicely, calibrates really well and works like a charm exept for what follows. In other words, for the very most part the effector runs paralell to the build plate lika a charm (all within about one mil). This is true as long as the pice that is printed stays within a diameter of about 14 inches. However, as soon as the diameter gets bigger up to the maximum of 16 inches, there are areas where the head no longer runs paralell. I created a picture to give a better idea about what I'm talking.



Whenever the head moves into the purple areas, the head rises gradually up with the maximum at the centers between the towers and outermost possible position. The maximum deviation from where it should be is about 120 mil which obviousely is a showstopper when printing parts of maximum possible size. I may also should add that the oposing arm in this extreme position is not yet parallel to the build platform, the slider in theroy still could move about 2 inches to reach this point.

The controller board is a megatronics V2 (ATMega 2560 based, similar to a ArduinoMega with a RAMPS 1.4). The firmware used is the latest Marlin version 1.1.5.

Since I invested about 150 hours in just verifying the precission of the mecanics in an attempt to find the source of the problem and fix it, I am reasonably confident that the issue does not have it's source in the mecanics. I of course still can be wrong, but I invested so much effort that I truly ran out of ideas for other possilble shortcomings on the mecanical side of things. What additionaly makes me think that the problem is not in the mecanics is the fact that the changes and potential improvements in precision and stabilty etc. did never change the problem I'm facing. I may also should say that both printers show precisely the same problem.

I am starting to wonder if I may hit a limitation of the precission by which Marlin with the forementioned hardware can calculate positions in those purple areas? Please note, as long as the diameter printed stays <= ~14 inches, no misbehaviour can be observed.

I'm thus looking for people with experiance in building BIG deltas which use a compareable controller and Marlin to learn if they may observe the same? If so, I would wonder what solution was found? I'm of course open for other ideas but the usual gotchas when building deltas do not seem to apply here... I'm truly out of ideas at the moment...

Any ideas?

TIA, Markus

Did you calibrate the tower angle corrections?

Quote
LVD
Did you calibrate the tower angle corrections?

I calibrated the towers (and all of the mecanics) "mecanically". They are really well aligned, perfectly in 120 degrees to each others, perpendicular to the build plate and parallel to eachothers. Measured / Verified it with a dial indidcator and some gauges, big digigal calipters etc. I made and constructed it to be so. The errors measured are <= one mil. It's a very high quality construction and the small real world errors (one mil) never could be responsible for this big of a deviation...

I'm particularly interested to hear from someon who consturcted a delta of this size or bigger and can share his experiance with regard to this. I'm really out of ideas on the mecanical side of things... The thing that makes this probably hard to belive is that smaller diameters do not show this behaviour at all. So IMHO it takes someone with practical experiance with deltas of this size or eventually a Marlin developper with insight into the precission of the delta kinematics calculations as they are impelemted on the 8 bit variants of the software. Please note, I don't want to sound arrogant - english is not my native language - I just try to point out that I spend about 150 hours just for improving and calibrating things to make sure there is no problem in the mecanics. I eventually still am wrong but looking back at what I tired / did / changed / improved and no change in this particular behaviour makes me starting to belive its eventually a software and or hardware limitation of the particular controller setup I'm using.

The people I know of who have built large deltas have all used 32-bit electronics. This isn't surprising, because large deltas are not cheap to build accurately, and it hardly makes sense to spoil an expensive machine by using budget electronics.

Many of the experts on delta printers hang out at [groups.google.com].

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

What results do you get manually moving the arms to the max position?
Did you calibrate it at the maximum distance from each tower?
Are the arms less than 20 degrees from parallel when they are at maximum distance? The carriage for arms 355mm long should be about 120mm above the effector for a 20 degree angle. Longer arms may solve your problem.

Quote
dc42
The people I know of who have built large deltas have all used 32-bit electronics. This isn't surprising, because large deltas are not cheap to build accurately, and it hardly makes sense to spoil an expensive machine by using budget electronics.

Many of the experts on delta printers hang out at [groups.google.com].

You are surely right with your statement, but we bought the electronics about one and a half year ago when here where I live 32 bit electronics were a bit exotic. I'm also keen to learn the source of the problem. In case it's not the electronics, going 32 bit would just lead to the same result.

I have to say that apart from printing on the purple areas, the printer performs totally to my expectations. So in case it's not the electronics per se, I don't see an immediate need to upgrade. Tonight I will try out Repetier and see if it makes a difference and will also double check the other posters advice regarding the arm lengths. I am in the process of deciding for a 32 bit electronics but haven't come to a final decission as to which of them to choose.

Thanks for the tip and link to the delta printers experts!

Quote
etfrench
What results do you get manually moving the arms to the max position?
Did you calibrate it at the maximum distance from each tower?
Are the arms less than 20 degrees from parallel when they are at maximum distance? The carriage for arms 355mm long should be about 120mm above the effector for a 20 degree angle. Longer arms may solve your problem.

Thanks for the tip with the arm lenghts. I'm currently not near my shop, but will check the angle out tonight and eventually create longer arms in case I'm truly below 20 degrees. Will also check again your other points.

I will post results here if there are news. Thanks.

You have probably slightly wrong delta radius and probably also diagonal rod length. Errors in these two can partially compensate each other and the imprecision can appear only at your purple places: [forums.reprap.org]

If you do not want to buy 32-bit electronics just yet then you can try to get/make a Z-probe a calibrate using this: [github.com]

Edit: By the way. The core problem of your machine is definitely not your 8-bit electronics. Your problem is most likely only a wrong calibration. You can run even a huge delta with it with 8-bit electronics. The problem will be that you will not be able o run it quickly. Big delta means your firmware cannot work with integers (in steps) but it must use float data types (in mm). That slows things down (in addition to square roots which are slow without FPU). The primary thing which comes with 32-bit electronics is calibration directly in the firmware. Well and a bigger speed of course.

Edited 1 time(s). Last edit at 10/02/2017 01:11PM by hercek.

Quote
hercek
You have probably slightly wrong delta radius and probably also diagonal rod length. Errors in these two can partially compensate each other and the imprecision can appear only at your purple places: [forums.reprap.org]

If you do not want to buy 32-bit electronics just yet then you can try to get/make a Z-probe a calibrate using this: [github.com]

Edit: By the way. The core problem of your machine is definitely not your 8-bit electronics. Your problem is most likely only a wrong calibration. You can run even a huge delta with it with 8-bit electronics. The problem will be that you will not be able o run it quickly. Big delta means your firmware cannot work with integers (in steps) but it must use float data types (in mm). That slows things down (in addition to square roots which are slow without FPU). The primary thing which comes with 32-bit electronics is calibration directly in the firmware. Well and a bigger speed of course.

Hi hercek,

Thanks for that information. It's very helpfull in two ways. a) it explains the wherabouts to me and b) gave me confidence that it's not a software / hardware limitation, hence it encurages me a lot to irno this out.

Thanks!

Markus

You will see limitation of your 8-bit electronics when your printer starts momentarily pause while printing. That typically means segment buffer underflow which happens because MPU is not quick enough to compute everything in time. This happens mostly because square roots and float are slow on 8-bit MPU (which does not have FPU).
You can mitigate that by:

• Lowering delta segments per second down to about 80-100 range. The error due to segmentation will be negligible at printing speeds of about 120 mm/s. The original Marlin (which limits maximum carriage speed) would have maximum delta segmentation error below 0.005 mm at this speed. I'm not sure about the latest Marlin. You may lower delta segments per second even lower but then also consider lowering the maximum printing speed by the same factor to be sure you do not have imprecision due to delta segmentation.
• If you have LCD then lower its refresh rate down to only something like once a second or disable it completely.
• Just lowering the maximum speed may help if the problem is that you are approaching maximum step rate of 8-bit electronics. I haven't seen anybody having this problem but it is an unlikely option.

If you will print at speeds people mostly use with delta (40-60 mm/s) then you can try to go with segments per second down to about 40 and then you are unlikely to be seriously limited by your 8-bit controller. If you use glass core belts then you do not need to strife for high speed anyway because you will need to use real low acceleration (probably below 4000 mm/s²) to avoid "ringing" around corners. And it does not make much sense to go for high speeds if your accelerations are pitiful. Well maybe it makes sense if you are going to print mostly long straight lines

hercek,

Thanks again for your hints! They are really usefull. If one like me builds and designs a delta from scratch, it's hard to get this type of information. Seems like you have quite some experiance in this area!

It seems that I was too high with the delta segments per second as they defaulted to 200. Will lower it to 100 as I only remember haveing seen very few stutters so far. The printing speed is currently set to 80mm/sec but I'm aware that this is on the faster side of things for my design. I'm in fact using GT20 belts which I asume is also what you refer to as "glass core belts". For more precise printouts I will lower the speed. I have a few smaller printers which I use for more precise printouts. This one was made with the intention to create bigger parts where some ringing at corners would be tolerable and yes, because of the size there will also be many long straight lines.

Interesting hint with the belts. What other ways would allow for higher speeds?

This delta project was an incredible learning experiance for me as I designed and built the printer all by myself. My next project (kind of got hooked) will be a coreXY printer. Seems to me like coreXYs are much less pickey with their kinematics and seem to have an almost as good acceleration balance as deltas (difference between X / Y axis acceleration is what I mean). I intend to try out a 32 bit controller with this but haven't made up my mind yet as to which one to use. Can you suggest one? No rush yet as I first want to make this delta work as designed.

Again, thanks!

Markus

GT20 profile is more precise than T25 profile but most GT20 belts are sold with glass core while most T25 belts are sold with steel core. Belt profile is independent from belt core otherwise. Glass core is less stiff which leads to more "ringing" at corners of your prints. On the other side the steel core belts will fail sooner when used with small pulleys (e.g. 16 tooth ones). If you see "ringing" at your prints then lower the acceleration or get stiffer belts or make your platform/carriages lighter.

CoreXY still needs to move smooth rods in one direction. It will always be somewhat slower than a delta. A Cartesian printer is easier to understand and tune. It is a better option for people who do not want speed.

DC42 can give you more feedback about 32 bit controllers. I still use an 8-bit controller. I would select a controller based on the firmware. Select a firmware you want based on the features the firmware implements, then select a controller which is able to run the firmware.