Source: https://github.com/626Pilot/Smoothieware" onclick="window.open(this.href);return false;
Firmware download: https://github.com/626Pilot/Smoothiewar ... rmware.bin" onclick="window.open(this.href);return false;
Instructions: https://github.com/626Pilot/Smoothiewar ... DME.creole" onclick="window.open(this.href);return false;
CONFIG OPTIONS HAVE CHANGED!
Please see this post. You will need to add a line to your config if it isn't already there, and there are other options that have been renamed or added.
OLD VERSIONS
Old versions of the firmware are available here: https://github.com/626Pilot/Smoothiewar ... rmware.bin" onclick="window.open(this.href);return false;
The commits from 626Pilot are mine. The ones from Jim Morris are not part of my fork, and won't have any of my code. For example, if you scroll to Sept. 19, you'll see a commit from 626Pilot (me) titled "Updating firmware.bin with support for tower scaling." Click that text. Then you'll see "BIN [][][][][] FirmwareBin/firmware.bin" - click View. On the next page, right-click Raw and then save-as.
WHAT FOLLOWS IS LEFT FOR POSTERITY - YOU'RE BETTER OFF READING THE INSTRUCTIONS AT THE LINK ABOVE!
As discussed in this thread, I started working on a heuristic tuning system to get our printers calibrated as best as possible in the summer of 2014. At first, I tried some hard-coded logic to try to tweak the parameters based on hard-coded rules. That was based on code someone had written for Marlin. I could never get it to do much, and it was more likely to get worse and worse with each iteration until finally it got so bad I'd have to turn the printer off.
As summer passed into fall, I started reading up on heuristics so that I could figure out whether there might be a way to let the machine figure out what I couldn't. I found a method called simulated annealing. The algorithm is basically a physics simulator that models annealing, in which metallurgists get atoms of metal to form extremely strong matrices by carefully cooling the metal in steps. SA is one of the fundamental algorithms used in machine intelligence. When you hear about a supercomputer that fills an entire data center running thousands of processors in parallel, there's a good chance that some of those CPUs are running SA algorithms often, if not constantly. SA is a form of machine intelligence that allows computers to solve problems that they have no fundamental understanding of. Some reasonable constraints (which variables, what ranges those variables can be in, etc.) have to be supplied, but aside from those constraints, the algorithm doesn't have to know the nature of what system it's trying to solve.
On the forums, you can find all sorts of advice like, "If the effector is too high next to Z but too low opposite Z, you have to loosen the Z endstop screw." The SA algorithm doesn't actually know that. It doesn't know the relationship between endstops, arm length, delta radius, individual tower offsets, or the surface normal of the build platform. However, because I've given it the ability to simulate different configurations (a "virtual delta printer"), it has the ability to slowly "creep" all 14 variables in the right direction, simultaneously. It can wander through less-optimal configurations on its way to more-optimal configurations, so it has some ability to find its way out of "blind alleys" on its way to better solutions. The particular algorithm I implemented is technically parallel simulated annealing, as each variable can have its own "temperature."
These are the 14 variables the algorithm can adjust:
- Delta radius
- Arm length
- Endstops
- Tower rotation offsets
- Tower radius offsets
- Surface normal (how perpendicular the towers are to the print surface)
- Probe calibration - lets you adjust the probe's settings. Priming (running the probe several times before measuring), smoothing (probing several times and averaging the result), and smooth acceleration/deceleration can all be adjusted.
- Iterative calibration (like Gene B's method - adjust delta radius and endstops at the same time). Both variables are converged simultaneously, usually after a few probing cycles.
- Depth map-based Z correction - maps the print surface in a grid. Using bilinear interpolation and extrapolation, any positioning errors in Z not corrected by the simulated annealing can be smoothed out. The grid is 5x5, but in the future I'd like to enlarge it to 7x7 or even more, as that would be smoother. I think I need to migrate the bilinear interpolation array to AHB0 (esoteric memory thing on the ARM processor) first.
Simulated annealing corrects for errors in X, Y and Z. This should get anyone's delta printer closer to optimal. The depth-map based Z correction will take out enough of whatever error remains, that your printer's positioning on the Z axis should be within 20-30 microns of perfection - and often better than that. X and Y will be more accurate as well.
Building and Installing
NOTE: You don't have to do this section anymore unless you want to! You can just download firmware.bin from GitHub and put it on your SD card.
You'll need to take one of the example config files out of ConfigSamples/*.delta and adjust it to your printer.
I don't know how the heck the FirmwareBin directory works. I tried copying a fresh .bin in there, but when I tried flashing it, it had none of the features I added, so until I figure that out you have to build it yourself. The following commands work in bash (Linux). If you have Windows or Mac... figure it out. Hey, I'm working for free here!
You'll need to install dfu-util first. It should be in your distribution's repo (software source).
Code: Select all
git clone https://github.com/626Pilot/Smoothieware.git
cd Smoothieware
sh linux_install (or mac_install)
sh BuildShell
make all
Code: Select all
make upload
If you don't want to mess with dfu-util, you can copy LPC1768/main.bin to your printer's SD card. Rename it to firmware.bin, safely eject/disconnect the card, and then power-cycle the printer. Whether you use dfu-util (make upload) or copy by hand, when the printer reboots, you should see the LEDs slowly counting in binary for a few seconds before strobing as usual. That's how you know the firmware got flashed.[/s]
Using
The recommended way to use this on a Delta printer is:
G29 (calibrate your probe - run this, adjusting the parameters each time until you get a good result)
G32 (iterative calibration - gets endstops/delta radius correct - K to keep, but don't use that if you want to run G31 afterwards)
G31 O P Q R S (simulated annealing - corrects for errors in X, Y, and Z - it may help to run this multiple times)
G31 A (depth mapping - corrects errors in Z, but not X or Y - benefits from simulated annealing, though)
G31 Z (depth map and print results - here is where you should see a lot of improvement!)
Remember to type M500 to save your configuration. Otherwise, your printer will forget everything it did the next time it's powered off!
Results
Here are the bed depths measured without any calibration at all, measured by typing G31 Z:
Code: Select all
[PD] 0.403
[PD]
[PD] [ 0.000] 0.253 -0.028 -0.272 [ 0.000]
[PD]
[PD] 0.563 0.169 0.000 -0.244 -0.169
[PD]
[PD] [ 0.000] 0.103 -0.075 -0.141 [ 0.000]
[PD]
[PD] -0.122
[PD] Best=0.000, worst=0.563, min=-0.272, max=0.563, mu=0.018, sigma=0.176, energy=0.212
Code: Select all
[PD] 0.253
[PD]
[PD] [ 0.000] -0.084 -0.084 -0.056 [ 0.000]
[PD]
[PD] 0.028 -0.094 0.000 0.047 0.403
[PD]
[PD] [ 0.000] -0.084 0.038 0.216 [ 0.000]
[PD]
[PD] 0.075
[PD] Best=0.000, worst=0.403, min=-0.094, max=0.403, mu=0.026, sigma=0.109, energy=0.122
Code: Select all
[PD] -0.019
[PD]
[PD] [ 0.000] 0.019 -0.009 -0.028 [ 0.000]
[PD]
[PD] 0.000 0.009 0.000 -0.009 0.009
[PD]
[PD] [ 0.000] 0.009 0.000 -0.038 [ 0.000]
[PD]
[PD] -0.056
[PD] Best=0.000, worst=0.056, min=-0.056, max=0.019, mu=-0.005, sigma=0.015, energy=0.017
I consider this a beta-quality release. It probably won't break your printer, but keep your hand on the power switch until you've seen it run successfully for awhile and don't leave it unattended while it's probing!
There is room for more improvement in the code, and I'll get to that when I have some time. For now, I hope some more people can benefit from my work.
If you run my firmware, I'd appreciate it if you could share your experience here. It would be nice to see some before-and-after G31 Z output. I would eventually like to send a pull request to the Smoothieware project so that they can pull my code into the main distro, and I told him I'd have some people test it out first.