Heuristic (AI) calibration for delta printers on Smoothie

[Tonkabot]

The FSR solution is inexpensive and surprisingly accurate. It just works and there is some momentum around it and the little board makes it dead simple to implement. Will there be better solutions in the future? I hope so, but FSRs aren't horrible here and now.

What would a printer board need in order to read a value from a strain gauge? They are not very expensive at all, so you only need to read the force, A simple instrumentation amplifier board would be fine for getting the values into a high level analog signal. Does the typical printer board have ADC channels available for reading the sensors? If it does, the board needed to read the strain gauges would be dirt cheap and simple.

Once you measure the force on the arms with this method, it open up all sorts of other interesting applications. You could even tell if the print failed and abort by the resistance of the extruder pushing filament into the air. You could probably do a much faster auto calibrate by dragging the nozzle around the build plate and mapping the shape of the plate as the nozzle moves.

If the hardware were available, do you think someone would take an interest in doing the software?

I am working on a Load cell reading circuit here for a customer. A load cell is a strain gauge attached to a chunk of steel or aluminum and calibrated. This one costs $460 each. The circuit to read it is a 24 bit delta-sigma converter, with integrated [instrumentation] amplifier. That ADC chip is about 10 bucks, but it doesn't need much else to read the load cell. It reads 0-2000 Lb with better than 1Lb resolution and accuracy.

I think FSR's are a better bet for sensing the bed/nozzle contact...

The accelerometer on the head carriage would be pretty handy and could maybe do the nozzle contact sensing, and you could see how much accel the hot end actually sees zipping around - good to maybe calibrate the firmware caclulated accel numbers and also show actual jerk* which there should not be much of, unless the cpu is pausing at random times.

*jerk is the change in acceleration, mm/s^3

[626Pilot]

I pushed an update yesterday: https://github.com/626Pilot/Smoothieware

Added option to commit geometry changes AFTER all the vars are annealed, in order to allow removal of bias that might be introduced by committing after each variable type is annealed. For example, instead of "adjust endstops -> commit -> adjust delta radius -> commit", it's more like "adjust endstops -> adjust delta radius -> commit".

Added code to shuffle the order in which the variable types are annealed, in order to remove bias that might be caused by always doing them in the same order.

Moved G31's lengthy "help" printout to its own method, so it won't gobble up a bunch of stack space each time we run through G31 - even if we DON'T print help.

Rationalized the LED blinking code to use its own method, rather than hard-coding stuff inline. Additionally, we now blink LED #2 (the third LED) whenever a caltype finishes annealing.

I forgot to mention this in the commit, but I believe using a lower temperature could be beneficial if you use the option to commit changes after all vars are annealed. This is because waiting to update the robot until after they are all annealed means that they will have more error, because all of the vars will be doing their own thing with no crosstalk at all until they are all committed at the same time. (The usual way is to anneal one, commit, anneal another, commit, etc., so that each variable gets the benefit of knowing what the ones just before wound up doing.) Lowering the temperature means that each variable is not allowed to move quite as far per iteration, so that should compensate somewhat for the increased error.

I have also begun work on the code to adjust and anneal the tower lean. Nothing is functional yet, so it isn't in the latest commit. The idea is to store a unit vector representing the lean of each tower relative to the top of the tower, i.e., where the carriage is when homed. If you have a perfectly assembled printer, the unit vector will be { 0, 0, -1 }, indicating zero lean and a perfect down-vector. As most of us don't have a million dollar bot farm to build our printers with milli-degree precision, it's more likely that the vector will look similar to these made-up numbers: { 0.04, -0.053, 0.983 }

The FK/IK functions are here. There are variables like delta_tower1_x, delta_tower2_y, etc. I will replace them with functions that look like,

Code: Select all

void __attribute__ ((always_inline)) LinearDeltaSolution::getTowerXYForZ(uint8_t tower, float xy[], float z) {
    // trig goes here
}

