Heuristic (AI) calibration for delta printers on Smoothie

[miglo]

That looks like a decent probe design to me. As long as the hangy metal part touches the glass right under the nozzle, it should be good to go.

I wonder why G31 OPQRS isn't making things better for you. Maybe the order in which it does the annealing for different variables should be different on your printer. I have been thinking about writing a separate routine that tries to figure that out. (It would take hellaciously long to run, but maybe worth it?)

G31 OPQRS doesn't work well for me either.

I always endup doing G32 first. Then G31 to figure out just the tower angles. Then G31 to figure out the endstops + shimming. Separately seems to work better than just having it try to figure everything at once. Then a G31 A. This seems to give me the best results.

I'm also realizing that the higher the bed temperature, the more deformed my surface becomes. I'm attributing this to the PEI sheet i have stuck on the glass.

[gestalt73]

Hey 626Pilot,

Yeah, it's literally an extra limit switch I had lying around from a previous build. And it's working great.
I have no idea why I was avoiding a dedicated probe. It is so much simpler, cheaper, easier, and more accurate than the FSR setup.

I'm not sure why G31 OPQRS isn't improving things. I've tried it a whole bunch of times on my superkossel, and a couple of times on my rostock max v1. In only once try out of maybe 20ish attempts, it resulted in an acceptable calibration.

Every single time, the simulated annealing results looked great, but would measure out to be worse than before when actually checking with G31 Z.

For whatever reason, running G32, G31 A results in an excellent calibration, every single time I run it.
My SuperKossel has a measured energy of 0.011, with a single high point of 0.035mm, and
My Rostock has a measured energy of 0.010 with a high and low point of 0.025 and -0.025 respectively.

These are incredible, and are far and away better than any hand calibration I've been capable of.

It looks to me like the machines might be capable of full bed 0.1mm prints. It's that good.

My Rostock Max V1 had a huge high spot between the x and z towers that I've been working around since I built it. We're talking about almost 0.5mm, and other issues, and your calibration routine figured out how to adjust away all of my machine imperfections.

Incredible! Thank you so much!

[EL Cuajinais]

Is there somewhere where I can find the parts list and instructions for installing a probe and smoothie board? I have a Mac. Is this PC only?

[gestalt73]

For me, it was dead simple. A limit switch, which is most likely exactly like the same ones used in your printer:
http://www.digikey.com/product-detail/en/0/SW780-ND

Then some wire, and a 3 pin connector you could grab from your smoothie kit or cannabalize a 0.1" header like I did.

Then whip up a mount in your modelling sofware of choice, and try to get the plunger directly underneath your hotend so there's no weird x/y offset silliness.

Wire everything normally closed, and grab kiiwii's config to get started.
https://github.com/iceboundflame/3dprin ... hie/config

Because the probe is lower than your actual hotend, you'll need to manually set your z-height when everything's done, or figure out the difference and add it to z-offset in the config file, if you only have one hotend.
[img]https://i.imgur.com/JLCfHS9.jpg[/img]

[miglo]

Oh crap, what a bummer, I thought I could get away with posting google drive images if the folder was public. Thanks for letting me know.
[img]http://i.imgur.com/FGc5DXi.jpg[/img]

Your limit-swith-zprobe is a REALLY good idea!!! It's so simple and elegant. I'm going to order some long-arm switches from ebay and try the same thing. Going to use my limited (and pretty sad) sketchup skills and see if i can do a quick clip on mount like you.

[gestalt73]

Wow, just awesome beyond belief.

Here's a quick shot of the first layer of a full bed print at 200 microns. It is just about perfect, the first time.

I've been printing with the Rostock for about 2 years now, and full bed prints are always an issue.
Endstops and Z-Height can only get you so far unless your machine geometry is perfect, and mine has never been.

This print was started after using 626Pilot's custom calibration code, and it's about perfect on the first try.
Like "I wonder if my z-height is off by 25 microns, and would it make enough difference to restart the print" kinda perfect.

