New Duet firmware with fast 7-factor delta calibration

I'm pleased to release version 1.04 of my fork of RepRapFirmware, available at [github.com]. The main improvement in this release is support for fast 7-factor auto-calibration for delta printers. To use it, you need to set up the coordinates of between 7 and 16 bed probe points in the bed.g file. The probe points can be anywhere you like, but obviously they should cover all areas of the bed. The sample file I provide for the Mini Kossel uses three points in front of the towers, three more near the edges of the bed midway between the towers, three halfway between the centre and the rim, and the centre (total 10). At the completion of probing, the firmware adjusts the three endstop corrections, the X coordinates of the X and Y towers, the Y difference between the XY and Z towers, and the diagonal rod length.

Starting from height differences of about 0.5mm between the highest and lowest probe points (which is what I have before I do any delta calibration at all), one iteration is enough to reduce the differences to 0.05 mm or less, which is as good as I can achieve with the mechanical Z probe of my Mini Kossel. Total time to do this is 27 seconds, including deploying and retracting the probe. With a better Z probe and a better delta build (i.e. towers that don't lean as much as mine currently do), it might be worth doing a second set of probing, which increases the time to about 45 seconds.

For the mathematically minded, what the firmware does after probing is to construct a matrix of differentials by differentiating the Z height at each probe point numerically with respect to each of the 7 factors. It then constructs the Gramian matrix of the differentials, then it solves the normal equations for linear least squares using Gauss-Jordan elimination. Note to mathematicians: I am aware that there are better ways of solving linear least squares such as QR decomposition, but I have limited mathematical training so I am not familiar with those methods. Feel free to improve the code and submit a pull request!

My thanks to hercek, who posted a wxMaxima script that gave me the idea of using a least squares fit.

This firmware release also supports version 1.05 of the DuetWebControl web interface, which is the web interface I recommend using with it.

---

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].

I read your post a while ago about the 32 bit however, I got a super cheap electronics kit (Ramp 1.4, Processors, ect) $24 bundle from China (However it is 8 bit Arduino Mega). Does having that 32 bit really effect performance and make life easier? I was thinking about buying 32 bit board, but the price is a little high.

Nice!
I'm glad somebody had a use for the maxima script. It was my hope when I published it.

Dave

just a couple of stupid questions but I need to get my head around the Config.g and Bed.g files.

in Config.g this section

// Z probe and compensation definition
;*** If you have an IR zprobe instead of a switch, change P4 to P1 in the following M558 command
M558 P1 X0 Y0 Z0 H8 ; Z probe is a switch and is not used for homing any axes
G31 X1.2 Y17.6 Z4.80 P500 ; Set the zprobe height and threshold (put your own values here)

;*** If you are using axis compensation, put the figures in the following command
M556 S78 X0 Y0 Z0 ; Axis compensation here

using your IR Sensor I have set to P1 think this is correct?
in the G31 line are the X Y Z values the offset of the sensor in relation to the Nozzle centre so my sensor is offset by 19mm in the X and 33mm in the Y (ie if you look down on the printer the sensor is 33 mm towards the Z and 19mm towards the Y towers) in this case should the line be

G31 X19 Y33 Zxxx P500 where Z would be the height difference between nozzle on the bed and the sensor above the bed?

If so then I assume that the Bed.g would have real unadjusted values for X and Y?

Just about to go and re-flash the Duet

TIA

Doug

Doug, I suggest you set the X and Y probe offsets in the G31 command to zero, and adjust the bed coordinates as necessary to keep the sensor over the bed. The reason is that the algorithm needs the actual XY coordinates of the head for the model to work, but the current code picks up the configured probe points instead - which is the right thing to do if you are trying to compensate for a bad that isn't flat on a Cartesian printer, but the wrong thing to do when calibrating a delta. I'll probably change it in future to subtract the head XY offset when doing delta calibration.

P1 for the IR sensor is correct.

---

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].

PS:

1. To see what the z probe values are before and after calibration, you can take a copy of bed.g file and replace the S10 in the final G30 command by S-1. Then run it as a print file or a macro. This will cause the Z probe heights to be printed out at the end of probing, instead of doing auto calibration.

2. You can connect Pronterface and enable Move debug (M111 P4 S1) to get a printout of what the auto calibration is doing.

Edited 1 time(s). Last edit at 04/03/2015 05:48AM by dc42.

---

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].