It's not too difficult. The distance from tower-top is multiplied by the unit vector, V. The results of this multiplication (in V.x and V.y) are put into xy[], which is a float[2]. The code will always be inlined, making it basically a macro. This is time-sensitive code that is called hundreds of times per second, and we don't want to waste any clock cycles on pushing and popping a bunch of data to/from the stack.

Once that's done, I will add some code to the heuristic calibration strategy, so that it'll know how to anneal those variables. This will make the annealing process SIGNIFICANTLY slower, as we are increasing the number of variables annealed from 14 to 23 (three floats per tower for the unit vectors). However, if you don't want to anneal those vars, you don't have to.

In other news, I got an enormous chunk of granite, 4" thick and weighing about 20 pounds. It's factory certified to be within 2 micrometers, although they only seem to have tested 9 points on it. A reviewer tested it with some kind of science machine at work and discovered that his was in fact quite flat. I have been getting slightly better calibration results with it, but not enough to make me happy (which is why I feel a sudden motivation to do the tower lean code). However, the piece is so huge that it's a bit of a waste. I would like it if there was a 1" slab (maybe thinner?) certified to the same flatness. 12x14x4" is overkill for this.

[mhackney]

Some updates...

Finally back from visiting my parents in FL with my family. Now that I'm back I picked up where I left off. Firstly, today I noticed a weird thing - as my kossel probed I watched the nozzle rock back and forth about 1-2 mm in the Z tower plane! Very odd. Upon taking the arms off the carriage I discovered it was very difficult to move up and down. Odd. So I removed the carriage from the linear guide and it was smooth as silk. Long story short, I had glued some little printed stop blocks to the top of each carriage to trigger the end stop switches. This one was binding against the track! Quick fix and now I'm as smooth as silk.

I then disabled IP/telnet support to free up memory and re-ran with the 3/26 update. It made it through the calibration but was having a difficult time converging to a low (<.01) energy. I ended up just doing a simple delta calibration and then running the z height compensation. I'm printing one of my fly reels now and it seems to be doing fine. I also set up the 2 new Smoothieboards I got with the group buy and read to install one on my Rostock Max.

I ran the annealing the first time and got an energy of .03ish. I then reran and got .05 and reran a third time and got .06 - progressively worse. This is different behavior than what I saw with the previous version - perhaps a side effect of the new commit strategy?

[mhackney]

Pilot626, here's a question...

Would it be possible to run your calibration code on the PC/Mac/Linux instead of in the firmware? It would take advantage of the G30 Z probe to get the height at each probe point and then the collection of data fed into the algorithms. If this could be done, virtually any firmware would be supported to do the calibration. The output could be the various config parameters, perhaps even output in the appropriate format:

Smoothie - as the name/value pairs for config
Repetier - as the #defines for Configuration.h
Marlin - as the #defines for configuration.h

This would also allow taking advantage of the host PC and it's floating point processor and more ram and faster processor. It also removes code from the firmware that really needn't be there after calibration.

I'd be happy to help out with the host application and USB communication with the printer if you think it's feasible and/or useful.

The other advantage this might have is the code to generate the height map would also be external. The height map could be created in a firmware appropriate way (your Smoothie file for instance) or could even be used with my gcode post processor to do the compensation on the gcode itself. I think this would be a big bang for the buck as it would provide support to all delta printers using smoothie, repetier or marlin. Perhaps the code to do the Z height adjustment would be more palatable for the firmware guys to add without adding all of the data collection and processing code too.

[Nylocke]

^
|
|

This, stuck in the "dark ages" of Arduino until something wondrous happens.

[626Pilot]

I ran the annealing the first time and got an energy of .03ish. I then reran and got .05 and reran a third time and got .06 - progressively worse. This is different behavior than what I saw with the previous version - perhaps a side effect of the new commit strategy?

Hard to say. I usually type M500 after I get a good calibration. If I run it again and the calibration isn't as good, I just reboot the printer

I would like to set it up so that it automatically remembers the best calibration. The probe calibration routine already does that.