[img]http://i.imgur.com/5BITpi1.jpg[/img]
http://i.imgur.com/5BITpi1.jpg

[626Pilot]

Good

I can't tell you what it was like when I did my first print where I didn't tortuously rotate the object in KISSlicer to keep it away from the several places on the bed that would always screw up horribly. Knowing that I can print something 9" across AT ALL on this printer is a great feeling.

[plasma]

Could someone post a built version for the firmware.bin. For some reason I cant build it on my Mac.

Thanks

[gestalt73]

Here's the firmware that I'm currently rocking on my deltas.

Just unzip contents to the root of your sd card, update your config using kiiwii's sample, and you should be golden.

[plasma]

Here's the firmware that I'm currently rocking on my deltas.

Just unzip contents to the root of your sd card, update your config using kiiwii's sample, and you should be golden.

Thank you

[Aflac]

I apologize if someone has mentioned this idea before...I have to get to work soon and do not have time to read the whole thread but i have read a good chunk of it.

Could you mount an accelerometer onto the effector platform somewhere and use that to tell when it touches.
something like https://www.sparkfun.com/products/9836
it seems like that would be able to detect contact pretty reliably from what I have been reading on it...would be a fairly simple mod to add. and could also measure angular movements so if you move all trucks up together it might be able to tell if its moving straight or at an angle so could measure tower lean for you.

My biggest question would be if they are sensitive enough for these purposes. but to my ohh crap I am late and need to type fast so i can go to work brain thinks it could work.

[Aflac]

or possibly even higher fidelity with in IMU like
https://www.sparkfun.com/products/10724
or
https://www.sparkfun.com/products/11055

[gestalt73]

Hey Aflac,

At first I was going to say no, but then I saw that it supports tap and doubletap sensing, so I suppose there's a chance that it could work. It would be a fun experiment to try.
The chip would need to respond to the tap almost instantaneously in order for it to work. limit switches are providing accuracy to around 0.01mm or better on average.
You'd also need to interface the accelerometer to the Smoothie, and write a custom rom to take advantage of it. You'll want to read through the datasheet, quickstart guide, and sample code to understand what that would entail.
Either that, or whip up an arduino board to interface the accelerometer to the Smoothie, as the current 636Pilot code expects one of the endstops to be triggered.

But to be honest, I'm getting great results with a simple $1.10 limit switch, just like what your Rostock uses already:
http://www.digikey.com/product-detail/en/0/SW780-ND

[img]http://media.digikey.com/photos/Omron%2 ... PT_sml.jpg[/img]

[Aflac]

Hey Aflac,

At first I was going to say no, but then I saw that it supports tap and doubletap sensing, so I suppose there's a chance that it could work. It would be a fun experiment to try.
The chip would need to respond to the tap almost instantaneously in order for it to work. limit switches are providing accuracy to around 0.01mm or better on average.
You'd also need to interface the accelerometer to the Smoothie, and write a custom rom to take advantage of it. You'll want to read through the datasheet, quickstart guide, and sample code to understand what that would entail.
Either that, or whip up an arduino board to interface the accelerometer to the Smoothie, as the current 636Pilot code expects one of the endstops to be triggered.

But to be honest, I'm getting great results with a simple $1.10 limit switch, just like what your Rostock uses already:
http://www.digikey.com/product-detail/en/0/SW780-ND

[img]http://media.digikey.com/photos/Omron%2 ... PT_sml.jpg[/img]

Yeah it would be a little more complicated but interesting....I am fairly comfortable e with arduino programming and have several laying about from the delta throttle joystick thing I'm making.

[FRANCO888999]

Hi,

first of all I need to say thanks to 626pilot for his code and for the hard work put in this project,
then sorry for my english.

After that I want to present my result with the heuristic firmware that it's very good from the point of view of the probe but I'm in to much issues with the print.
Long story short, I end the calibration with 0.011 of energy but the first layer is very orrible.
This is the calbration iter:

