Experimental gcode auto Z compensation ready to test...

[Nylocke]

Think FSRs would be repeatable enough for this? Would be nice to not have to mod my existing setup

[bvandiepenbos]

Think FSRs would be repeatable enough for this? Would be nice to not have to mod my existing setup

maybe, but would you need extra electronics and/or a Aurduino to interface with Rambo endstop signal input ?

Michael's idea is just so simple and elegant, why complicate it?

[mhackney]

Sure. You could do a full matrix scan for more precise results. This new work is an optimization for folks without a sophisticated probe already. Brian, the FSRs look like an endstop to the firmware so they are transparent. I experimented with them last year but never got it to work with the heavy rostock bed with a heater and aluminum dissipator.

[Nylocke]

I'm not saying everyone should get FSRs, I'm saying I have an existing working FSR setup that would be convenient to use. Mine work pretty well, just want to double check with you that you'd think they would be repeatable enough

[bvandiepenbos]

Take one of the thinnest leaves out of a feeler gauge set and fasten to platform with a pivot point that rotates at a bit of angle so it rotates up out of the way when printing. Then just leave it on the printer.
Now I know what those 2 spare "Aux." pin wires on the Jellow Jacket QC board can be used for !!


Could even mount the feeler finger on a servo to automate it further.

one drawback may be plastic buildup or ooze from nozzle would mess up contact.
so your nozzle would need to be kept clean.

[mhackney]

A quick swipe on the nozzle should do it - do a bit of a retract first.

This has the advantage of setting Z=0 precisely too, which is why machinists use it. If you have brass feelers, soldering on the lead is easy. Otherwise, a screw and washers or alligator clip work.

[radicaldev]

A quick swipe on the nozzle should do it - do a bit of a retract first.

This has the advantage of setting Z=0 precisely too, which is why machinists use it. If you have brass feelers, soldering on the lead is easy. Otherwise, a screw and washers or alligator clip work.

I've been meaning to ask,

The manual and about a million other sources say to use a piece of notebook paper and set the nozzle such that it "just drags" on the paper. That doesn't sit well with me, because notebook paper thickness varies within and between manufacturers, and "just drags" is very subjective.

What is good height to set z=0 to? I mean, the notebook paper trick works pretty well, but so does 0.12mm.

[mhackney]

The best height to set z is "0.0mm"

You are dead right, notebook paper is a cop out. I learned a trick from old time machinists that is excellent. Use cigarette rolling paper (or joint paper if you are in CO or WA). It is very consistent at .001" thick. And, when the tool "bites" the paper (the drag test), it rips. If you are persnickety you add .001" to the Z. This is basically what I do but I actually use .001" thick stainless feeler material (I use it for other projects so I get it in bulk, but you can buy a gauge - even a metric one and use 1 leaf). The "snag" is subjective. The key is to be consistent and MEASURE many trials to see how close you are. I know that when I drag on .001" it is .001". I don't worry about that small amount with printing.

[radicaldev]

Awesome. I didn't really have a plan for what to do with my printer once I got it. I figured I'd just become proficient with 3d modelling software and print some stuff, but I've always wanted to get into CNC-everything from lathes, lasers, mills, etc.

Succintly, I didn't realize this could be that. The printer itself, at the moment, is way more interesting to me than 3d printing.

ETA: I start my race to mod a HF dial indicator to work for my purposes with the orion in about an hour. My guess.. It'll be an 8+ hour endeavor to get it working right.

Update: HF Indicator modded and connected to (and powered by!) arduino -- reading data =)

This guy: http://hackaday.io/project/511-digital- ... face-probe
Plus this guy: http://www.instructables.com/id/Reading ... and-Power/
Equal this guy: [img]http://i1151.photobucket.com/albums/o637/radicaldev/20150207_013852.jpg[/img]


Lol... margaritas and lack of sleep make bit twiddling confusing, so Arduino just passes the binary data to Python...

That was easy...

Convert 100101000110000000000000 to 7.88
Convert 100101000110000000000100 to -7.88

Python code

Code: Select all

import serial
s = serial.Serial("/dev/ttyACM1", 115200)

