Auto-Calibration - $100 Bounty and Bragging Rights

[Broose]

There are no settings for you to tell it the offset to the probe, so it assumes the probe is exactly at the nozzle. My probe is a good 50mm from the nozzle. What a pain :/

Shouldn't "G30 Znnn" handle the probe offset on Smoothie? It works a little differently from Marlin.

I think he meant X and Y offset, not Z offset. In other words, the probe is off to the side of the nozzle.

Oh, in that case, I agree. I should have read his Smoothieware post. With the E3d hot end, I can't get the probe that close to the center point (though its closer than 50mm), and the FSR solution seems a little problematic with a heated bed.

I saw one guy on the Google forum developed a printable probe that snaps onto the hotend which would eliminate the X/Y offset problem, but I'd hate to see what happens when its snapped on if the hotend is still hot.

[626Pilot]

I'm going through ZProbe.cpp now and adding some code to handle the offset. The solution is fairly simple: move the probe to position+offset instead of position. However, there is step-counting going on, and that's where it gets tricky.

This is the tactic I'm using:

Code: Select all

    // FIXME: Experimental offset/coordination code begins here
    // home
    home();

    // find bed, run at fast rate
    int s_alpha;        // Number of steps moved down from home position to probe_height
    int s_beta;         // Number of steps moved down from <probe_offset_x, probe_offset_y, probe_height> to surface
    int s;              // Number of total steps from the top endstops to the surface at probe offset
    int s_prime;        // Number of steps before we correct it
    
    // Move to a position at <0, 0, probe_height>, and save how many Z-steps we are from the top
    coordinated_move(NAN, NAN, probe_height, this->fast_feedrate);
    s_alpha = STEPPER[Z_AXIS]->get_stepped();
    
    // Move to a position above the place to test, and save how many steps we are from the top
    coordinated_move(probe_offset_x, probe_offset_y, NAN, this->fast_feedrate);
    s_beta = STEPPER[Z_AXIS]->get_stepped();

    // Find the bed surface
    if(!run_probe(s, true)) return false;
    s_prime = s;

    // Compensate for Z axis motion due to moving from bed center to probe offsets
    if(s_alpha > s_beta) {
        // Z carriage moved up after we moved from bed center to offset position.
        // This means Z's step counter will be smaller (higher elevation) by that amount.
        // Therefore, calculate steps lost from Z moving up, and add to the total steps. 
        s += s_alpha - s_beta;
    } else if(s_alpha < s_beta) {
        // Z carriage moved down after we moved from bed center to offset position.
        // This means Z's step counter will be larger (lower elevation) by that amount.
        // Therefore, calculate steps gained from Z moving down, and subtract from total.
        s -= s_beta - s_alpha;
    }
    gcode->stream->printf("Compensation: alpha=%d, beta=%d, s before=%d, s after=%d\n", s_alpha, s_beta, s_prime, s);

    // Old code: Assume probe height = height at which probe triggers.
    // float bedht= s/Z_STEPS_PER_MM - this->probe_height; // distance to move from home to 5mm above bed

    // New code: Assume that we _start_ probing downward from probe_height, and _trigger_ at probe_offset_z.
    float bedht= s/Z_STEPS_PER_MM - this->probe_offset_z;

    gcode->stream->printf("Bed ht is %f mm\n", bedht);

It doesn't work properly yet. get_stepped() is returning numbers like 11 and 7 when it should be returning numbers like 500 and 1000. I think I'm calling the method wrong or something.

No one answered the thread I posted on the Smoothie forums yet, but I don't think they get much use. Most of the activity seems to be in an IRC channel.

[626Pilot]

Got on IRC and talked to wolfmanjm. He's the one who did those diagrams of error on delta printers, and he seems to be in charge of Smoothieware. I figured out that the code above wouldn't work because get_stepped() should actually be called get_steps_remaining(). I redid the math to use the robot's reported axis positions instead, and it worked. However, the calibration is just as bad as it was before, and in exactly the same way.

Good news: wolfmanjm pointed me at this branch that does something like my tower rotation fix, but automated: https://github.com/wolfmanjm/Smoothie/t ... er-offsets

If you have a controller that will run Smoothieware, please give that a try and let me know. wjm said it worked for the guy who wrote it, but would never get close enough to a solution to resolve on his machine. I compiled and installed it and ran Rich C's calibration (G31 instead of G32) and it was slightly better, but still off. (Also it took 20 minutes to iterate through all the tests!) I will try porting my probe offset logic to Rich's algorithm and see if that helps.

[Broose]

Good news: wolfmanjm pointed me at this branch that does something like my tower rotation fix, but automated: https://github.com/wolfmanjm/Smoothie/t ... er-offsets

If you have a controller that will run Smoothieware, please give that a try and let me know.

I swapped out wolfmanjm's firmware.bin above on my mini Kossel and with a G32 it tried to probe outside the work envelope, apparently ignoring the J-code I had to set the radius to 85mm. What is Rich C.'s G31? Is that different from the touchprobe commands listed on the smoothieware site?

[626Pilot]

G32 will level the towers and adjust delta radius. G31 does what G32 does, and it will run a calibration which probes all towers and tower opposites (like a six-pointed star) and tries to make everything converge at once. It attempts to adjust delta radius, tower angle, and arm length all at once. As adjusting multiple variables at once is very tricky, sometimes it converges on a solution and sometimes it doesn't. I'm currently working on the code to see if I can improve it.