>>> G31 O P Q R S
SENDING:G31 O P Q R S

[HC] Heuristic calibration in progress. Press Reset to abort.
[HC] /!\ PROBE CRASH DANGER /!\ Don't press buttons, send commands, or access the SD card.

[HC] Data source: Probe
[HC] Active tests: [Endstops (O), mul=1.00] [Delta Radius (P), mul=1.00] [Arm Length (Q), mul=1.00] [Tower Angle Offset (R), mul=1.00] [Virtual Shimming (S), mul=1.00]
[HC] Inactive tests: (none)
[HC] Set geom during/after (J): During
[HC] Keep last settings (K): False
[HC] Annealing tries (T): 50
[HC] Max temp (U): 0.350
[HC] Binary search width (V): 0.100
[HC] Overrun divisor (W): 2.000
[HC] Zero all offsets (Y): False

[HC] Baseline kinematics updated.
[HC] Keeping existing kinematics.
[HC] Depth-mapping the print surface...
[PK] Arm length: 261.986
[PK] Delta radius: 125.865
[PK] Endstop offsets: {-0.821, 0.000, -0.819}
[PK] Radius offsets (ABC): {0.000, 0.692, 0.692}
[PK] Angle offsets (DEF): {0.537, -1.747, -0.983}
[PK] Virtual shimming: {-0.368, -0.374, 0.848}, vector={0.000, -0.008, 1.000}, d=-0.036, Enabled
[PK] Depth (Z) correction: Disabled
[PR] Priming probe 1 times.
[DM] Depth to bed surface at center: 665 steps (0.000 mm)
[PD] 0.112
[PD]
[PD] [ 0.000] -0.069 0.031 0.069 [ 0.000]
[PD]
[PD] 0.075 -0.062 0.000 0.075 0.044
[PD]
[PD] [ 0.000] -0.006 0.038 0.206 [ 0.000]
[PD]
[PD] -0.006
[PD] Best=0.000, worst=0.206, min=-0.069, max=0.206, mu=0.020, sigma=0.054, energy=0.066
[HC] Generating carriage positions for a printer with this configuration.

[HC] Starting test configuration: Arm Length=261.986, Delta Radius=125.865

[HC] ***** Simulated annealing pass 1 of 1 in progress *****
[HC] Existing calibration has energy 0.066

[HC] Reticulating splines...
[HC] Try 0 of 50, energy=0.060 (want <= 0.010)
[HC] Try 5 of 50, energy=0.077 (want <= 0.010)
[HC] Try 10 of 50, energy=0.083 (want <= 0.010)
[HC] Try 15 of 50, energy=0.054 (want <= 0.010)
[HC] Try 20 of 50, energy=0.054 (want <= 0.010)
[HC] Try 25 of 50, energy=0.054 (want <= 0.010)
[HC] Try 30 of 50, energy=0.054 (want <= 0.010)
[HC] Try 35 of 50, energy=0.054 (want <= 0.010)
[HC] Try 40 of 50, energy=0.054 (want <= 0.010)
[HC] Annealing has stalled - aborting.

[HC] End of annealing pass (energy=0.054)
[HC]
[HC] Heuristic calibration complete (energy=0.054). Final settings:
[PK] Arm length: 262.220
[PK] Delta radius: 125.676
[PK] Endstop offsets: {-0.475, 0.000, -0.289}
[PK] Radius offsets (ABC): {0.000, 0.880, 0.880}
[PK] Angle offsets (DEF): {0.218, -2.049, -1.469}
[PK] Virtual shimming: {-0.373, -0.165, 0.660}, vector={-0.002, -0.006, 1.000}, d=-0.040, Enabled
[PK] Depth (Z) correction: Disabled

[HC] Final SIMULATED depths:
[PD] 0.111
[PD]
[PD] [ 0.000] -0.018 -0.003 -0.000 [ 0.000]
[PD]
[PD] 0.207 -0.043 0.000 0.025 -0.007
[PD]
[PD] [ 0.000] -0.001 0.013 0.178 [ 0.000]
[PD]
[PD] -0.038
[PD] Best=0.000, worst=0.207, min=-0.043, max=0.207, mu=0.017, sigma=0.058, energy=0.054

