New way to auto-calibrate delta in one shot



  • i have tried it but with the probe (think it lies with my probe) i cant nail it quite (still getting around +-0.1) 

    i had to set time and display settings on us otherwise the dot would not transfer to eeprom instead it would transfer big numbers. 
  • Hey Repetier,

    I am trying to revive this thread as I still do think that implementing dc42's way of calibrating a delta ( would be a killer feature in Repetier firmware, especially on 32-bit boards (namely RADDS or similar). Why do I revive this and ask you to PLS implement this into the next version? Because I tried smoothieware. And BOY is Repetier still such a much better firmware than smoothieware.

    Both in smoothieware and Duet firmware there are options to auto-calibrate a Delta machine. In Duet it's obviously dc42's method, as he programms the Duet firmware himself. In smoothieware it's just a radius and endstop calibration, which on some (wel-built) machines will be enough, not so on others. Repetier is unfortunately still missing such a auto-calib feature (besides compensation and leveling) and could benefit a LOT I think.

    Give it another thought, guys. Pls do!

  • So you are saying the method is working good. That's good to know. I once implemented a autolevel method and spend a week with it and removed it for not being stable. So did not want to waste again such a lot of time.
  • Probably the best solution would be a plugin for Repetier Host - to make it compatible with boards that are not capable to perform all calculations onboard.
  • edited February 2017
    Repetier said:
    So you are saying the method is working good. That's good to know. I once implemented a autolevel method and spend a week with it and removed it for not being stable. So did not want to waste again such a lot of time.
    I would say that with all the methods I tried up to now, dc42's calculator with 6-factors calibration using 10 probing points works out best for me (by far) and my rather crooked Delta printer. I do not compensate the bed anymore (i.e. I dont use G33), as the results with dc42's calculator are already very good (~ +/- 0.05mm deviation over the whole bed surface). G33 does not improve my results any further.

    Other methods I tried:
    - Auto-Radius + endstop correction via smoothieware + bump map = worse than dc42's calculator. Dunno why. Just smoothieware I guess...
    - Manual radius correction + endstop correction via Repetier + bump map = ok results, bump map has to correct for ~ +/- 0.25mm; VERY tedious;
    - Opendact = did not run on my machine, though I tried a lot of settings; no support on the forums;
    - Manual angle adjustement via No... just no. Results are usually worse than with any other method. And again, VERY tedious.
    - 7-factor dc42: Works fine, too, and converges nicely and quickly. But diagonal rod length will be off by +/- 5%. I was better off manually adjusting the diagonal rod length by the printed part size (i.e. printed part to small by x% -> decrease rod length by x% and do 6-factor calibration again; typically hits spot-on quite nicely).

    BR, Peter
  • Thanks for your analysis. I think you are right with diagonal. Problem is that you can not measure size in x-y direction so you easily optimize for flatness neglecting the size which you can easily bind to diagonal rod size. Also this variable is the most easy one to measure so keeping that as fact prevents drifting too far away. So when I get some time I will recheck how the computations are done and decide if we need it in host or can be done in firmware.
  • Hi, I have the same experience with Escher3D's calculator, 6 factor calibration is the best option I've come across so far. I'm designing a Windows app that uses the Javascript calculator in the background (with dc42's permission) and am now figuring out how to talk to the Repetier firmware to update the vallues in EEPROM. It's a free time project so I'm going slowly but it's looking good so far. 
  • Not yet! :) As said, still working on it, at the moment it's a front-end for the JavaScript calculator (you enter your values and it loads the webpage in the background, fills the parameters and gets the results) so it doesn't do anything that you can't do with the website. I have the serial connection to the printer up and running and now need to implement making changes to the EEPROM. This is my first project and printer with Repetier firmware, my experience has been mostly with Marlin and RepRapFirmware. That said, for the Delta I'm using Repetier firmware on I find it quite superior to Marlin on the same (8 bit) hardware. 
  • edited March 2017

    I just want to tell that the escher3d-Method done for 6 factors with 10 points worked fabulous for me.
    Error down to 0,03 mm! Four iterations and it was done.

    One pitfall!

    The method expects the angles to be 210/330/90 otherwise it would not convert.
    My machine was setup as 330/90/210 and it dit not convert.

    Changed to 210/330/90 and the result is fabulous.

    I contacted the author about this problem.

    I didn't need to do a G33 afterwards. My glas bed is a dream now!

    It would be really great to see this in repetier firmware!

  • And if you add and substract from the power position angles (in my case 120°) you will be able to use the wizard in any orientation of your printer.

    Thanks to David from escher3d for this fast answer.
  • Good hint, should be easy to test first angle against 210 and add difference.
  • Yes. And it worked REALLY great. No need for autolevel afterwards and also no need for distorsion correction. All my 10 testpoints are <= 0,05 mm height error.
  • I've tried Escher3D's calculator, the results are indeed good, but only with manual moves: as soon as I start a print the extruder moves in a strange way, almost ten mm above the bed and also hits the bed sometimes. I've tried it two times but with the same behaviour. What could be the reason?
  • solved: I had a feedrate too high. Nothing to do with Escher3D's calculator.
  • edited December 2018
    @Repetier, what do you think about this?
    Why not implement it within Repetier Server and Host, f you do not want to spend some bytes in the firmware?
    Work very well with Octoprint:

  • I want to add it in firmware v2. I think inside firmware it is best as we have all data exactly as required.
Sign In or Register to comment.