New Duet firmware with fast 7-factor delta calibration

Quote
bower-andy
...

It's interesting, though, that the 7 factor calibrate works well for me when the probe is central but not otherwise.

The 7 factor calibration is probably trying to compensate for errors caused by varying trigger height, which in turn is probably caused by effector tilt.

---

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

@dc42,

Thanks for that extensive tutorial of how to compensate for effector tilt. This seems a reasonable explanation as to why I was seeing the issue with the IR probe (although actually, the 8mm offset was to the measurement point and not the back of the board - yes, I know it is probably too close for comfort). When I get a moment, I'll switch back from the FSRs to the IR probe and try this out.

Best regards

Hi,

is there anyone who tried a simple metal sensing inductive probe? I recently got an aluminium surface so I ordered one of these inductive proximity sensors and soldered a little voltage divider to get the sensing voltage down under 5V.

Per M558 I would define it as P4 (switch) and there exists amble example for the ramps, so could I just mimic the same for the duet? and just

Quote

"P4 selects a switch (on the Duet, this must be connected to the E0 endstop pins)."

use the extruder endstop pins?

Yes use the extruder endstop pins.
You might need to invert the signal for NO switch.

You should be able to connect an inductive proximity sensor with NPN output directly to the E0 endstop pins. You will need to invert the signal level by adding M574 E0 S0 in config.g.

If your sensor has a PNP output, then use a voltage divider to drop the output to about 3V and use that to feed the analog Z probe input instead.

Edited 1 time(s). Last edit at 09/13/2015 03:43AM 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 don't know if this has been addressed yet, or if I could just find it in the code, but I have a few questions as I was getting ready to implement this. I just wrote a delta simulator. I took the inverse kinematics directly out of repetier, and modified the forward kinematics from the Steve Graves doc, but I modified it to take the error corrections repetier offers. Which leads into my first question. Why 7 factor? I'm not familiar with firmwares other than marlin and repetier. Marlin didn't seem to offer as much as repetier in a lot of things (I have a Cartesian that originally used marlin, not a delta, so I can't be totally sure) but repetier, including endstops, includes 12 points. Moreover, I'd expect it to be a factor of 3 since pretty much everything can be done on a per tower basis (delta axis basis?). Did you have 3, 3, and 1 like steps/mm?

Second, have you measured X/Y positioning accuracy. I had been thinking to myself, why hasn't anyone done this already? Damnit, I don't want to work! Then I saw your post....then I thought, wait, chances are if Z is off, X and Y probably suffer as well. So I added the ability to plot X, Y, XY, and XYZ error lengths to my sim, and sure enough, X and Y errors are similar to z errors in terms of range of errors (they are in different locations, its not like the plots look identical).

I'm at the point where I was going to add a least squares solver to my sim and see what it got for parameters compared to the original parameters. I'm thinking getting all 12 points in there is going to be a massive undertaking....so complex just keeping my head around it will be tough at best. But if I have my "ideal" printer, my "real" printer with inaccuracies, and a least squared fit for the parameters, I can see exactly how far off the error terms are, and how close to following the surface the print head will be, as well as positional accuracy. If it's too much for the firmware, so be it! I'll calculate on the PC! All I need is to be able to send it back to the firmware somehow (either manually and recompile, or send it to the EEPROM depending on the printer). Its always nice if the printer can do it by itself.....and I may add a "coprocessor" and hand optimize a solver for a cortex M4 (think arduino teensy) which has DSP extensions....that or just have some real fun and hook a DSP up over SPI/I2C, or even more nuts, try my hand with FPGAs.....but now I'm just getting ridiculous!

BTW....Once I get my sim cleaned up a bit more, I'll be happy to release it. Its C++/ASM/QT (I just can't bring myself to do vector processing with a scalar processor when SIMD units are there). I despise AT&T ASM though, so for Linux I might just have to either use intrinsics and C, or just go scalar...but other than that issue, it should work windows, Linux, OSX, and any platform that supports QT Its still *very* rough. I put it together in 2 days...so you can imagine stuffs missing. (like the file menu doesn't do anything yet )

Anyhow, main questions were, why 7 points, and did you check the X/Y accuracy or just the Z. Depending on your answer, I may abandon the whole thing, or try and figure out how to add X/Y probes into my printer

Edit: Actually, I think I answered my own questions. Looks like z is dependent on x and y in the forward kinematics. So either theres a wonky x/y that fits z and should be easy to reject), and/or x and y will be corrected. I also see you followed another's work in the 7 factors. I'm tempted to just port that, but also to do 12 factors...despite the headache...I mean the fact that you have to start with tower angles and radii...I think its going to depend on how bored I am That or I might have to talk a friend that has a PhD in math into doing some "kiddie" match as she calls it

Edited 1 time(s). Last edit at 09/27/2015 12:50AM by corry.

Not quite sure how DC42's calibration works. Afaik the 7 factors that are calibrated are:

https://github.com/dc42/RepRapFirmware/blob/dev/DeltaParameters.h

    float diagonal;			// The diagonal rod length, all 3 are assumed to be the same length
    float radius;				// The nominal delta radius, before any fine tuning of tower positions
    float xCorrection, yCorrection, zCorrection;	// Tower position corrections
    float endstopAdjustments[AXES];	// How much above or below the ideal position each endstop is

I think the x/y/zCorrection are the offset angles of the three towers. They should probably be called towerACorrection, towerBCorrection and towerCCorrection. Not sure if the radius is actually used or just a starting input value. If I remember correctly you only need 3 values to define the tower triangle. But here it seems to be defined differently.




I've written something similar here (very messy) and planned to port the code to javascript to make it a HTML calibration site. You could probe some points and enter them on a webpage and get your calibration values back. You could also add three different diagonal rod length instead of only one "diagonal".

The factors that get adjusted changed between firmware versions:

- Originally I adjusted the X position of the X and Y towers, and the Y position of the Z tower. Also the diagonal rod length and the homing switch positions. The delta radius was only used as a starting point.

- Later versions adjust the angular positions of the X and Y towers on a circle (these are xCorrection and yCorrection), and delta radius. Also the diagonal rod length and the homing switch positions.

- In later versions still I added zCorrection as a parameter in the M665 command, but auto calibration doesn't adjust it. The reason for adding it is so that you can rotate the XY printing axes, which is convenient if you are building a "square" delta.

Dejay is right, you only need 3 values to define the tower triangle, as long as you don't want to rotate the XY printing axes or move the origin to a point that is not equidistant from the towers. So all versions of my auto calibration algorithm adjust 3 tower position parameters.

I now recommend that users run 6 factor calibration instead of 7 factor, i.e. leave the diagonal rod length alone. This is because the diagonal rod length is not very well defined by probing, unless you probe opposite the towers well outside the normal printing radius. My implementation in RepRapFirmware supports 3, 4, 6 and 7-factor calibration. I explain how to select the number of factors at [reprap.org].

The number of probe points needs to be at least equal to the number of factors you are calibrating, but it is better to probe more points. If you probe e.g. 6 points to calibrate 6 factors, you will end up with zero error at those points, but it tells you nothing about how flat the printing plane is away from those points. I recommend using 10 points on a small delta, and 13 or 16 points on a large delta. My implementation supports up to 16 probe points. Even with 16 points, on the Duet the calculation only takes a fraction of a second.

---

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