[HC] You can run this command again to see if it gets better, or type M500 to save.
>>> G31 a
SENDING:G31 A

[DC] Probing bed for depth correction...
[PR] Priming probe 1 times.
[DM] Depth to bed surface at center: 712 steps (0.000 mm)
[PD] 0.131
[PD]
[PD] [ 0.010] 0.019 0.013 -0.044 [-0.044]
[PD]
[PD] 0.294 0.069 0.000 0.038 -0.019
[PD]
[PD] [ 0.199] 0.062 0.038 0.156 [ 0.139]
[PD]
[PD] 0.000
[PD] Best=0.000, worst=0.294, min=-0.044, max=0.294, mu=0.042, sigma=0.080, energy=0.073
[DC] Surface transform saved to SD card. Type M500 to auto-enable.

>>> g31 z
SENDING:G31 Z

[DM] Current kinematics:
[PK] Arm length: 262.220
[PK] Delta radius: 125.676
[PK] Endstop offsets: {-0.475, 0.000, -0.289}
[PK] Radius offsets (ABC): {0.000, 0.881, 0.881}
[PK] Angle offsets (DEF): {0.218, -2.049, -1.469}
[PK] Virtual shimming: {-0.373, -0.165, 0.660}, vector={-0.002, -0.006, 1.000}, d=-0.040, Enabled
[PK] Depth (Z) correction: Enabled

[BH] Determining the probe-from height.
[PR] Priming probe 1 times.
[BH] Bed height set to 352.919
[PR] Priming probe 1 times.
[DM] Depth to bed surface at center: 751 steps (0.000 mm)
[PD] -0.019
[PD]
[PD] [ 0.000] -0.031 -0.006 -0.006 [ 0.000]
[PD]
[PD] -0.006 -0.006 0.000 -0.013 -0.013
[PD]
[PD] [ 0.000] -0.025 0.000 -0.006 [ 0.000]
[PD]
[PD] -0.006
[PD] Best=0.000, worst=0.031, min=-0.031, max=0.000, mu=-0.005, sigma=0.008, energy=0.011

I had tested the g31 z three time with the same result.
I printed the test object with the frst layer with 0.3mm of heght and the result is that:

From the picture i the z axis there is the higher spot that became lower until the extruder touch the bed betwin the X and Y axis.
My bed is 260mm I used and calibrated only 200mm, my is a complete custom delta printer that is based to the original Jonathan Keep's project.
All part are made by iron and laser cutted, the carriage is built with ball bearing and there is not slack at all, the effector is printed and the arms is made by alluminium with traaxx joint

Please I need some help becouse I can't realy understand how is possible that the probe tell to me that there is only 0.031mm of error but when I print I have at the least 0.3mm of error, ten time the misured one!
I had tested also only the G32 and the G31 A with very similar result.

So I realy need to understand the origin of the problem, also because I need to know if had to destroy my printer !

Thank you

[626Pilot]

First, I noticed that the measured energy actually increased as a result of running the simulated annealing. That would result in a worse-than-default calibration. If you run it a few more times, it may eventually find a way to decrease the energy and get better. However, it might not. An energy of less than 0.1 is not too bad, really, and I would say 0.05 or less would be optimal. Yours was 0.66 - not too bad. There is a bias in the annealing process - it anneals each variable in a particular order, and I need to figure out a way to let it experiment until it finds the best order. Best way to reset everything is to run G32, which will do a GeneB-style calibration of the endstops and delta radius. That command dumps all the custom offsets that the simulated annealing tries to tune. In fact, I usually get better results from annealing if I run G32 first. It gives the algorithm a better starting point.

There is also some order-randomizer code I put in there, which is live on GitHub, but which should be commented out as the default order seems better than a random order: https://github.com/626Pilot/Smoothiewar ... .cpp#L1062