while True:
    data = s.readline().strip()

    if len(data) != 24:
        continue

    val = int(data[1:-3][::-1], 2)/100.0
    if data[-3] == '1':
        val = -val

    print val

Arduino code

Code: Select all

int dataIn = 11;
int clockIn = 12;

int clock = 1;
int lastClock = 1;
int out = 0;

void setup() {
  pinMode(dataIn, INPUT);     
  pinMode(clockIn, INPUT);  
  Serial.begin(115200);
}

int index = 0;
int bits[24];

void loop(){
  lastClock = clock;
  clock = digitalRead(clockIn);
  if (lastClock == 1 && clock == 0){
    out = digitalRead(dataIn)+digitalRead(dataIn)+digitalRead(dataIn);
    
    if (out > 1){
      bits[index] = 1;
    }
    else{
      bits[index] = 0;
    }
    
    if(index >= 23){
      index = 0;
      for(int i = 0; i < 24; i++){
          Serial.print(bits[i]);
      }
      Serial.println();
    }else{
      index += 1;
    }
  }
}

Now we're reading for mounting to the platform. An obvious limitation of this indicator is a really slow sample rate... Something like 2 to 3 samples per second.

[mhackney]

Ok, so we are at the point to make this easy to test. The Barycentric interpolation is working well. It only requires 25 data points and these are concentrated in the hot spots where issues show up on delta printers. Even collecting the points manually only takes a few minutes so anyone/everyone should be able to do it. I still need to create a little program to create the set of triangles from the collected data points but the interpolation works and is fast even without additional optimizations (of which there are a few that will speed things up even more).

[radicaldev]

Awesome!!

Rigging is done, and after some tweaking the mapping process is not as slow as I thought it would be. Gunna do some testing tomorrow to see how accurate my maps are, then I'll post some pics and the new code.

Mount for Orion platform: http://www.thingiverse.com/thing:672344
Mount using same hardware as for the hotend.

[enggmaug]

Hey Mhackney,

I'm glad you took it further than I did.

I kind of gave up on that because I thought that whilst the height of the build raises, the mapping may change.

To me, if you need to interpolate at Z=0 in X and Y directions, you may have to interpolate also the geometry change at different values of Z.

In other words, it would be more accurate, (but also more difficult) to map not only the bed, but the whole printing volume, and interpolate in X,Y andZ.

But while I gave up, and have nothing, you, Mickael, did it... I'll happilly try it out.

[mhackney]

Cool, I remember your post from last year. I've done some measuring of my rostock at Z=0, z=6" and Z=9" (with gauge blocks) and there was not enough variation to worry about. Of course, every build is different.

My thoughts are that firstly, just getting a good first layer kills a lot of folks. This approach will significantly help that. Secondly, most parts that are large diameter are usually fairly short so any differences in the mapping as you grow Z won't be critical. Also, tall parts are usually don't have critical dimensions - thinks like sculptures, Yoda, etc so some variations in Z aren't show stoppers. Again though, these are my thoughts and everyone's situation is different. It's a start!

Cheers,
Michael

[Eaglezsoar]

You guys sounds like a bunch of Einsteins.

[radicaldev]

Just wait til I formulate my theory on (delta arm z-stop) relativity.

Seems that a change in one screw effects the entire platform.

[radicaldev]

Haven't quite touched up the code enough to print, and I decided to diverge from mhackney's original script and instead use a kdtree. Also refactored a bit to make further development toward support for multiple printers, dial indicators, and slicers less of a chore.

With 10mm spacing and a bug in my row change code which causes the dial to be read before z height settles (high spots on left corner between X and Z tower), I think the results are pretty good.

Code runs once, builds z offset, then runs again applying the offset.

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

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

[mhackney]

I've gone away from using a full matrix and instead I am collecting a small # of points (31 Rostock, 25 Orion and Mini Kossel) and using Barycentric Interpolation over every point in the gcode. I'm getting good results and Jimustanguitar is very close to testing on his Rostock. He used a dial indicator for probing. I implemented the touch probe I mentioned earlier. It works great and it couldn't be any easier to make or use.