Quote
dc42
Doug, I suggest you set the X and Y probe offsets in the G31 command to zero, and adjust the bed coordinates as necessary to keep the sensor over the bed. The reason is that the algorithm needs the actual XY coordinates of the head for the model to work, but the current code picks up the configured probe points instead - which is the right thing to do if you are trying to compensate for a bad that isn't flat on a Cartesian printer, but the wrong thing to do when calibrating a delta. I'll probably change it in future to subtract the head XY offset when doing delta calibration.

P1 for the IR sensor is correct.

Thanks for the clarification time to start working out the co-ords then!!

one other thing what is the best way to run the bed.g file can it be put in the macro folder and run from the panel?

how is the sensor over a mirror/Kapton etc?

1. If you put the bed.g file in the /sys folder then it will be run when you do G32.

2. Mirror is probably the worst possible surface to use with the IR sensor. Ask your local glass merchant to cut some circles of 4mm glass instead. Preferably, if you have aluminium under the glass, put a sheet of black paper or thin black plastic between them. Or use BuildTak on top of the mirror.

3. Also see the PS I posted just before your post.

Edited 4 time(s). Last edit at 04/03/2015 06:46AM by dc42.

---

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].

Dave have you used Buildtak and if so how does it perform especially with ABS?

Just having second attempt at printing a case for the 5 inch display (Like the numpty that I can be I had the design mirrored thank god for the mirror function in Repetier Host) if it work ok I will publish it with that caveat not sure if I can mirror in Freecad but will try.

Doug

I haven't yet tried BuildTak, but it's on my list of things to do.

How much space do you have under your effector? I'm considering making a smaller IR sensor that can fit underneath the effector of my Mini Kossel in order to reduce the XY offset, and since I have to order 10 PCBs, I could make a couple more at the same time.

---

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].

I have 15mm under the effector on my E3D v6 with the Volcano heater a std V6 is around 10 mm Have you seen the new E3D V6 Lite that they have just released £21.50 complete or £24 for the Bowden one that is a bargain IMHO.

Would definitely be interested in a low profile sensor and I know of a couple more guys on here that would be as well AndyCart may also be a good customer for you as well as T3P3 I think.

Doug

time to go get some 4mm float glass cut to 380mm dia

15mm might just be possible if I put the Molex connector right above the sensor head parts n(or use a different connector) and the microcontroller to one side. 10mm looks impossible. Can you post a photo showing how the hot end is mounted on the effector?

---

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].

That sounds amazing. Im just finishing my new delta and it would save a lot of work. Is there any indication that someone is trying to integrate the same functionality into the normal RAMPS marlin version?

Buildtak is pretty good. I've just put a 400 x 400 sheet on my coreXY. If anything prints stick too well. It's a bit of a struggle to release them after the print has finished. You need to make sure your first layer isn't squished, as you would on kapton tape. I've set my first layer so that I can just see the bed between the infill lines and that seems to be the best setting. Still a bear to get off though. I've tried both ABS and PLA with good results for both. Make sure you don't dig into the bed with the nozzle as this will ruin it and also don't let the hot end sit touching the bed for any length of time as this melts a hole. All in all I like it but it is very expensive my 405 x 405 sheet was about £32.00.

Quote
sungod3k
That sounds amazing. Im just finishing my new delta and it would save a lot of work. Is there any indication that someone is trying to integrate the same functionality into the normal RAMPS marlin version?

I wouldn't have attempted this if I was still running Arduino/RAMPS. That electronics is underpowered for running a delta, you really need 32-bit controller electronics to do anything fancy like this, or even just to run a graphical display. On the Arduino Mega, the code would fit, but I estimate it would take 10 to 20 times longer to execute. So what is now a short but noticeable pause after bed probing would become a long wait. Also RAM is tight in Marlin because the Arduino Mega has only 8K, so there might not be enough free RAM to hold the matrices.

Edited 1 time(s). Last edit at 04/03/2015 08:44AM by dc42.

---

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].

Quote
sungod3k
That sounds amazing. Im just finishing my new delta and it would save a lot of work. Is there any indication that someone is trying to integrate the same functionality into the normal RAMPS marlin version?

[github.com]

Quote
This version has a much improved auto-calibration function which will hopefully be able to cope with many more printer configuration errors than previous versions were capable of resolving. The auto-calibration can now automatically adjust the following printer configuration variables:

· Delta Radius
· Diagonal Rod Length
· Software Endstop Offsets
· Z-Height Correction
· Tower Position Error Correction (independent Radius and Radial position adjustment for each tower)

All of these values can also be changed manually if desired using the M666 command .

Quote
AndrewBCN