It may not be enough to fix outside-the-triangle errors. I theorize that the most likely way to do this is to have the probe walk as much of the print surface as possible, create a heightmap, and use that to throttle filament extrusion speed. Z=0 would be at the minimum elevation detected, i.e. the lowest point on the bed, and the robot would silently correct positions between the min and max probed heights by making Z=0 be wherever that elevation really is on the surface. (So if you start at the lowest point and move across the surface, the robot silently corrects by raising the effector.) If the extruder is running, it will be throttled proportional to elevation. If you extrude at the lowest elevation you get full specified flow, but if you extrude at the highest elevation it doesn't extrude at all.

[lordbinky]

Arg... Since they reworked all forum access (ie if it mentions forum in the address it's blocked) I missed that post that wolfmanjm did the marlin implementation of the tower calibration.... and I noticed it just after I just posted I was about to finish up the exact same thing tonight. *sigh* Testing it out right now to see if it works so I can just go to testing my methods since I don't agree with all of Rich C's methodology (which doesn't mean much since I could just be missing something important of course).

[lordbinky]

And I tried that version and I don't like it, I'm going to just finish mine out, post it, and at least know it works for me lol.

[626Pilot]

I've been working on that code for awhile. I don't think it's likely to work on all printers, although it might magically work on the one it was developed on. For me and wolfmanjm, it tends to get slightly closer to a solution at first, but then it just diverges more and more with each pass. I can watch the "bed center" migrating to the right, across X+.

The problem, as I see it, is that they attempt to calibrate delta radius, arm length, and tower angle all at the same time. In other words, it can change up to nine variables at the same time (three kinds of adjustment times three towers). If you tweak nine variables at once in a decidedly non-linear system, how do you know the proportion of the change each one is responsible for? It tries to use some heuristics, but those heuristics don't know the difference between the author's printer and mine, and whatever specific stuff is going on with his printer may be more amenable to these algorithms than mine.

I think the solution is to break down the calibration into discrete steps, where you test only one tower at a time (or at least you only change one kind of variable at a time, which the endstop leveling code already does fairly well.)
- Level endstops (code's already there)
- Calculate delta radius (code's already there)
- Do my laborious tower angle adjustment (needs to be written)
- Skip the individual tower radius delta (adjusting this by hand leads to prints that slant off to the side, so why bother)
- Skip the arm length adjustment, at least for now

At that point, the geometry of the printer should be dialed in "good enough" to print inside the triangle. To fix the outside of the triangle, another step has to be added:
- Walk the print surface with the probe, generating a height map, and use this to silently adjust both position and filament flow when Z is within the min height to max height envelope (1st layer or so)

If anyone has suggestions on improving this, I'm all ears.

[Flateric]

I mounted my probe on a spare magnetic hotend exactly where the hotend tip would be.

This allows a more difficult setup since you have to make 2 effectors that match exactly.

Not sure why mine appeared to work so well, Perhaps my starting value were really close already or accurate from the get go?

[snoman002]

I think the 6 point star is insufficient to develop enough of a calibration routine. Perhaps a 13 point routine could help, center and 2 six point stars with one halfway between the outside star and the centerpoint.

The height above the bed for the inside star compared to the vales for center and outside star should help narrow down the variables.

[BONE]

New here, so I've only skimmed over this thread so far, but has this been discussed?

https://www.youtube.com/watch?v=HcnhCNh ... Wg&index=1

[JohnStack]

Of course there is this.

Not a new idea - measuring based on lasers and images captured from them; however here goes:

http://3dprint.com/9952/mit-researchers ... d-printer/

[626Pilot]

Hi, thread! How are you doing? Long time, no see.

I fixed the autocalibration problem with simulated annealing: https://github.com/626Pilot/Smoothieware

This doesn't meet the bounty conditions, but I'll tell you one thing: As far as I've been told, it works for everyone who has tried it. Positional accuracy is greatly improved, first by adjusting printer settings to correct for errors in X, Y, and Z; and then a final Z correction is added by depth-mapping the print surface in a grid.

You have to have a Smoothieware-compatible board (Azteeg X5 Mini or Smoothieboard 5X). So, it's not under $100. You also need a Z-probe, so it won't work if all you have is a dial gauge. (However, the Z correction can be hacked to work by manually editing the file where it stores the depths.)

It was always my hope that this would be ported to the Arduino controllers. I just posted to the deltabots group, asking Rich Cattell if he wants to port it to Marlin. Maybe someone can talk to whoever maintains Repetier.

[mhackney]

I'll grab that to try on my smoothie-equipped Mini Kossel. I'm waiting for the group buy details to pick up another couple of smoothies, 1 for the Rostock.

[gmh5760]

Pretty new to this stuff (only have a few prints under by belt), but what about monitoring the current to the stepper motors? The second they meet resistance (nozzle contacting the bed) the current to the steppers would rise. Would just have to program the variables such as current deflection requirements, distance ABOVE current deflection in which to call it "Z=0" (first layer base height), and then following calculation procedure (stepper motor current deflection point minus desired first layer base height, say 0.003", the steppers could then reverse travel to limits to "verify" Z. Could maybe utilize the same process (more trig) to calculate bed curvature).

[626Pilot]

Pretty new to this stuff (only have a few prints under by belt), but what about monitoring the current to the stepper motors? The second they meet resistance (nozzle contacting the bed) the current to the steppers would rise. Would just have to program the variables such as current deflection requirements, distance ABOVE current deflection in which to call it "Z=0" (first layer base height), and then following calculation procedure (stepper motor current deflection point minus desired first layer base height, say 0.003", the steppers could then reverse travel to limits to "verify" Z. Could maybe utilize the same process (more trig) to calculate bed curvature).

Some stepper drivers have missed-step detection. I don't know if any commonly available control boards actually plumb that into the controller's I/O lines.