Heuristic (AI) calibration for delta printers on Smoothie

[Eaglezsoar]

miglo , would it be possible for you to share with us the stl files and the source of the magnets that you used and the part number?

Hate to ask but it is the only way to possibly get the files! Great job!

Found it!
http://www.thingiverse.com/thing:1547303

Thanks for the find!

[Fitz]

I have only read the first couple of pages of this thread so my question may have already been answered. Please bare with me! I have downloaded 626pilot's firmware and config files referred to as sept19 to use on a Azteeg X5 mini running smoothieware that is controlling a delta printer. My understanding to using his auto probing code is to 1. save his firmware to the sd card that I use on my X5 2. copy / add / change any of the lines of code from his config file that are not specific to his printer to the config file on the sd card that I use on my X5. Is this correct? Are there firmware or config file updates after Sept. 19, 2015?

Thanks in advance for any responses!

[megablue]

I've discovered this two days ago, I just gave it try.

Also, my ghetto zprobe using IR sensor gave me 0mm error with the probe calibration, i didn't know it was that good. I guess it is very important to mount the contact point and pivot point at the center of the effector.

I managed to get the energy to 0.154 with G31 HOPQR.

Then with Depth Mapping, the final energy score is about 0.014.

The question is, is the ideal energy score, 0.05 suppose to be achieve with G31 alone or after Depth Mapping?

[rubiks24]

