Auto-Calibration - $100 Bounty and Bragging Rights

[lordbinky]

If I had an Ideal setup, I would have a Rambo running whatever firmware I was working on and have it's outputs interfaced back into the computer so I can have the Rambo controlling a modeled Delta printer. Allowing you to trigger sensors in a simulation using the actual electronics, with recorded definite results could speed up development and you can find any weird nuances with the electronics and algorithm processing quirks. Decoupling the process from a full setup would also let you test hypothetical sensor inputs without fully developing them too.

[Demolishun]

I wonder if it could be done with Processing:
http://processing.org/

[Flavored Coffee]

It's an Arduino Mega2560 board, only altered slightly to power power transistors on the same board. They're only using two of analog inputs for thermisters. So, you could per say, mechanically adjust a switch via a screw, and when the print head touches the glass, you crank the screw until the switch closes. Or, you can use an infrared diode, and place is right next to an infrared sensor, calibrate it once, and store the value of light measured. Autocalibration, and mechanical calibration, go hand in hand. Auto, can only work when the mechanical has been but, it's really easy. You just look analog read of the resistance of the infrared sensing diode, and that will be the same. It's just a matter of programming the board to respond to that reflection. If you put something in front of it, it will auto calibrate to that reflection's brightness. It won't collide if you left something on the print plate but, it might try printing on top of it.

You can go here and count how many analog inputs that they're not using in the Rambo.

http://store.arduino.cc/index.php?main_ ... cts_id=196

There's 16.

You could add three silicon self stick buttons to the cold side of the hot end, and put this pressure sensing resistor on the other side of one of the silicon pads. When the tip, touches the print surface, no matter what the reflectivity, it will increase the amount of pressure on the sensor beyond normal, which, is just the mounting force of the screws. Other than that, a program for the processor to calibrate zero.

http://store.linksprite.com/force-sensi ... tor-small/

The smallest amount of change the Arduino board can detect, would be it's cue to knowing it touched something. It also means more wires going to the print head. Just that one sensor could do allot during printing. If it bumps the print project, it would know to stop printing. If the resistance went high, it would know to stop the extruder and turn off the hot end, and print bed. Stuff, wouldn't be left cooking, or just turn into a big mess. I've seen some pictures of a hot end, that overheated, wrecked the bowden tube, clogged, and then ruptured the hot end. Any change in resistance would indicate, the hot end malfunctioned. There would be a small amount of change in pressure just due to thermal expansion, and you'd want Arduino, to ignore the small changes over time but, never a sudden change.

[Flateric]

It appears that the current version of smoothieware does do both z-height calibration for each tower and also delta radius adjustment for you as well. I have not used it myself yet. But here is a link to the process and description of how it proceeds.

http://smoothieware.org/zprobe

Sounds like it makes multiple tests of each through 3 passes and then you simply write the data out to the firmware with a gcode command.

I may be able to test this later this evening to see how good it is and how well it works.

[626Pilot]

It appears that the current version of smoothieware does do both z-height calibration for each tower and also delta radius adjustment for you as well. I have not used it myself yet. But here is a link to the process and description of how it proceeds.

http://smoothieware.org/zprobe

Sounds like it makes multiple tests of each through 3 passes and then you simply write the data out to the firmware with a gcode command.

I may be able to test this later this evening to see how good it is and how well it works.

I tried it. It doesn't work very well. 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 :/

The calibration does a three-point test over and over again until it gets Z values within 30 microns of each other. It calibrates the tower offsets (like turning endstop screws) as well as the printer radius. It doesn't do that test where it walks all over the print surface, which is too bad, but maybe if they'd let us supply an offset for the probe it would work properly. The firmware also has a feature to automatically turn on the fan above a certain temperature, which I like a lot, although it seems buggy. I posted a thread about the Z probe issue here: http://smoothieware.org/forum/t-920408/ ... t-settings

This is on an Azteeg X5. It costs about $50 less than a RAMBo, runs at 120MHz, has something like 64K RAM... so while the firmware is a bit rough around the edges, this is a platform with a FAR better price:performance ratio than anything Atmel has to offer, and it will provide a lot of room for growth. I'm never buying another stupid Arduino controller again.

[Jimustanguitar]

626, are you seeing the geometry error that we're chasing with the Smoothie also? That's a shame, part of me was hoping that it was an error caused by lack of processing power :/

[RegB]

Captain Starfish, it's not that your bed looks like a golf course. It's that the path of the nozzle above a perfectly flat and level bed can travel in a non-planar surface if your machine is not mechanically perfect - tower position, tower leans, arm length, delta radius, etc. You can either fix all the mechanical problems (preferred but sometimes difficult) or compensate for them in software. For instance, I had an issue with my Z tower when I first assembled my Max last year. The symptom was that the nozzle would raise above the bed when it was between the Z and X towers but traveled in a pretty good plane everywhere else. This created problems putting the first layer down since the nozzle rose above the bed at that position and was too far to get adhesion of the plastic bead. (the problem I described is greatly simplified, the movement was "odder" than that but you get the point). In my case, my Z tower was leaning ever so slightly toward the X. Turns out that the opposite effect was happening on the other side, the nozzle would get too close to the bed. I spent a couple of days tweaking until I got that out. I know that my effector movement is not *exactly* planar now and it actually changes day to day. Maybe heat and humidity affect the tower positions/lean or something. But it is usually good enough. The sort of calibration we are talking about has 2 components:

1) actual calibration - by taking a series of measurements at strategic spots over the bed, the delta arm length and delta radius can be determined. Test, compare, repeat until you are within some small margin. The strategic spots are at the center and at the base of the towers.

