› ›

New way to auto-calibrate delta in one shot

paul_deltapaul_delta
in Feature Requests
Hi,

There is an online calculator/calibrator for delta printers http://escher3d.com/pages/wizards/wizarddelta.php written in Javascript.
It works pretty good for my Kossel Delta and Repetier 0.92.6. There is no need anymore for neverending manual iterations to get so-so bed leveling - I need just enter my firmware settings, z-probe provided coordinates, enter z-probe values back in to the form and get out-of-the-box parameters that provide pretty flat height map in Repetier-Host. It would be great to have this feature in firmware, using this algorithm or (may be better?) to have another menu in Tools, under Height Map menu that will z-probe and calculate everything automatically and then write it to eeprom.

Thanks!
«1

Comments

  • RepetierRepetier
    That is a nice algorithm also untested for the moment. I asked the author for permission, also I'm not sure it would fit into avr firmware version. It needs to store quite some variables to solve the mathematical problem. He had the advantage of having a due version, so he has much more ram. But we will see. If it does not fi it might get part of the server which then handles the data exchange.
  • docpaycedocpayce
    Will test it manually tonight or so. Why would you need permission by the author? He uses the "delta calibration algorithm that RepRapFirmware has built" - i.e. it is GNU GPL v3. (Probably I miss something ;) ).

    Also, how will this interact with X/Y adjustments or better said, Corr. diagonal A/B/C? Hope the angles will at least be the same...
  • RepetierRepetier
    The javascript is not open source and maybe it would be easier to add it in server or host. But we have the permission from the author. Also had a look into it and it is a lot to write and test, so might take some time to emerge in firmware.
  • docpaycedocpayce
    edited January 2016
    Just tested and results are ... meh.

    Without compensation (raw values before anything) my auto-leveled bed had a z_max-z_min of 0,23 mm (height map tool in rephost, no distortion correction).

    I put all the required values into the tool, revisited Repetier, changed the EEPROM settings accordingly and reset the controller (so that new tower angles are implemented into the calculations). The z_max-z_min got worse. It changed to 0.29 mm and the height map showed signs of offset tower angle (a "line" of constant height opposite of B tower). First I thought about the possibility that I put in all height values with negative sign. So I ran the procedure again, this time with negated z heights and the result even got worse with z_max-z_min 0.7 mm and a constant height line opposite to the A tower.

    Perhaps I did something wrongly. I would really be happy if somebody could confirm these results. My bed is not the best (not sooo level), so perhaps the tool was not able to compensate for me accordingly. But it seems to me the tool is trying to squeeze a bit to much of info out of a few z height measurements...
  • paul_deltapaul_delta
    Just tested and results are ... meh.
    If your diagonal rods are not equal, the calculator will not help you much. Especially if you probe has big offset from the hot end tip - the effector tilt will destroy all measures because of "floating" errors across the bed. I had successful results only after I designed this probe mount that has zero X/Y offset : http://www.thingiverse.com/thing:1198256
  • docpaycedocpayce
    Hey paul! Back from vacation just now. :)

    Will retry with manual testing (i.e. paper method) as my FolgerTech Kossel has a HUGE z probe offset in x/y directions. Will report back! My diag rods are nearly perfectly even (margin of error certainly smaller than 2 mm).
  • RepetierRepetier
    Diagonal rods should be exactly even. 2mm would be a very big error making it unusable. <0.1mm is what you should try to achieve or you will get extruder rotation while moving. Thats why you should use a template to create diagonals with same size.
  • docpaycedocpayce
    Yes, I did. I prepared all rods using two M3x50ish screws to align all six rods on both sides via their rod ends. They should be within +/- 0.1 mm range.
  • docpaycedocpayce
    edited February 2016
    Hey paul, hey repetier,

    back from the escher / z probe / correction front with good news:

    I printed out Pauls magnetic z probe mount (http://www.thingiverse.com/thing:1198256) with near-zero x/y offset (for me its in the 1.5 mm range) and re-tested the Escher3D method Paul was referring to in the first comment.

    Firstly, the x/y offset was indeed the major reason of my problems. With a high x/y offset, the reading of the z probe compared to manual paper method was in a range of (max) +/- 0.2 mm. After switching to Pauls design, the difference is now (max) +/- 0.05 mm.

    As a next step, I deleted all DELTA_DIAGONAL_CORRECTION settings, as I was told in Escher3D's manual (I *would* assume this is indeed necessary. Maybe DELTA_DIAGONAL_CORRECTION can be included in his calculations at some later stage.) and ran the numbers, here are my results:

    - Before Escher:
    Standard deviation of measured height: 0.164 mm
    Max deviation: +/- 0.205 mm
    - Escher first run:
    s dev: 0.040 mm
    max: +/- 0.050 mm
    - Escher second run:
    s dev: 0.029 mm
    max: +/- 0.035 mm

    Measuring the resulting z height map in Repetier host was very positive: There was one bump left with ~ 0.1 mm height, which was very likely a "real bump" in the bed (round shape , ~20 mm in diameter). Bed correction took very nice care of that, though I use DISTORTION_CORRECTION_POINTS = 15 now to get really good results (no memory problems, just minor problems with the G33 command - I posted this as a bug report).

    There is still a repeatable deviation of ~ +/- 0.05 mm between paper method and z-probing left now, which I would think one can only get rid of with either FSR z probe or much lower z probe offset (Pauls design results in a z offset of ~ 110 mm). I dont know whether I am gonna invest time and money into FSR's yet, but I am planning to adapt Pauls design to mechanical switches and thus much lower z offset - presumably 50 mm or less.

    Also, I did not yet calibrate DELTA_DIAGONAL_ROD and DELTA_DIAGONAL_CORRECTION. I do hope they wont eff up all other values in major way. If they do, I will report back.

    Never the less, the printer runs VERY MUCH nicer than before and I gotta say thany you Paul in a big way. :D I would full-heartedly suggest to include Escher3D's method into the firmware, it works, *IF* you got a low x/y offset probe.
  • docpaycedocpayce
    Just a little add-on, as I ran into some problems using Escher's method: Using it, the bed gets levelled VERY nicely indeed, but x/y scaling and angles maybe off by a little. But correcting these via diagonal rod errors and angles will counteract Escher calibration, resulting in a loop which gets worse and worse (Escher -> manual adjustment -> Escher etc).

    I.e. I still do use Eschers method to level the bed, as I am having the least problems doing so. But I do compensate for x/y scaling and angles (tan xy xz yz) in software/firmware afterwards. Only problem: There is no x/y scaling option for Delta's in Repetier as far as I can see (I do that in the slicer right now). When using Escher, adding this option to the firmware would be VERY helpful.
  • RepetierRepetier
    Dimensional accuracy is in deed a problem with this kind of optimization. It can not measure it with z probe, so all the minization problem does is moding the parameter to reduce z error neglecting dimensional accuracy. For dimensional accuracy you need something like


    Maybe that gives a start that deviates less in xy when calibrated. If it is uneven, the error will also depend on the xy position. I do not think that it is a linear error that you can simply fix with scaling + tan xyz correction (FEATURE_AXISCOMP). That would also only be a coarse correction.

    Scaling can easily added to transformToPrinter as it is just x = x * xFactor. In transformFromPrinter it is x = x / xFactor and for y the same.
























  • docpaycedocpayce
    edited February 2016
    Hey Repetier,

    the thing you linked is exactly the thing I used to try to calibrate my printer after doing Escher's optimization. The problem with this is that the linked thing and Escher are counteracting each other:

    - Escher tries to adapt for z using tower endstops and angles
    - The calibration "thing" adapts for xy (or tower accuracy) using diagonal offsets (which is f***ing up the tower endstop positions) and angles
    - If running Escher again, it will increase the needed endstop corrections
    - If then running the thing again it will increase the needed diagonal corrections
    - etc etc etc

    Yes, the axiscomp & transformtoprinter would only be a coarse guide to help getting a good print. :) But in my prints I saw pretty much the same deviation in the whole print bed up to now, no matter the z height. It would be a good start at least. ;)

    Is it transform*to*printer or transform*from*printer to be changed if I wanna try that? (You mentioned both)

    Thank you and BR!
  • docpaycedocpayce
    edited February 2016
    Just a remark: For now I will try to use Escher for 4 factors only (endstop positions = bed leveling, delta radius) in conjunction with (#spooky voice#) the thing (#spooky voice off#) you linked earlier. That might work well.
  • docpaycedocpayce
    Short update: No luck with that: Changing endstop positions will counteract the angle adjustment. It all gets just worse and worse. I will stick to the plan to level the bed via Escher as far as possible and adapt geomentry via transforms and axiscomp. :/
  • paul_deltapaul_delta
    Repetier: a lot of people had VERY good experience with this calculator. Of course, if they understand basics of delta geometry and mathematics. Currently this is the most promising way to calibrate delta in 1-2 iterations.

    Docpayce: this is not right place to show your inability to use this tool. If you have any concerns - please contact dc42 and stop annoying Repetier with problems that are far from Repetier firmware.

  • docpaycedocpayce
    I also *do* have the best results using Escher's calculator - I never said anything else. I do not understand how you interpreted my writing as "inability to use this tool". I have had (by far) the best results with this calculator.

    I just wanted to add reasoning that if Escher's calculator is implemented (which I would love), some form of firmware x/y-scaling could be helpful to partly counteract the missing possibility to adapt delta diagonal offsets. Which, btw, was very succesfull in my testing/firmware hacking right now (less than 0.4% length deviation in all 3 dimensions in a 50 mm cube).
  • RepetierRepetier
    > Is it transform*to*printer or transform*from*printer to be changed if I wanna try that? (You mentioned both)

    You need to modify both. toPrinter is when you have global coordinates and map it to printer coordinates, but sometimes we do it the other direction if we moved nozzle x steps we need to update real coordinates and then use the inverse function.

    paul_delta The escher solution has no input on xy positions as they can not be measured with a z probe. What he does is a optimization for z height based on measured values and possible modifications. These completely neglect xy accuracy and only optimize the z height to be as constant as possible and that it does very well. Depending on the real error or starting data in geometry this leads to neglectible errors in xy to errors or errors you can measure. And with that I do not mean a mm but maybe just 0.3mm. For most prints these errors can be ignored like figures. But sometimes size is important and you want to compensate that error as well.
  • paul_deltapaul_delta
    edited February 2016
    I understand that. Actually, I never had this problem because I always use calculator just to polish my eeprom values. I always use 6 factors calibration (without changing diagonal rod value - the main source of dimensional inaccuracy). BTW what will be very helpful to have in Repetier Host (or firmware itself) - the procedure to find correct horizontal radius, that will level the bed using 3 points, measure X0Y0 and adjust horizontal radius to make the bed flat. Here is my usual algorithm to calibrate delta with Repetier manually (actually I had acceptable flat bed after that even without calculator):

    1. Level the bed using endstops correction.
    2. Measure height error in the center
    3. Multiply height error by 2.2 and +/- the value to/from horizonta radius.
    4. Repeat
    5. Measure height error in opposite to tower points. Usually 1 or 2 such points will be off the level. Adjust horizontal radius correction for this tower for value that is equal to height error .

    Usually 2-3 iterations is enough to get pretty flat bed.
  • RepetierRepetier
    I like your simple solution. Especially how easy it is to fix the problem opposite to the towers where it likes to go up again. Maybe that would be a good solution to automate calibration.

    I also agree that the diagonal rod length is main source for dimensional error. 

    docpayce Did you use 6 factor without diagonal rod length? Maybe if you used 7 factors the 6 factor solution would converge.

  • docpaycedocpayce
    edited February 2016
    @paul_delta: When Escher calculator is implemented, steps 1 - 4 could be replaced by a Escher 4-factor calibration (it levels the bed and calculates delta radius). The only extra-thing to be programmed then would be step 5.

    @Repetier: I tried 7-factor once but quickly went back to 6-factor variant, because 7-factor calculation (with 10 measurement points) "corrected" my diagonal rod length from 240,0 mm to 241,7 mm, which would have resulted in (241,7^2/240^2)-1 = 1,4% smaller print size. That was way off, regarding that my printing size was well within a 0.5% range already.

    If its of any help, I will retry the 7-factor variant again (solo and with diag. rod corrections - *IF* the latter is useful at all?) and report back asap (which is likely on monday). I will also use paul's horizontal radius correction beforehand and revoke all the x/y transform firmware hacking I already implemented... ;)
  • RepetierRepetier
    @docpayce Just read my comment and it was not what I meant. I meant did you try 6 point to NOT change diagonal, so just what you apparently already did.
  • docpaycedocpayce
    I think I understood you now. I was a little bit confused by the last sentence.

    Yes, after Escher 6-factor, I printed https://www.thingiverse.com/thing:745523 and corrected both the delta diagonal rod length *and* the diagonal rod corrections. The diagonal rod length seems to converge nicely, but the endstop positions/angles and diagonal corrections diverge quickly.


  • paul_deltapaul_delta
    Just FYI, here is the initial release of calculator from spiffcow : https://github.com/spiffcow/DeltaCalibration
    The message on reprap forum: http://forums.reprap.org/read.php?178,445488,626121#msg-626121

    Now it's just the tool to help with calibration process, but, ideally, such kind of tool should communicate with printer directly, getting all data from eeprom and z-probe and writing calculated results back to eeprom.
  • docpaycedocpayce
    Any chance that this will find its way into the next release? Would be quite the killer-feature still.
  • aussieozaussieoz
    @paul_delta where can I find adjust horizontal radius correction for each tower? I cannot fint it in eprom settings.
  • paul_deltapaul_delta
    Delta Radius A/B/C.
    For example: to increase hor. radius for X tower to 0.5mm set Delta Radius A=0.5. To reduce - set it with negative value (-0.5).
  • RokoRoko
    Just tried this method,I went through the steps several times and was able to get it dialed in . The hardest part for me was making sure the towers balanced. When I adjusted the Delta Radius A/B/C for a particular tower I found I had to go back and forth between the 2 points of that tower to get them equal everytime I adjusted the Del_Rad number. Then I rechecked all 3 to make sure they were all correct.but I got it done.
    Thanks for the explanation of the terms.
  • juuliusjuulius
    edited June 2016
    hey guys just saw this thread 

    was wondering if anyone had tried opendact 

  • fanofccfanofcc
    Tried but seem it's not stable. At least for me.
  • docpaycedocpayce
    Also tried it, but can't get it to work. It connects to the printer all fine, but I can't send any commands nor can I disconnect or do anything else. 
Sign In or Register to comment.