Quote
sungod3k
That sounds amazing. Im just finishing my new delta and it would save a lot of work. Is there any indication that someone is trying to integrate the same functionality into the normal RAMPS marlin version?

[github.com]

Quote
This version has a much improved auto-calibration function which will hopefully be able to cope with many more printer configuration errors than previous versions were capable of resolving. The auto-calibration can now automatically adjust the following printer configuration variables:

· Delta Radius
· Diagonal Rod Length
· Software Endstop Offsets
· Z-Height Correction
· Tower Position Error Correction (independent Radius and Radial position adjustment for each tower)

All of these values can also be changed manually if desired using the M666 command .

I took a look at Rich Cattel's fork of Marlin before I implemented this, and was distinctly unimpressed. The algorithm he uses appears to be ad-hoc, rather than have a sound mathematical basis. The code adjusts all six tower position coordinates instead of just three, which is not only unnecessary but counter-productive. If you adjust too many of the tower coordinates, you end up translating or rotating the bed, which doesn't correct any errors but just moves them around - possibly to points that you haven't probed. The reports I have seen say that it takes many iterations to converge. But it doesn't need matrices or do a lot of FP calculations, so it's not demanding of the limited resources on an Arduino Mega. Maybe it's not possible to do very much better on Arduino/RAMPS.

---

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].

I wouldn't criticize Rich's work in a thread he might never read, that is kind of self glorifying and does not give him a chance to reply.

If you have some valid, constructive criticism to make about his calibration algorithm or its implementation, why don't you post in the relevant thread in the delta Google group forum?

Or better yet, fork his version of Marlin and implement whatever you believe is a better algorithm, then test it and make a pull request?

Also, who cares about the fp requirements of a calibration algorithm if all we need is to run it once in a while?

Quote
AndrewBCN
I wouldn't criticize Rich's work in a thread he might never read, that is kind of self glorifying and does not give him a chance to reply.

If you have some valid, constructive criticism to make about his calibration algorithm or its implementation, why don't you post in the relevant thread in the delta Google group forum?

Fair point; however I'm not a member of that group (I didn't even know it existed), and I don't propose to join it as I already spend too much time on these forums. I was responding to your post, which implied that his work was equivalent, and I was expressing my opinion that it isn't and explaining why. Feel free to alert him to this thread.

Quote
AndrewBCN
Or better yet, fork his version of Marlin and implement whatever you believe is a better algorithm, then test it and make a pull request?

I have no intention of ever running a delta on Arduino/RAMPS/Marlin again. As you are well aware, I consider it pointless to write computationally-intensive code that is constrained to run on ancient 8-bit microcontrollers with inadequate performance and insufficient RAM to code the task easily, when much better and faster 32-bit microcontrollers are cheaper. A 32-bit 3D printer controller board could cost less than Arduino/RAMPS, if there was the same amount of demand for it.

Quote
AndrewBCN
Also, who cares about the fp requirements of a calibration algorithm if all we need is to run it once in a while?

I do, because I run delta calibration every time I turn on my delta printer. I don't have to, but I would at least have to probe the bed to set the Z height. Once the machine is homed and the probe is deployed, it takes very little extra time to probe 10 points rather than 1; so why not do full delta calibration?

Also, the pause for the calculations is just acceptable on the Duet, but a pause of several seconds would disturb the other things that happen in the polling loop of Marlin, such as controlling temperatures. So the code would have to keep returning to the polling loop at intervals during the calculation - more complexity just to overcome the limitations of an inadequate CPU.

However, I see that another forum user has a separate fork of Marlin for Due, so maybe he will pick up the code.

Edited 5 time(s). Last edit at 04/03/2015 02:38PM by dc42.

---

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].

As dc42 indicated it is better if the calibration is quick enough so that you can run it before a print in a reasonable time. I would really like that if I would ever mess with the bed. The point is that the calibration will find the best endstop offsets too.

And it is nice if it can run on the printer controller. There is already kind of standard interface to run calibration/probing so it will work with almost any PC software.

That being said. One can make this work also for AVR with a customized PC application which will do the heavy lifting. The result would be out in few seconds. But it is less comfortable ... and you cannot do it before printing from an SD card only. AndrewBCN, looks like you will need to find some other software developer who is willing to do the considerable work of pulling the calibration solution search to a PC application. As for as me, I'll rather get some ARM controller for my next 3dPrinter

Edit:
Ach, and whoever would want to implement calibration in a PC may want to get a look at:
* dc42 source code,
* this notebook: [github.com]
* this project: [github.com]
* and possibly also this book (especially if you want to calibrate out more kinds of errors): [books.google.sk]

