[WIP][RFC] Automatic bed adjustment

Yes, this looks a lot simpler, but will still require moving the rod during printing of a single layer.

No problem with atmel (actually - attiny2313 stuffed with vusb stack is still my favorite), just don't like arduino (the software part of it, the hardware is pretty typical, though insanely overpriced), since I have to often switch MCUs for my projects, between avr, stm32, msp430 (fram series rock!). And a lot of tasty stuff is not available with it. Even vusb for avr is not supported! Besides, as a linux kernel hacker for a living I have been long addicted to Kconfig.

Yeah, I will be trying this as well. But as I said above, for 0.05 layers I think I will get better results if I do NOT move z rod during printing of a layer at all, to avoid any artifacts. So this leaves me with only one insane option.

Yeah, I've seen those very articles a year or so ago, and I'm still wondering if digital dial gauge has something similar built-in.  (And yes, it's not serial, I was wrong).

I'm afraid laser will suck, due to being reflected from the glass surface.
ultrasonic and PIR sensors are not likely to work as well.
ultrasonic has minimal distance of about 30 to 60 cm.
PIR - I'm afraid glassy surface will screw up the readings and I don't think it's that precise. (but it IS on my checklist to try)

Why not just a digital dial indicator?

There's another thread around here somewhere that mentions interfacing arduino avr or another microcontroller with digital calipers - I don't see why the same couldn't be done with a cheap dial indicator.  The cheap indicator that I bought from harbor freight this week has a similar output port.

Mine is labeled "Pittsburgh" but I'm sure they're the same thing:
http://www.harborfreight.com/1-inch-sae … 93295.html

Example connections and interfaces with the calipers:
http://www.robotroom.com/Caliper-Digital-Data-Port.html
http://nut-bolt.nl/2012/reading-digital … n-arduino/
http://robocombo.blogspot.com/2010/12/u … rface.html

Ha - go figure...  adrian and Necromant were on to the same thing in their posts above - I was was just looking at the "new posts" part of the thread.  Their posts were exactly what I was referring to when I said "...another thread around her somewhere..."

Consider this:
...put thick gears in place of the leveling thumbscrews, put a worm gear on little gear motors (3 - one for each screw)  to turn them [thick screw gears so that the worm gear can slide up and down along the teeth as they move up and down], drive the gear motors from an arduino (with simple on/off transistor switches to get enough current) connected to the dial indicator.  As long as the extruder is repeatably near the leveling screws, an algorithm to level a 3-point plane should pretty much solve it - just cycle around the 3 screws.  All the resolution you need will come from the dial indicator - don't worry about backlash in the leveling gears.

Really, if you manually put the back single thumb screw at a "middle" position, you would only have to adjust the other two screws to level the bed. ...but still use a measurement at the other screw.

Assuming you can repeatably position the extruder (either by direct g-code or by g-code scripts with pauses), theres no need to mess with anything else on the computer side of things.

Yep - I really wish we had a level of scripting available in the gcode that could perform some basic actions/math and make use of auxilliary inputs and outputs on the control board.  Only way I could think to do that currently would be to run the printer on Mach 3 and a diffferent board.  Basically process the slicing and gcode in RH and Slic3r, save gcode to file, load in Mach 3, run leveling and z-stop scripts (with inputs and outputs), load gcode and print.  I'm not experienced with Mach 3 but I'm sure it could be configured to interpret the extruder and bed temperatures.

Holy Crap thats a nice and easy way to level the bed.

That might be something we can implement depending on how much room is under the bed. Might need to sacrifice a little z height.

Nostalgia trip (it won't help you interface to these calipers), just old guy telling stories.

Back when the first version of these calipers was made, the external interface was much simpler.  The data port was intended to drive an external up/down counter.  One pin was a clock and another a direction signal. That's how they worked internally too.  (no uC in them back then)

How do I know?  Back in '78 - '80 I was the project engineer responsible for designing the electronic guts in the very first digital caliper with a liquid crystal display.  All of these new ones use the same sensor and operational concept.

The sensor concept, and the basic functionality, was invented and patented by a professor in Stockholm, Sweden.  I was the project engineer turning his patent into a product.

The attached photo is my personal one of the original model.  Over 30 years old and still working.

(Back to original programming)

Nick