Would it be possible to run your calibration code on the PC/Mac/Linux instead of in the firmware?

If someone wants to port my code to run on a PC, it's fine with me. I've already put it in front of the guys that do Marlin and Repetier, which is as far as I will go in supporting those firmwares. I don't think either of them will pick it up.

[geneb]

How about as a MatterControl plugin?

g.

[626Pilot]

I ran the annealing the first time and got an energy of .03ish. I then reran and got .05 and reran a third time and got .06 - progressively worse. This is different behavior than what I saw with the previous version - perhaps a side effect of the new commit strategy?

The commit strategy is off unless you turn it on. I have tried several different settings for that, but none of them seems to be any good. Unless someone else pipes up and says it works better for them, I will probably remove it.

Also, there was another change - the order in which the variables is annealed is randomized each pass. I thought this would be a good way to de-bias the system, but the results I get are actually a little worse, so maybe it NEEDS that bias. Maybe there's even a better order in which to anneal, based on putting variables that are more interdependent closer together. Has anyone else messed with this? I'm thinking about getting rid of the randomizing feature as well.

[626Pilot]

I've been hard at work on a new release. I had hoped to drop it Saturday, but there is a pointer corruption issue that I need to resolve.

One thing I'm becoming more and more convinced of is that shuffling the order in which the variables are annealed hurts more than it helps. The new release will have it disabled. If you'd like to disable it without having to wait, the code in question is here: https://github.com/626Pilot/Smoothiewar ... .cpp#L1063

Every line between 1063 and 1070 (inclusive) should have a // put at the beginning, so the compiler knows to leave it alone. Save, compile, upload, done.

Stuff that has been changed in the next version:

