This is quite an old update that I had planned on publishing last year, with the state of my dynamic bed levelling project as it stood at the time.
I hope to add further updates shortly

following a discussion on the #emaker IRC channel I have returned to the dynamic bed levelling routine with a little more success, and a whole load more issues.

The AVR644p as an FPU

The statement that prompted me to return to this went something along the lines of “everyone always says that the 8-bit processor in the printer cannot do floating point maths very fast, but no-one has ever proved it.” So I set out to convert my dynamic bed levelling code to do its calculations directly on the little 8-bit atmel 644p processor that was already busy managing all of the other aspects of the printing process.

The change was really quite simple, rewriting the routines that used to run on the FPU and leaving the calling functions pretty much unchanged.

And the result?

It works!

With the benefit of  hindsight, most of the calculations are performed during the calibration phase, and before any other printing operations take place, so the strain on the processor is not all that great, but it is impressive none-the-less.

While the printer is operating the routine simply multiplies the destination coordinates by a 4×4 matrix to get the new transformed location, and this can be performed without holding up the processor from doing any of the other important stuff that it needs to be doing.

Z-probe is not z-endstop

Another change that I have made is to move the z probe wire from its dedicated pin to the z-endstop input. The aim here was to remove the need to run a separate probe sequence to set the z height every time the printer was started up. The theory being that once the bed has been calibrated the settings can be saved, and a simple G28 to determine [0,0,0] would be enough to set up the printer.

The first issue that this course of action raised was that homing x and y positioned the nozzle off the edge of the bed, a slight tweak to the metal arms on the x and y endstop switches to position the nozzle right on corner of bed solved this problem.

Z-Probe woes

The biggest outstanding problem with this process is the accurate measurement of the error to be corrected.

Currently I am using a very clever probe circuit built into the RepPapPro Huxley’s heated bed. Whenever the print head presses down on the bed the probe circuit is broken. This means that the Z height can be  measured anywhere on the bed.

When this works I can extract consistent measurements from the probe, but a number of things have lead me to question the accuracy of this probe.

Unfortunately, as clever as this probe system is, it suffers from a number of serious flaws. The most serious of which is the way that the bed can get stuck with not all of the three contacts closed.

Another major flaw in this system is the effect of the springs in the bed acting against the backlash springs on the z carriage. The effect of this interaction is to throw off the results of the probe in such a way that the bed measures higher as the probe approaches the support springs on the bed.

Current issues…

1: Scaling
There appears to be an issue with scaling when printing with dynamic levelling enabled. This could be a rounding error…
2: can’t rotate gravity!
There seems to be distortion in the prints produced that I have put down to the extruder not being perpendicular to the bed.
3: only 32bit
I don’t know that this is an issue, but I would be much happier with the precision of the routines if I I had more than 32bit floating point numbers to work with.

So the projects on hold again?

Again Progress is halted – my plan now is to rebuild the bed using the new reprappro design of y carriage to try to improve z-probe reliability.

Another option that has recently presented itself in the slic3r tool is the option to print the first layer of a print much thicker than the rest of the layers in the print. This might be enough to iron out any small errors in the level of the bed.