hey 626pilot, love your work, I have been using it since day 1! Any plans on merging in the major code refactor from july? (http://smoothieware.org/blog:14) Supposed to have fixed the issue with path planning and bugs with S3D as well as improved acceleration calculation.

[Glacian22]

So, two questions about this firmware. First, in the instructions on github it says it may take a couple minutes to do the annealing calculations, but when I run G31 HOQR it only takes a couple seconds when it's finished to spit out the results...is something going wrong there?

Also, when I actually try to print using this firmware it'll draw the skirt loop, and then lock up when it tries to start the first layer itself...anyone else experience this? This is over USB from repetier...I'd try via sd card but my LCD is currently out of commision, is there any way to run gcode from the internal sd card that holds the firmware/config?

Thanks!

[626Pilot]

I did see that blog post, and it seems pretty cool. As with the PanelDue support, my inclination is to wait until these changes are merged into the mainline. I don't think their refactor will have much, if any, impact on my code, and I don't want to get too far into merging code that might vanish once it has been gone over by the Smoothie core team. (Git is not the easiest version control software - very powerful, but with that level of power, you get a ton of complexity and head-scratching.)

The firmware does indeed take only a few seconds. It used to take 45+ seconds, but then I optimized a critical section - it was searching for solutions in areas that were already excluded.

If it locks up after drawing the skirt, I dunno what to tell you, but maybe there's a weird M-code in there? Did you tell it to use a different temperature, and it's waiting for the hot end to come up to it? That's the only thing I can think of. The firmware doesn't know any distinction between drawing skirts and drawing the main object. You can send G-code to tell it to play a file, but you still need an interface like Repetier to do it. You could try loading the G-code into Cura or some other host, I suppose. If you have a Raspberry Pi laying around (or don't mind dropping $40 on one), you can run OctoPrint. For me, that solution has been flawless. It gobbles up huge G-code files in a second, and I've never had it spaz out on a print after hundreds of hours. OctoPrint has a lot of fans on these forums, and for good reason!

[campe89]

Hi 626pilot, many thanks for your awersome work!

I've a question: during the calibration workflow, I arrived successfully to G31 H O Q R, then G31 A report this problem:

Code: Select all

>>> g31 a
SENDING:G31 A

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

[DC] Depth correction doesn't work with X or Y probe offsets.
No strategy found to handle G31

My probe offset is:

Code: Select all

comprehensive-delta.probe_offset_x                      -24.25
comprehensive-delta.probe_offset_y                       14.0
comprehensive-delta.probe_offset_z                        0     

The problem is the offset? If yes, how can I fix?
Or something else?

Thanks in advance.

[626Pilot]

You can't use probe offsets for depth correction because they won't work. Your probe needs to be mounted dead center for that. Set the X and Y offsets to zero and use a center-mounted probe.

[campe89]

Ok, in future releases, it would be possible to use the X and Y offset for the G31 A command?
I think it's very convenient for us that we have the proximity always mounted and decentralized.

[626Pilot]

In my tests, the G31 A (Z-only) calibration worked significantly worse with an offset probe than with a center probe. It was bad enough to ruin first-layer adhesion (lifting in one place and dropping enough to block the nozzle in another), and that's why it's disabled. Heuristic calibration was also worse by about 40-50 microns. Since the physical system already has misalignments, adding the requirement to make the effector go to an XY position other than where the probe is, makes things worse. It introduces additional error into the system, and that error makes it harder for the correction to do its job.

I understand about it being more convenient to use a side-mount probe. I used one for many months, and I liked it at the time. My Hall-O probe mount on Thingiverse still has side-mount provisions. However, at the end of the day, it's better to use a center-mount probe. More effort to do it that way? Yeah, but there's a huge tradeoff involved. Unless the printer is moved or harshly bumped into, there should be no reason to recalibrate it. In exchange for messing with a screwdriver and a wrench for a few minutes, you get months/years of printing that's more positionally accurate than you can get with a side-mount probe. The more accurate your printer is, the easier it is to print other people's stuff, and to design your own stuff without having to add special provisions that are specific to whatever way your own printer is messed up.

These days, with a microswitch-based Z-probe that costs well under $5, I'm designing my parts with ZERO dimensional error tolerance. If I make a 20mm square hole, and a 20mm object to sit in it, they will fit perfectly. That's so much better than printing something, having it not fit because the printer's calibration is off, having to massage it to be just right, then it doesn't print right on someone else's printer, etc. Trust me, the few minutes you spend messing with a center-mount probe will pay off big time!

[campe89]

Ok, now I understand your choice to disable the G31 A with offset.

There is a way for NOT correct delta radius during G32 calibration?

[626Pilot]

G32 calibrates delta radius and endstops only. Those two variables are interrelated, so it's better to calibrate them both at the same time. The more error you take out of one, the more accurate the other one can get.

You could have G31 calibrate only one variable at a time, or you could tell it to calibrate several variables that aren't delta radius, but it wouldn't do much good. In a delta printer, all the variables work together at the same time to produce the position. When I developed the firmware, I discovered that every time I added another variable, the calibration would get better by a few tens of microns. Conversely, leaving a variable out will tend to make it a few tens of microns worse.

The one variable I recommend leaving out is arm length, which can be calibrated separately using instructions linked in my signature. Using my arm length calibration method, you can calibrate the arm length based on the actual, real-world output of the printer. That always works better for me than letting the heuristic calibration do it. Of course, it is more time-consuming, but what's a few of hours calibrating arm length compared to hundreds/thousands of hours of accurate printing?

[prophet_master]

Hello i have find a bug or problem, i have a LCD12864 and if send G31 HOQR the card crash. anyone have this problem. I use the latest firmware 626pilot

[626Pilot]

Disable the LCD. Smoothieboards don't have enough RAM to handle both the LCD and the calibration at the same time.

[skygizmo]

Hello, is this software only for calibration? or I use it as usual for printing?

Thanks magnus

[626Pilot]

If you need the Z-only correction, and most people seem to, it must be enabled during printing.

[paboman]

What is the difference between this system of calibration and the delta grid compensation in the new official Edge ?

[626Pilot]

Smoothie can now calibrate delta radius, and endstops I think (otherwise how would it do delta radius), and do a Z-only compensation (that's the "grid" part), without my firmware mod. That leaves out all the other things it could be calibrating, like tower rotation and per-tower radius offset. And arm length, if you want to use that, although I don't recommend that any longer because my dimensional accuracy calibration (see signature) is better.

The things that Smoothie edge can't do might be worth a few dozen microns of accuracy on your printer. They certainly are on the Rostock MAX v1 and MAX Metal that I've built. For that reason, I'll keep using my calibration system for the time being. Maybe Smoothie will catch up with those features in the future. Hopefully the dev team thinks they're worthwhile, but for all I know they might have the opinion that it doesn't matter.

To me, a few dozen microns definitely matter. That's the difference between parts fitting perfectly, and having to be massaged in the CAD program to be specific to whatever is misaligned with each individual printer. That's a pain in the ass, and it means your work might not be portable to another printer, even if it's the same kind you tested it with.

[626Pilot]

Calibrated the joints on my magnetic arms (carriages + effector) and got some decent results:

Code: Select all

[PD]                                    0.094
[PD]
[PD] [-0.075]    -0.075      0.000      0.044      0.019      0.019    [-0.034]
[PD]
[PD] [-0.079]     0.019      0.038      0.031      0.013      0.019    [ 0.011]
[PD]
[PD]   0.006      0.044      0.031      0.000      0.000      0.019      0.094
[PD]
[PD] [ 0.029]     0.044      0.025     -0.006      0.013      0.050    [ 0.156]
[PD]
[PD] [ 0.125]     0.019      0.000     -0.038      0.000      0.056    [ 0.189]
[PD]
[PD]                                   -0.050
[PD]
[PD] Best=0.000, worst=0.189, min=-0.079, max=0.189, mu=0.017, RMS=0.052, sigma=0.049, energy=0.040

I can't remember the last time I saw the energy at 0.04 (40 microns). Not bad for printed carriages and effector! When the Smoothieboard 2 comes out, I intend to get one. If it isn't too much hassle, I'd like to at least port the depth-mapping feature of my firmware (i.e., the above) to Smoothie 2.

[executivul]

Hi,
I know this is old, but 626pilot could you please port your code to a newer edge realease. Last year it was a major update regarding very small movement parsing and hangs which my S3D seems to generate. I run a Tevo Little Monster delta machine and the default calibration and grid does not do it for me, I have places where I'm printing in the air and other places where the 0.3mm firs layer is squished that the extruder can't print. I'm now on your fw but it doesn't have all the new stuff in it.
Thanks

[626Pilot]

Hi,
I know this is old, but 626pilot could you please port your code to a newer edge realease. Last year it was a major update regarding very small movement parsing and hangs which my S3D seems to generate. I run a Tevo Little Monster delta machine and the default calibration and grid does not do it for me, I have places where I'm printing in the air and other places where the 0.3mm firs layer is squished that the extruder can't print. I'm now on your fw but it doesn't have all the new stuff in it.
Thanks

I'll do this as time allows. I'm pretty slammed right now, so it won't be soon.

[loic]

does it inclued now in the new official branch?

[626Pilot]

does it inclued now in the new official branch?

No. It's behind the official release. I will merge in the changes when I have a chance. I moved, and haven't set up the printer yet.

[xboxhacker]

Hey Pilot

It seems you have stopped development on your branch of smoothieware. SOOOO...if I were to run your FW, get my leveling results, and save the over-ride config. Could I flash the latest version of the FW and still have the benefit of your FW, with the over-ride config? And be 100% ok?


~TIA~

[626Pilot]

No. My code is in a branch of Smoothie. None of it has been merged upstream, although I have seen some of it show up in LinearDeltaSolution.cpp (like, it's totally identical, down to the G-code letters, only difference being that some comments aren't there). Last I read, Arthur is not big on adding new delta calibration strategies, so I don't know if there will ever be a merge with upstream.

Taking a config generated with my branch and loading it into plain Smoothieware edge won't work because the logic isn't there and I think one or two G-code letters are different, so it wouldn't be guaranteed to degrade gracefully...

Anyway...

For s***s and giggles, I pulled Smoothieware edge yesterday and am rebasing my branch onto it. (In English, that means I'm "replaying" all of my branch's changes on top of the most up-to-date version.) I don't know that there's a lot of advantage in doing so, but it is fun, and if nothing else, good practice.

Fair to point out, I'm still not in a good position to set up my lab, so I have nothing to test this against.

Until that situation changes, there is no pressing need to worry about not having the latest-and-greatest Smoothieware updates. My code, though now 2+ years behind edge, is already feature-complete. The only big advantage to the rebase (aside from satisfying my curiosity and sharpening my skills) is for people who use that weird slicer that generates vast piles of nanometer-scale moves. If you're using that crap, throw it away and use KISSlicer instead. It, uh, doesn't do dumb stuff. Also it rules.