Put // at the beginning of lines 1062-1070 to turn off the randomizing code. Maybe that will help it run better on your printer. The randomizer will be removed in the next version so it won't be necessary to comment it out.

OK! Second. You calibrated out to 200mm, which is OK. But I have the .stl you're using (Onyx Bed Level Aid) and it's more like 260mm across. The firmware projects the measured depths from that 200mm circle outwards, so it thinks the depth at 250mm is the same as the depth at 200mm. (Which is the safest assumption I know how to make, as delta math is non-linear. Other guys' firmware just stops correcting if you go outside the radius!!!)

Ideally, you would calibrate out to 280mm or whatever your diameter is. But as the probing grid is only 5x5, this would be kind of rough. It makes it harder for the annealer to do its work when the sampling points are further apart, and it also makes the Z correction (G31 A) rougher. I do have an upgrade in the works that will increase the size to 7x7 or even 9x9, but it requires migrating a lot of stuff that uses memory to a secondary bus. (An annoying vagary of the processor they chose to use - the RAM is segmented into 3 pieces.) The migration is done, but there's a bug in the allocation of 2D arrays that I have to fix before I can publish the code. Therefore, at the moment, it is necessary to trade off between a smaller, better calibration that only works sort of OK for large pieces, or a larger, less precise calibration that will at least let you print big things sort of well.

[FRANCO888999]

Thank you very much for your time,
today I will try to move the G32 A before the annelling like your suggestion (I already commented out the random order), and also understand what you mean about the correction grid, but what make me crazy is the fact that the misure of the probe can't see the bed inclined, and it's true that a grid of 5x5 it's a bit small but the misured point in the G32 A command are linear intorpolated means that it's impossible to have some kind of "hole" where the probe touch the bed, correct me if I'm wrong.

[626Pilot]

The linear interpolation is far more helpful between the points than outside them. On a Cartesian machine, if the bed is inclined, you could just touch three points and get the surface normal and you'd be done. But on a Delta, the math is non-linear. If you draw a line across the print surface from left to right, along the X axis, you may find that it starts low - then gets high - then gets low again. Or, it could be the other way around. It can even be that such an undulation happens BETWEEN the probed points, which the firmware doesn't see and can't correct for - that's one reason why I want more than 5x5 to cover a big 280mm diameter print surface. Predicting how to correct OUTSIDE the probed radius is difficult because the software has no idea whether the surface is going to incline or decline of it goes in any direction beyond the probe radius. If I try to extrapolate based on the curvature inside, I could make it better, but I could just as easily make it worse. The better solution is therefore to use a larger grid, 7x7 or 9x9, and then do the calibration ALL the way out to the edge.

[626Pilot]

OK! New version: https://github.com/626Pilot/Smoothieware
Precompiled version: https://github.com/626Pilot/Smoothiewar ... rmware.bin

Changes:

• Annealing order randomizer was not useful, so it has been removed.
• 2D memory allocation bug fixed, but not deallocation.
• Grid size increased to 7x7.
• Test point calculation routine fixed to work with 7x7 grid.
• Simulated depth output removed - it's not useful unless you're me anyway.
• Simulated annealing automatically re-probes after it finishes annealing, so that you can see what REALLY happened.
• If you ask for something that requires bed probing, and the geometry hasn't been changed since the last probe, the last values will be used rather than pointlessly re-probing the surface.

My probe is kaput. I am done with Hall-O stuff. I am going to get a microswitch instead. The upshot of this is that I haven't tested it as much as I wanted to, but I think it's good to go. Please test and let me know if anything is amiss.

Thanks!

[gestalt73]

I see the commit on april 11th for migrating the arrays to AHB0.
But I also see "Fixed 2D array allocation bug - dealloc still doesn't work, so arrays will just stay around forever."

Does this mean that you were able to keep the arrays in AHB0?

I'll give it a go with the GLCD enabled tonight.

Thanks to your calibration routine, my Rostock went from "calibrated but quirky in spots" to "use the whole bed, see if I care"

Thank you so much!

[626Pilot]

All the big arrays have been migrated to AHB0. Here's the output from the mem command:

Code: Select all

Unused Heap: 4476 bytes
Used Heap Size: 21868
Allocated: 10136, Free: 10612
Total Free RAM: 15088 bytes
Free AHB0: 8732, AHB1: 10440

That's with GLCD and Ethernet turned off. The same command, after turning on Ethernet, the panel, and the laser module:

Code: Select all

Unused Heap: 3928 bytes
Used Heap Size: 22416
Allocated: 10320, Free: 10936
Total Free RAM: 14864 bytes
Free AHB0: 8732, AHB1: 10440

If you want to help me test with GLCD and/or Ethernet turned on, set second_usb_serial_enable to true in config, save, unmount, and reboot the controller. Then, you can connect a terminal to the second serial port and send the command 'mem' to see how much RAM is being used. Just make sure you turn second_usb_serial_enable to Off if you aren't going to have a serial terminal connected. Otherwise, Smoothie will hang because it has a serial buffer that never gets emptied!

[gestalt73]

Nice! It ran beautifully, and I tried out a G31 OPQRS again for kicks, and it improved the energy rating of the calibration.
I think My last best run was 0.06.

It ran just fine with the GLCD enabled.

What's interesting is that I tried to wrap it up with a G31 A, and I got a "[DM] Geometry hasn't changed since last depth map - keeping it!"

I thought G31 A was a separate step from G31 OPQRS?

Code: Select all

[PD]                                    0.050
[PD]
[PD] [ 0.000]     0.025     -0.045     -0.040     -0.060     -0.065    [ 0.000]
[PD]
[PD] [ 0.000]     0.035     -0.025     -0.030     -0.030     -0.010    [ 0.000]
[PD]
[PD]   0.135     -0.100     -0.070      0.000      0.010      0.030     -0.010
[PD]
[PD] [ 0.000]     0.165     -0.015      0.000      0.005     -0.010    [ 0.000]
[PD]
[PD] [ 0.000]     0.125     -0.020      0.005     -0.010      0.060    [ 0.000]
[PD]
[PD]                                    0.020
[PD]
[PD] Best=0.000, worst=0.165, min=-0.100, max=0.165, mu=0.003, sigma=0.045, energy=0.043

[gestalt73]

And I see you've enhanced M665:

Nice!

Code: Select all

>>>m665
SENDING:M665
A:   0.0000 B:   0.2242 C:   0.2242 D:  -0.7062 E:  -0.7378 F:  -0.4958 H:   0.0000 I:   0.0000 J:   1.0000 L: 295.8844 N:   0.0000 O:   0.0000 P:   1.0000 R: 155.4959 W:   0.0000 X:   0.0000 Y:   1.0000 Max Z  310.135

[626Pilot]

G31 A is doing that because ComprehensiveDeltaStrategy::depth_map_print_surface() remembers depth measurements. Those measurements are available because it probes the bed after annealing (instead of making you run G31 Z, like before). Since the geometry hasn't changed, it won't re-probe. In previous versions, it would "forget" the measurements, and it would be necessary to take them again.

M665 has been enhanced to be able to stuff a bunch of values into config-override. It now splits M665 stuff into separate lines as necessary, never letting any of them get over 80 characters long.

What probe radius did you use? Since I upgraded to a 7x7 grid, I've been using 135. Seems to work alright.

[gestalt73]

Currently my probe_radius is set to 110, i'll try extending the radius to 135 in between prints.

With the 7x7 samples, I think I'm going to turn probe_smoothing back down to 1 as well. I have good repeatability, and I've noticed that the calibration can change a bit just by moving the printer, so changing down to 1 should cut down on the calibration time.

The calibration is so simple and fast and accurate. I think I'll set up a gcode script to automate all the steps, and then kick it off whenever I change hotends or move things around.

Thanks!