Edited 1 time(s). Last edit at 04/03/2015 09:05PM by hercek.

Quote
hercek
...
AndrewBCN, looks like you will need to find some other software developer who is willing to do the considerable work of pulling the calibration solution search to a PC application...

That's actually a good idea, since any reasonably coded optimization algorithm for a linear delta will run in less than half a second on any PC or ARM processor equipped with a floating point unit (the Cortex M3 MCU used in the Duet does not have a FP unit). All we need the AVR for is to probe the heatbed and report back the probed values to the PC or in my case, the Octoprint server. Then it's a simple matter of sending the new adjusted values using the M666 command, repeat the probe and iterate until the error converges to a predetermined minimum.

Another advantage of this method is that one can code the optimization algorithm in any language supported by the host (e.g. Python) and test and compare various optimization algorithms, without the constraints of the 3D printer's MCU hardware.

Edited 1 time(s). Last edit at 04/04/2015 06:23AM by AndrewBCN.

I have done a few more code changes and tests on the auto calibration. I can now auto-calibrate using 3, 4, 6 or 7 factors, for any number of probe points between the number of factors and 16 inclusive. I also added a printout of the RMS height error over all the probe points, and did some timings. This is what I found:

1. My machine starts with an RMS Z height error of 0.343mm. The difference between highest and lowest points is 0.432mm. This is using the stock values for diagonal rod length and delta radius supplied by T3P3, with the endstops as I built the machine, and with the average height out by around 0.2mm because I am running the tests with the machine cold and I calibrated the height when it was hot.

2. If I probe 10 points and do 3-factor calibration (endstops only), the RMS error drops to 0.123mm, and the difference between highest and lowest points is 0.392mm.

3. If I probe 10 points and do 4-factor calibration (endstops and delta radius), the RMS error drops to 0.077mm, and the difference between highest and lowest points is 0.258mm.

4. If I probe 10 points and do 6-factor calibration (endstops and tower positions), the RMS error drops to 0.023mm, and the difference between highest and lowest points is 0.062mm.

5. If I probe 10 points and do 7-factor calibration (endstops, tower positions and diagonal rod length), the RMS error drops to 0.016mm, and the difference between highest and lowest points is 0.061mm.

So adjusting the diagonal rod length as well as everything else made only a small improvement, despite the fact that it changed the diagonal rod length by nearly 2mm. The RMS errors are computed values, which I can't actually achieve because the mechanical Z probe on my Mini Kossel gives readings that vary over a range of up to 0.015mm if I probe the same point multiple times.

From the same starting point, I did 4-point calibration (endstops and delta radius) using only 4 probe points: one in front of each tower, and one at the centre. This is the standard delta calibration that most users perform. The resulting RMS error was of course zero, because it had adjusted 4 variables to get 4 points exactly right. Then I probed all 10 points. The RMS error was 0.131mm and the difference between highest and lowest points was 0.402mm.

My conclusions, valid for my Mini Kossel build and not necessarily valid for your build if it is more accurate than mine, are:

1. Probing 4 points and doing endstop + radius adjustment is not sufficient to get good results. [I already knew this from experience with trying to print large objects.] I need to probe more points (e.g. 10 as I did, but even 7 would be an improvement) and do a least-squares fit in order to get the calibration good enough to consider printing. Even when I adjust only the endstops and delta radius, using 10 points approximately halves the error compared to using 4.

2. To get the best results, I do need to adjust the tower positions.

3. I do not really need to adjust the diagonal rod length. Doing so makes a very small difference.

Other things I found:

- I tested how the residual error varies with the number of Newton-Raphson iterations. Two iterations gives slightly better results than one, so it worth doing, at least on the Duet (each iteration takes 31ms to calculate).

- Contrary to my original expectations, I now think that this algorithm could be used on 8-bit Arduino-based solutions. I hacked the code so that I could run it on an Arduino Uno and time it, and the calculation time came out at under 0.25 seconds in the worst case.

Edited 2 time(s). Last edit at 04/05/2015 03:49AM by dc42.

---

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].

I would say it kind of makes sense that one can leave out calibration of diagonal rod length. It is rather easy to make them precise or even precisely measure them with the help of a jig.
It is harder to place (virtual) towers precisely since they depend on the top/bottom extrusions (or plates), the tower brackets, carriages and the centre platform. Errors can add up there more easily.

Quote
dc42
...

- Contrary to my original expectations, I now think that this algorithm could be used on 8-bit Arduino-based solutions. I hacked the code so that I could run it on an Arduino Uno and time it, and the calculation time came out at under 0.25 seconds in the worst case.