• Preliminary work to make the kinematics aware of tower lean. (Doesn't do anything yet, so it's turned off.)
• Allow longer M665 config lines to store tower lean variables. This makes robot.cpp output M665 stuff in multiple lines if need be. (Some vars won't get read if a line is too long!)
• Migrated several 1D arrays from system RAM to AHB0.
• Migrated some 2D arrays from system RAM to AHB0, but there's a pointer corruption bug. It works with a 5x5 probing grid. With 7x7, it doesn't crash (for the first time ever, yay!) but the last few probing locations wind up pointing to zeroes (the number, not the address). wolfmanjm tells me I can use gdb to debug, so maybe I can figure out what needs to be fixed.

The new version will be published when the pointer corruption issue has been resolved. It won't have any working tower lean compensation code. I think that's probably going to take at least another week of concerted effort, and that's assuming I work on that and nothing else.

I tried using a precision-ground granite slab as a calibration surface. It actually produces worse results than the borosilicate glass. I think it may not be sitting flat enough on the PCB. If you want to bother with something like this, it might be better to dismount the PCB and put it directly on the snowflake.

[TFMike]

Hey 626Pilot, I saw your post over here in this thread: http://forum.seemecnc.com/viewtopic.php ... 820#p57820

and it got my gears turning. I recently came upon a bunch of strong metal beams for cheap (FREE!) from an office depot that is merging with the office max across the street and I wanted to try my hand at building a GIANT delta (like 18inch tempered glass build plate giant) but I wanted to do it on the cheap. Would I be able to use one of these and your firmware to have an auto calibrated giant delta? Please say yes:

http://www.aliexpress.com/item/32-bit-A ... 51240.html

"If you use a Smoothieboard (or Azteeg X5 or other clone) you can run my auto-calibration firmware. It uses a machine learning algorithm to figure out the true dimensions of the printer (arm length, endstops, delta radius, tower radius and angle offsets, and surface normal), producing improved dimensional accuracy on all axes. If enough slop is left over to impede 1st layer adhesion, the firmware can also depth-map the bed and use this to continuously adjust Z as a function of the bed surface.

This requires a Z-probing apparatus. If an effector-mounted probe is to be used, it must be mounted dead center. Bed leveling and geometry adjustment data is stored to the SD card, so you don't have to re-run the calibration unless the printer is moved."

[Nylocke]

Theres 2 ways you really don't want to skimp out on your printer, #1 is the hotend, and #2 is the controller.

[TFMike]

Theres 2 ways you really don't want to skimp out on your printer, #1 is the hotend, and #2 is the controller.

I already have quality hotends laying around, and he did say CLONES could work, so would that be a viable option?

[Nylocke]

Its just a general rule of thumb. I would recommend just getting a genuine smoothie board from the US distributor. The X5 Mini is okay, but Pilot will tell you about the lack of reliability he experienced with those.

[TFMike]

Its just a general rule of thumb. I would recommend just getting a genuine smoothie board from the US distributor. The X5 Mini is okay, but Pilot will tell you about the lack of reliability he experienced with those.

alright well shit, ok. Off I go to spend 180 or whatever it is. Am I mistaken in thinking that the smoothieboard needs me to put new fuses on it plus there is an issue with 12 and 24v? I recall someone complaining about their SSR blowing up.

EDIT: Also, am I pretty much guaranteed that the 626pilot firmware combined with my steel framed giant delta will allow me to print on a giant piece of glass with limited troubles should I get a genuine smoothie or azteeg?

[Nylocke]

If you're only doing a single extruder system you can get one for as low as $120. I'm not aware of the fuse thing or the issue with 24V? From http://smoothieware.org/smoothieboard

Main 12-24V ( Stepper drivers ) power can be connected using a 3.5mm or 5mm screw terminal, SMT power jack connector, or a Molex connector ( ATX-harddrive style )

Up to 3 SMT ZXMN4A06 ( 5A, up to 24V ) Mosfets sharing a power circuit
Up to three thru-hole ( AOT240L : 12A, up to 24V ) Mosfets sharing a power circuit

It is designed to be used as a very diverse CNC controller after all.

Assuming your frame and carriage to effector connections are right it should be alright.

[626Pilot]

I don't even know if that can RUN Smoothie. If it has "ramps" in the title it's probably an Arduino controller. They may just be throwing names of stuff out there to try to get traffic. Also, it has no stepper drivers. You would have to buy them sepearately at $15-20 each. In other words, you save money now in order to have to spend more money later. Doesn't make sense to me.

Just get a Smoothieboard.

[TFMike]

Just get a Smoothieboard.

Pulled the trigger on an azteeg mini x5 as I didn't wanna mess with soldering. Will this suffice?

[626Pilot]

Smoothieboards don't require soldering unless you want to run them without USB power. I actually prefer not to. I can turn off the main power but not have it disconnect from Repetier.

I went through two Azteeg X5 Minis in less than six months. Other people seem to do fine with them.

[TFMike]

Smoothieboards don't require soldering unless you want to run them without USB power. I actually prefer not to. I can turn off the main power but not have it disconnect from Repetier.

I went through two Azteeg X5 Minis in less than six months. Other people seem to do fine with them.

Time will tell I guess, thanks for the help

EDIT: By the way, Tom C/stonewater seemed concerned and wanted to get your input on this: http://forum.seemecnc.com/viewtopic.php ... 013#p67986

[mhackney]

Well, if you want to connect the display to smoothie, you do need to solder the pins onto the board. You used to have to solder the maximum endstop pins on too but the two I just got were all set with that. You also used to have to solder the ethernet connector but that was pre-soldered on these new boards also.

[626Pilot]

EDIT: By the way, Tom C/stonewater seemed concerned and wanted to get your input on this: http://forum.seemecnc.com/viewtopic.php ... 013#p67986

Either he downloaded the v5 mount by mistake, or E3D shipped him and me hot ends with different mounting profiles.

[miglo]

Anyone running this on their max 2 please share their config file?

Im assuming the alpha_steps_per_mm is 80 for the max 2?

[forrie]

kiiwii posted this...

http://forum.seemecnc.com/viewtopic.php ... 111#p67939

Haven't tested it though yet.

[miglo]

I think I finally have this board kinda working with the FSRs.

G29 causes the head to repeatedly crash into the bed though. I can see it trigger the FSRs as its red as the head continually pounds and scrapes the bed. Any other way for me to check to see if my hits are not registering with the board??

EDIT: NVM solved it

[miglo]

Do you guys think there is something fundamentally wrong with my printer? I resquared, retightended etc etc but I can't seem to get the energy below .06. I've rang G31 OPQRS a bunch of times now, and it still pretty much all over the map.

Heres the latest run:

<-[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: 269.663
<-[PK] Delta radius: 128.317
<-[PK] Endstop offsets: {-0.006, 0.000, -0.014}
<-[PK] Radius offsets (ABC): {0.000, 1.729, 1.729}
<-[PK] Angle offsets (DEF): {-2.221, -2.912, -2.998}
<-[PK] Virtual shimming: {1.249, 0.660, 0.045}, vector={0.005, 0.006, 1.000}, d=-0.651, Enabled
<-[PK] Depth (Z) correction: Disabled
<-[PR] Priming probe 1 times.
<-[DM] Depth to bed surface at center: 344 steps (0.000 mm)
->M105

->M105

<-[PD] 0.312
<-[PD]
<-[PD] [ 0.000] -0.050 -0.025 0.125 [ 0.000]
<-[PD]
<-[PD] 0.138 0.050 0.000 0.062 0.363
<-[PD]
<-[PD] [ 0.000] 0.125 0.138 0.175 [ 0.000]
<-[PD]
<-[PD] 0.125
<-[PD] Best=0.000, worst=0.363, min=-0.050, max=0.363, mu=0.062, sigma=0.102, energy=0.141
<-[HC] Generating carriage positions for a printer with this configuration.
<-
<-[HC] Starting test configuration: Arm Length=269.663, Delta Radius=128.317
<-
<-[HC] ***** Simulated annealing pass 1 of 1 in progress *****
<-[HC] Existing calibration has energy 0.141
<-
<-[HC] Reticulating splines...
<-[HC] Try 0 of 50, energy=0.085 (want <= 0.010)
<-[HC] Try 5 of 50, energy=0.091 (want <= 0.010)
<-[HC] Try 10 of 50, energy=0.112 (want <= 0.010)
<-[HC] Try 15 of 50, energy=0.092 (want <= 0.010)
<-[HC] Try 20 of 50, energy=0.088 (want <= 0.010)
->M105

<-[HC] Try 25 of 50, energy=0.083 (want <= 0.010)
<-[HC] Annealing has stalled - aborting.
<-
<-[HC] End of annealing pass (energy=0.083)
<-[HC]
<-[HC] Heuristic calibration complete (energy=0.083). Final settings:
<-[PK] Arm length: 269.941
<-[PK] Delta radius: 128.396
<-[PK] Endstop offsets: {-0.044, 0.000, -0.115}
<-[PK] Radius offsets (ABC): {0.000, 1.651, 1.651}
<-[PK] Angle offsets (DEF): {-2.175, -2.961, -3.003}
<-[PK] Virtual shimming: {1.154, 0.658, -0.021}, vector={0.005, 0.006, 1.000}, d=-0.597, Enabled
<-[PK] Depth (Z) correction: Disabled
<-
<-[HC] Final SIMULATED depths:
<-[PD] 0.289
<-[PD]
<-[PD] [ 0.000] -0.040 -0.087 0.007 [ 0.000]
<-[PD]
<-[PD] 0.182 0.013 0.000 -0.096 0.173
<-[PD]
<-[PD] [ 0.000] 0.043 -0.009 -0.019 [ 0.000]
<-[PD]
<-[PD] -0.040
<-[PD] Best=0.000, worst=0.289, min=-0.096, max=0.289, mu=0.017, sigma=0.081, energy=0.083
<-
<-[HC] You can run this command again to see if it gets better, or type M500 to save.