2) movement compensation - once the delta parameters are calibrated, if there is any non-planarity in the nozzle movement other mechanical issues are at fault (tower lean, non parallel delta arms, etc). Most of the time these are within reasonable limits but even a slight variation, along with daily changes described above, can cause enough variation to cause problems getting the first layer to stick well - especially over large areas (i.e. large parts). So, the compensation takes many measurements on a grid (there are other ways to do this) say at 1cm increments and creates a topographic map in Z. This is NOT a map of the bed. It IS a map of the nozzle/effector movement. With this map, you can add or subtract the ∆Z from the known actual Z (which by default could be at X=Y=0). Now, when printing, when the nozzle is at a give X, Y position, the firmware can check to see what the ∆Z is and compensate for it. The simple approach is to just use the same ∆Z for all points within a square cm, a better approach is to extrapolate between neighboring grid points. The simple case works surprisingly well since we are just trying to tweak out very small (<1mm for sure, .5mm if possible) non-planarities.

Interestingly, you could actually do 2 above in gcode. If you had the topo map of ∆Zs you could post process the gcode and insert explicit Z movements for every X, Y movement. I've done simple tests doing this and it works pretty well.

Oh Ohh,,,
The suggestion that heat and humidity may affect alignment is kinda scary (to THIS newbie).
My kit MIGHT be here tomorrow, so in light of what I know about the sensitivity of pianos to humidity changes I'm wondering if the FIRST task should be to SEAL all melamine edges.
I think Melamine's core is wood fiber based... BICBW.
The fibers may all be sealed by being mixed with whatever glues are in the mix anyway.
OTOH, if those are not waterproof glues it could still be worth sealing the edges.

Did Gene's orange machine get some benefit other than cosmetic from being painted ?
Where "cosmetic benefit" is a value judgement (-:

[geneb]

Thou shalt not dis Orange Menace.

I suspect the edges of the material are sealed as a side effect of the laser cutting process.

g.

[Jimustanguitar]

The suggestion that heat and humidity may affect alignment is kinda scary (to THIS newbie).

Heat and humidity affect everything. There's also gravity and friction at play The Universe is built on entropy.
An entertaining story I heard about this involved the guys who drafted the very first military helicopter plans by hand in the 40's and 50's. Supposedly, paper and ink would shift too much and cause problems with the final design, so they scribed their plans on aluminum sheets with a scratch awl because it wouldn't suffer from thermal shift as badly.

You'll be fine. Most of these sorts of conversations are about splitting hairs that most people wouldn't notice or would consider negligible. It's an insanity that you can take your time growing into

[Eaglezsoar]

The suggestion that heat and humidity may affect alignment is kinda scary (to THIS newbie).

Heat and humidity affect everything. There's also gravity and friction at play The Universe is built on entropy.
An entertaining story I heard about this involved the guys who drafted the very first military helicopter plans by hand in the 40's and 50's. Supposedly, paper and ink would shift too much and cause problems with the final design, so they scribed their plans on aluminum sheets with a scratch awl because it wouldn't suffer from thermal shift as badly.

You'll be fine. Most of these sorts of conversations are about splitting hairs that most people wouldn't notice or would consider negligible. It's an insanity that you can take your time growing into

Well said, Jim.

[626Pilot]

626, are you seeing the geometry error that we're chasing with the Smoothie also? That's a shame, part of me was hoping that it was an error caused by lack of processing power :/

Hard to say without a working bed leveling algorithm. I am impressed that it takes only two arguments - delta radius and arm length - and calculates the bed radius based on that using a Z probe, out to four decimal places. (Of which perhaps three are good - my probe isn't that repeatable.)

I also notice it leaves the extruder stepper on after a print. I can hear it emitting noise. I'm thinking about modifying the firmware to support a probe offset, since it's relatively simple. I might fix that too if I can figure out how.

[JohnStack]

There are a number of new principles that we must consider.

https://www.youtube.com/watch?v=rLDgQg6bq7o

[RegB]

The suggestion that heat and humidity may affect alignment is kinda scary (to THIS newbie).

Heat and humidity affect everything. There's also gravity and friction at play The Universe is built on entropy.
An entertaining story I heard about this involved the guys who drafted the very first military helicopter plans by hand in the 40's and 50's. Supposedly, paper and ink would shift too much and cause problems with the final design, so they scribed their plans on aluminum sheets with a scratch awl because it wouldn't suffer from thermal shift as badly.

You'll be fine. Most of these sorts of conversations are about splitting hairs that most people wouldn't notice or would consider negligible. It's an insanity that you can take your time growing into

Well said, Jim.

No doubt it does, but reading elsewhere about Melamine suggests that it is a good thing to seal all edges ANYWAY.
I'll probably do it for peace of mind later on, say August when the humidity is UP and again 6 months later.
If I don't it will just NAG at me every time I'm trying to troubleshoot - and/or hear a piano that BADLY needs to be tuned.
Humidity is NOT a good variable for wooden things.

This isn't the sort of thing that will cause "harm", other than wasting time and materials.

n'ths of ten'ths of a gnat's hair ?
Yep, this sounds like my kinda pastime.

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

Here is what it says in smoothieware.org/zprobe:
"G30 Znnn will probe until it hits the bed then sets Z to nnn, this can be used to set the nozzle height if nnn is the probes Z offset from the nozzle"

I tried it and it seems to work, though if you home afterwards it loses the offset.

[dtgriscom]

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.

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