Hi dc42,

Do you mind if I have a go at porting your 7-factor least squares calibration algorithm to Marlin? Where do I find it in your GitHub repository? Anything in particular I should be aware of? Marlin as I have it configured reports >3K of free memory (I assume that is RAM) available, so I guess that would be enough to hold the matrices in your algorithm?

Andrew, be my guest. I will be checking in a more flexible version of the code later today (version 1.04d) when my test print has completed, and I suggest you use that. The code is in [github.com] (note the dev branch, not the main branch which I use to track RepRapPro releases). The code you need to port is in Move.h and Move.cpp. In brief:

- class DeltaParameters holds the tower positions, diagonal rod length, and endstop adjustments. The methods for supporting auto calibration are ComputeDifferential and Adjust. Methods Transform and InverseTransform are also called, but equivalents of those should already be present in Marlin.

- Function DoDeltaCalibration in class Move does all the calculations, and is called when the bed probing has been completed. Ignore all the stuff about bed compensation in class Move, that's for Cartesian printers.

Edited 1 time(s). Last edit at 04/08/2015 11:23AM by dc42.

---

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].

Nice, thanks for the tips.

I have been looking at your code and it is quite neatly organized in separate blocks as far as I can see, so I believe it can be yanked out of your fork of the RepRap firmware for the Duet and reimplemented in Rich Cattel's fork of AVR Marlin alongside his calibration algorithm, so I should be able to compare the performance (accuracy, time to calculate and time to converge) of both calibration methods.

Also I believe that porting your calibration code to Marlin on AVR/RAMPS will expose it to many more, different test cases!

I am designing a Z-probe for my Delta Steel and will report back as soon as I have it working and begin hacking your code into Marlin.

I have now checked in version 1.04d, so please use that code.

What sort of Z probe are you designing? I will shortly be ordering PCBs for a variant of my differential IR board, reduced in size to fit under the effectors of most delta printers.

Edited 1 time(s). Last edit at 04/08/2015 02:36PM by dc42.

---

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].

Rumor has it that we will soon be seeing this new calibration routine ported to Smoothieware.....

Quote
dc42
I have now checked in version 1.04d, so please use that code.

Got it, will be hacking on that latest commit of yours.

Quote
dc42
What sort of Z probe are you designing? I will shortly be ordering PCBs for a variant of my differential IR board, reduced in size to fit under the effectors of most delta printers.

Oh, I am simply designing a holder for one of these $1 Makerbot-style mechanical micro switches that will fit my Kossel Mini effector (the same one I am using for the endstops, see my blog).

Actually I am done designing it and printed it a few minutes ago, and soldered the cables, tomorrow I'll be installing and testing it.

I know there are more accurate methods of probing a heatbed but this is very much what the "average delta" (i know, there is no such thing as an average delta) will be using, so if a calibration algorithm works with this, it should work with more accurate Z-probes too. Besides, I only think a more accurate Z-probe makes sense if the endstops are equally accurate. What would be the use of a Z-probe with 0.001 accuracy if the endstops are only accurate to 0.1mm?

Quote
AndrewBCN

Quote
dc42
What sort of Z probe are you designing? I will shortly be ordering PCBs for a variant of my differential IR board, reduced in size to fit under the effectors of most delta printers.

Oh, I am simply designing a holder for one of these $1 Makerbot-style mechanical micro switches that will fit my Kossel Mini effector (the same one I am using for the endstops, see my blog).

How are you deploying it?

Quote
AndrewBCN
I know there are more accurate methods of probing a heatbed but this is very much what the "average delta" (i know, there is no such thing as an average delta) will be using, so if a calibration algorithm works with this, it should work with more accurate Z-probes too. Besides, I only think a more accurate Z-probe makes sense if the endstops are equally accurate. What would be the use of a Z-probe with 0.001 accuracy if the endstops are only accurate to 0.1mm?

I run 7-point autocalibration before every print. At the moment, I home the printer at the end of the autocalibration sequence. However. I don't need to because the firmware corrects its idea of the current head position at the end of autocalibration (in Move::AdjustDeltaParameters), to allow for the changes made. So if I remove the homing call from the end of the delta calibration macro file, then it wouldn't matter if the endstop switches are much less repeatable than the Z probe.

At present I am using the microswitch Z probe on the Mini Kossel, which I think is probably less repeatable than the endstops. Still, I think I'll try removing that second homing anyway.

Edited 1 time(s). Last edit at 04/08/2015 05:55PM by dc42.

---

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].