[Nylocke]

I would love to try the touch probe thing with my FSR sensors.

[mhackney]

Ok, let me polish off the code tonight and I'll post it tomorrow. Right now, it works like this...

There is an excel spreadsheet and the python code. The spreadsheet has a tab for each supported printer, Rostock first. Each printer page has the gcode needed to probe the points. Right this minute, this is for a dial indicator, I am adding the probing gcode tonight so you can use it (I used it for my touch probe). I'll provide the files for the probing gcode too.

You run the probing code. In the case of a dial indicator, there is a pause that gives you time to take a reading and enter it in the spreadsheet. In the car of a problem (FSR, etc) the code will output the measured value in your host control's logging window. You will need to go through the log and pick out the probe points to enter in the spreadsheet.

Now, once the probe points are in the spreadsheet, it automatically generates the python variable for the probe points and the triangles used for the interpolation. Right now you have to copy and past this into the python postprocesor. The plan is to generate a txt file that will just be passed in to the python script.

Now you can either run the script from a command line or enter it as a post processor in KISS. In either case, a new file with the Zmapping is created so your original gcode file is not harmed.

[Nylocke]

That sounds pretty awesome. I'd love to give it a try, last night I tried printing Pilot's extruder mount (the whole plate) and only 4 or 5 of the parts turned out okay, the ones that didn't failed because of the first layer. In the end I only ended up using one, since I reprinted everything except the actual extruder mount in KISS (tried the plate in Cura). I'm getting some pretty neato results with KISS so far. I finally stopped being lazy and calibrated my extruder and measured my filament instead of doing a print and looking at the top and saying "eh, it looks fine".

Off of that tangent, I could really benefit from this until someone does some nicer calibration routines in Repetier that adjust tower rotations and things. Wanting to print parts for a filament extruder for my local makerspace and they are quite large.

[radicaldev]

Neat. I managed to generate a spiral pattern (four actually),which are ordered such that the print head is moved in rotating triangles that grow toward the extremeties.

After applying the map, I was down to .09mm es with tolerance of +/- .045mm

That's replaying the same points though. Probably not so fine when using new uncharted ones.

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

[KAS]

Neat stuff and well above my level.

Is effector tilt possible to measure? For example if the towers are square to the bed, but tilted to the left or right?

[enggmaug]

Neat stuff and well above my level.

Is effector tilt possible to measure? For example if the towers are square to the bed, but tilted to the left or right?

It could be possible to measure with 3 sensors on the platform, but how do you intend to correct it anyway ?

To me, a tilt means towers are not square...

[KAS]

Well I guess that's what I was getting at. Everyone is measuring with single point probes. The instructions when building the kit explained the process to "square" the tower to the bed in a single axis but not the left/right or the tower lean angle. The weight of the tower sitting on one alignment screw will naturally persuade the tilt. It wasn't until recently I found that my towers tilted/leaned slightly at various angles with a digital angle finder, although I was within 90 to the face of the bed. With three towers at random lean angles, you'll have 6 rods at various heights. If I'm understanding that correctly, wouldn't it be difficult to guarantee a parallel effector to the bed? We force the effector into "good enough for me" state by calibrating it in four locations. X,Y,Z, Center. But everywhere else that nozzle is not pointing 180 degrees straight down, it's tilting off center.

Again, I'm new to this. So just trying to work this out in my head and grasp the concepts.

[mhackney]

KAS, this thread is about COMPENSATING for small issues in the mechanical build and configuration. This thread IS NOT about calibration! It assumes that you've done your best on the mechanical build, can at least get the delta radius and tower offset calibration completed in good shape but still have a few gremlins that appear as "highs" or "lows" on a layer as you print. This is usually the biggest problem getting that first layer (or few) down. This project builds a topographic map of your build surface at a few (31 Rostock) strategic points and then uses that data to compensate for these variations by applying a map to the gcode as a post process. This could, of course, be done in firmware and I plan to do that for Smoothie once the proof of concept is complete.

This compensation will remove all mechanical issues, including platform tilt and tower tilt. But the better you can build your machine, the better!

cheers,
Michael