Experimental gcode auto Z compensation ready to test...

[radicaldev]

Neat!

Figured out how to install my .35mm nozzle and swapped out the platforms.

Changed my cura slicer settings for the .35mm nozzle.

First layer height: 0.15mm
Others: 0.1mm
Ext Temp: 210
Bed temp: 50
Material: PLA

Printing: Test circle (1mm high, 1/2 bed-width wide, 100% infill, 20mm/s)


UPDATE:
I was unable to get a very good print with the above settings.
The default print had very low spots at the Y tower and between the Y and Z tower.
My compensator alleviated the problem a little bit
I didn't get around to testing Michael's yet.

It's as I feared, though. Direction of travel effects z height.

For example (Not real numbers, haven't measured specifics yet):

from X0, Y0, Z15 to X0, Y0, Z0 -> Z height is 0
from X0, Y0, Z-1 to X0, Y0, Z0 -> Z height is -0.02
from X1, Y0, Z0 to X0, Y0, Z0 -> Z height is -0.01
from X-1, Y0, Z0 to X0, Y0, Z0 -> Z height is 0.02
from X0, Y1, Z0 to X0, Y0, Z0 -> Z height is 0.01
from X0, Y-1, Z0 to X0, Y0, Z0 -> Z height is -0.01

Adding in other types of movement also effects the z height.

So, what I see in the case of lines being drawn from the X tower to the midpoint between Y and Z towers, is numbers one way are one set, and numbers the other way are a different set, but these two sets are repeatable.

The good news is: It seems that my indicator platform and hotend platform are dimensionally very close, so this method, once worked out, should be useful when swapping in the hotend platform.

[radicaldev]

Note to self... Consider the new forces.

So, ordinarily, there's no upward pressure on the platform (maybe some from extrusion). There is when you're using a dial indicator with a spring in it.

That totally changes things.


Update:
I took the spring out and put a little bit of light oil on the stem.

Much better looking results.

255 point map:
[img]http://i1151.photobucket.com/albums/o637/radicaldev/bp_10mm_nospring.png[/img]

Replay side of map:
[img]http://i1151.photobucket.com/albums/o637/radicaldev/bp_10mm_nospring_replay.png[/img]

Replay top of map:
[img]http://i1151.photobucket.com/albums/o637/radicaldev/bp_10mm_nospring_replay_top.png[/img]

Not sure what happened with that one spike. It was the only point that was out of place.


Some empirical evidence for my theory above. Direction matters.

These graphs are from running the map backwards. First ones were bottom to top, left to right. These are top to bottom, right to left.

[img]http://i1151.photobucket.com/albums/o637/radicaldev/bp_10mm_nospring_backwards.png[/img]

[img]http://i1151.photobucket.com/albums/o637/radicaldev/bp_10mm_nospring_backwards_top.png[/img]

Interesting...

Randomly moving to points, my initial map is this:
[img]http://i1151.photobucket.com/albums/o637/radicaldev/bp_10mm_nospring_random.png[/img]

Replaying the same points in a new random order gives me this:
[img]http://i1151.photobucket.com/albums/o637/radicaldev/bp_10mm_nospring_random_replay.png[/img]

They're almost identical....



Question: My Y tower seems to be the focal point of problems, and its cheapskate is markedly more difficult to move with steppers disabled than the X and Z towers. Could that be the issue here?

[radicaldev]

Much better evidence...

Maps were made across the buildplate where the head was moving from right to left, left to right, down to up, up to down, left to right at an angle of 45 degrees, right to left at an angle of 45 degrees, left to right at an angle of 315 degrees, and right to left at an angle of 315 degrees.

[img]http://i1151.photobucket.com/albums/o637/radicaldev/bp_5mm_multi_map.png[/img]

[radicaldev]

Progress!

I made 8 maps covering a manageable amount of points and directions.
Depending on which direction the print head is moving (calculated by considering the last x,y move and the next x,y move) , the map for that direction is used to lookup the z height.

Then, I set up a sample which previously failed miserably (with like +/- 0.5mm tolerance) --- randomly sampling 747 points
[img]http://i1151.photobucket.com/albums/o637/radicaldev/bp_5mm_multimode_replay.png[/img]

Still a couplle of outliers, but all under 0.12mm, with the majority being within +/- 0.06mm

A friend of mine shipped me a mitutoyo indicator which I will mod similarly to the HF one. If the sample rate is higher, I can build higher resolution maps and probably get better results.

Awesome!

[Fiddler2070]

Mhackney,

How is the auto Z compensation project going? There doesn't seem to be any updates since Feb.

I really like this project and wouldn't mind getting a dial indicator to do this although the leaf switch idea seems simpler?

Felix

[Neptune]

Did this work go a different direction? I was really looking for the end result...

Radicaldev, did you continue working on this beyond your posts?

Mhackney, did you switch to the switch method(could have sworn I saw something you wrote about using switches)..

[radicaldev]

I did, briefly, up to the point where I realized it's imperative to mount the indicator in the same way as the hotend in order to have the values be relevant while printing. Then I got loaded down with work, my son being born, and some other interesting obstacles. There's a lot of stuff I haven't gotten around to finishing, unfortunately.

Newer versions of Slic3r include verbose gcode which makes it pretty easy to post-process, and my kd-tree method for picking the compensation values based on direction seems to work fairly well. If the same mechanism was used for both the hotend and the indicator, I would expect some pretty decent results.

One of the main things keeping me from making this a priority is a lack of good dimensions for the V2 effector platform. I'm just not very good at measuring things like that and I need the hole spacing so I can make a suitable fixture for the indicator.