Experimental gcode auto Z compensation ready to test...

[KAS]

I gotcha, thanks for the clarification. I was looking at the tests as an indication that something was not structurally sound and I couldn't grasp how a single point probe could tell you more info. I was trying to grasp the concept of a dial indicator with a rounded test point an inch+ off the bed trying to measure something from a slightly twisted effector. To me that measurement would be erroneous value compared to a nozzle a few mm away.

anyways, I can definitely appreciate the level of smarts going on around here. But, I'm going to crawl back into my hole and keep reading and hopefully learn through osmosis.

[Eaglezsoar]

You all are talking way over my head, all this math and exponential thinking makes my brain hurt, can we just make something that
probes the bed like the Kossel can do using Marlin?

[bvandiepenbos]

I know this is a bit off-topic since this thread is about compensating for error in effector movement, but it got me thinking and wondering if lengthening the stock 269mm arm length to 280 or something would help? Or maybe move the "bad" areas out of the typical build area?

Of course you lose some build height, but it would be worth it in my opinion.


Another thing that really bugs me is why are the bad spots in mostly 2 areas not 3 ?
And why does the change in travel happen quickly in a short distance?

[mhackney]

Eaglesoarz, the marlin probing is for auto calibration and does not do compensation. I understand that Johann's fork might have some form of compensation but I haven't been able to use it. I won't do any dev work on Marlin or Repetier - they are just too much spaghetti for my liking. I've been doing some dev work on Smoothie, it is very nicely structured. I contributed a module last year that a lot of printer folks are using (temperatureswitch). I've entered this delta compensation into their contest. In any event, once I know that the proof of concept works for folks, I will implement it in smoothie. In theory it should work, really just a question of how many points need to be probed. This work is all about reducing the # of points so it can be done manually.

[Nylocke]

I've used the composition branch of Marlin. Not sure if the compensation code or the Marlin code caused it, but it did quite a bit of stuttering.

[mhackney]

Ok, here is the latest and greatest. There are 3 parts that you need:

The probing gcode. There are 2 versions of this for Rostock (you can make it easily for Orion using the spreadsheet). One is if you use a dial indicator and the other if you have an automatic probe of some sort (switch, FSR, etc). The dial indicator version moves to the probe spot, lowers slowly and pauses at Z=0. You must read the delta Z (positive or negative) and enter it in the spreadsheet (explained next) in the FILL THIS IN FROM PROBING blue cells. The automatic probe version will do a G30 at each probe location. This will/should be logged in your host application's log/terminal window. You should be able to let the script run and then go back and copy all of the Z heights to the spreadsheet. These will go in the blue cells with the Automatic Probe header. The difference is, the automatic probe gives you a Z height. You enter that and the spreadsheet subtracts the Z height from X=Y=0 to get the delta Z needed for the program.

The second part is the spreadsheet. There is a tab for Rostock and one for Orion/Kossel. I've explained how to use the blue cells to capture your delta Z or actual Z above. Once you've entered those, you will see the green section IMMEDIATELY to the LEFT of the blue area you used update. This is the code you need to copy to the python script (the 3rd part). This is a short term kludge to get you started. Ultimately, this will be handled automatically. But I want to make sure this concept works before spending too much more time on it.

FYI - in the upper right corner of the spreadsheet is the gcode generator for the probing points. The top section generates the dial indicator manual probing and the lower section generates the automatic probing. You simply copy these to a text file, rename it something like probe.code and maybe do a little formatting. I've already done this for Rostock as described above. I'll do Orion/Kossel when I have some time.

The third part is the Python script itself. At the bottom of the file ZMapper.py you will see a comment:

Code: Select all

        
#=========================================================================
# EDIT THIS SECTION TO INCLUDE YOUR PROBE DATA 
# by editing the last value (0.0) in the "[]" with your probe data
# OR copy and paste the automatically generated code from the green
# cells in the accompanying spreadsheet
#=========================================================================

Everything between this comment and the ending comment:

Code: Select all

#=========================================================================
# END OF EDIT SECTION
#=========================================================================

Is replaced by copying and pasting the green cells in the spreadsheet (the once I mention above IMMEDIATELY to the LEFT of the blue input cells. Again, this will be completely automated once I know this works.


Finally, once you have the ZMapper.py script edited with your delta z map, you can either set it up to be run automatically from KISS or run it from the command line.

In KISS for Mac OS X, in the Printer->Firmware tab is the post processor field. Enter:

pythonw "/Users/YOUR USER NAME/Desktop/KISSlicer-v1.5-beta-2.7/ZMapper.py" -"t" "/doesntmatter.txt" "-i" "<FILE>"

For Windows:

C:\Python27\python.exe "C:\Users\YOUR USER NAME\Desktop\KISSlicer-v1.5-beta\Zmapper.py" "-t" "\doesntmatter.tx" "-i" "<FILE>”

The ONLY thing you need to edit is the path to the ZMapper.py script. I'm on a mac so paths begin with /Users. Windows will likely start with C:/ The -t doesntmatter.txt does not matter, don't change it! This is where the data will be entered later.

You can also call the script from a command shell or terminal:

'pythonw' '/Users/YOUR USER NAME/Desktop/KISSlicer-v1.5-beta-2.7/ZMapper.py' '-t' '/ddd' '-i' '/Users/YOUR USER NAME/Desktop/KISSlicer-v1.5-beta-2.7/TEST.gcode'

Here you will have to specify the paths to both the script AND your gcode file to process.

In either case, ZMapper will create a new file with the word ZMapped appended to the file name part. It will not harm your original gcode.

What I need now are a couple of power users who understand the above and can give it a shot. Beginners need not apply because, as you see, a little more technical experience is necessary at this point.

Good luck!

Zmapper.zip

(56.23 KiB) Downloaded 364 times

[Nylocke]

I'll get to trying it sometime here. Tonight I'm going to my local Makerspace and tomorrow I've got some things I'm planning on doing. Might be able to do it afterwards, I will tell you how it goes and show some nice pictures.

[Jimustanguitar]

Michael was nice enough to spend quite a bit of time working with me on this last night. It's very close to working!!! In fact, I think it does work, I've just got some slicer issues to address before I can test it fully.

We ironed the wrinkles out of having a layperson like me figure out how to populate the Python script with my own measured values. Also made good progress on calling the program in Mac vs Windows, integrating it with Kiss Slicer (which is very very cool, by the way), and running it outside of the slicer from a command prompt.

At this point, the processed code is definitely changing Z values according to the interpolation routine. I still need to run an actual print to test it, but it looks very right!!!

Props to Michael for the work and time he's invested in this. It'll be an awesome improvement to the world of Delta 3D printing!

[radicaldev]

mhackney,

Is it just me, or do you never actually set X to anything but zero in mapZ?

You set a local variable X in getZ, but you never actually call getZ, and getZ returns None, and X is not global.

e.g.:

def mapZ(lineParts, layerHeight, interpolationType):
X = 0
...
...
...
if firstChar == 'X':
X = float(X) ->>>> X = 0 on first run, I think maybe you're supposed to parse X from the gcode, no?
...
...
...
if firstChar == 'X':
X = int(round(float(X)/10) + columns/2)

[mhackney]

I don't touch the X or Y or E positions. All I do is calculate an explicit Z and add that to each G1 line.

You are looking at the default initialization of X and Y in the mapZ routine so that I can access them from within the IF statements.

By the time mapZ function is called, I've already parsed the gcode file and working on a specific line - that is the lineParts in the function declaration. It contains the parts of a line like G1 X=3.22 Y44.9 E0.23

Read the comment at the start of the function. You can add:

print lineParts

at the very start of the file (even before the X=0 line) and it will print the contents of lineParts so you can see what is in there. Do this from the command line though, not as a KISS post processor.

[radicaldev]

I get that.

Your comment is:
# Use the X and Y positions in lineParts to lookup the Z height adjustment, add that to
# layerHeight and return a formatted gcode line. Currently supports two types of mapping:
# 1) a matrix of delta Z values
# 2) Barymetric Interpolation over a set of triangles

but it seems you don't use the X position, ever...

Example output with print statements:
Set X = int(round(float( 0 ) + 5 /2
GCODE X: X-0.77
Set X = int(round(float( 0 ) + 5 /2
GCODE X: X-4.15
Set X = int(round(float( 0 ) + 5 /2
GCODE X: X-3.86
Set X = int(round(float( 0 ) + 5 /2
GCODE X: X-1.74
Set X = int(round(float( 0 ) + 5 /2
GCODE X: X-3.86
Set X = int(round(float( 0 ) + 5 /2
GCODE X: X-4.15
Set X = int(round(float( 0 ) + 5 /2
GCODE X: X-0.77
Set X = int(round(float( 0 ) + 5 /2
GCODE X: X-0.02
Set X = int(round(float( 0 ) + 5 /2
GCODE X: X-0.31
Set X = int(round(float( 0 ) + 5 /2

[mhackney]

Not sure where you are looking - there are 2 ways to look up the delta Z as it says in the comment. I am mostly focused on the barymetric interpolation now. It may be that the matrix look up is not working or you do not have a deltaZ mapping CSV file. Last I tried the matrix lookup (Sunday) it worked fine and I know the BI works as I am running that myself. The X & Y are used to determine which triangle the point is in. Then the interpolation is done from the 3 points of the triangle and the delta Z value associated with each point.

It would help if I knew where you put the print statement so I could test/verify here.

EDIT: I see from the "5/2" part of your print message you must be doing something special in that is the number of columns/2. None of my CSV files have 5 columns.

[radicaldev]

Lol. Too complicated.

What I'm saying is,

you left out "X = float(part[1:])" in your script in all the places that depend on the X coordinate from the gcode.

So, essentially, the algorithm you're using is working with only one valid axis.

Say I wanted to know what my Z height should be for X25.735, Y-28.2, I could only get as close as X0, Y-28.2.


Lines 114, and 153 should probably be X = float(part[1:])

[mhackney]

Yup, the X calculation was inadvertently removed in the version of code I posted - I had removed a bunch of debugging coed and inadvertently removed some code that's needed! Thanks for finding that.

Code: Select all

#----------------------------------------------------------------------------------------
# Use the X and Y positions in lineParts to lookup the Z height adjustment, add that to
# layerHeight and return a formatted gcode line. Currently supports two types of mapping:
#    1) a matrix of delta Z values
#    2) Barymetric Interpolation over a set of triangles   
#
def mapZ(lineParts, layerHeight, interpolationType):
    X = 0
    Y = 0
    
    # perform Barycentric Interpolation
    if interpolationType == 1:

        # find X, Y for the move
        for part in lineParts:
            firstChar = part[0]
        
            if firstChar == 'X':   
                X = float(part[1:])   # <=== changed
            
            elif firstChar == 'Y':
                Y = float(part[1:])

        if ((X >= 0) and (Y >= 0)):
            for triangle in NEquad:
                deltaZ = deltaZfromTriangle([X,Y], triangle)
                if deltaZ != "not found":
                    break
    
        elif ((X >= 0) and (Y < 0)):
            for triangle in SEquad:
                deltaZ = deltaZfromTriangle([X,Y], triangle)
                if deltaZ != "not found":
                    break

        elif ((X < 0) and (Y < 0)):
            for triangle in SWquad:
                deltaZ = deltaZfromTriangle([X,Y], triangle)
                if deltaZ != "not found":
                   break
            
        elif ((X < 0) and (Y < 0)):
            for triangle in NWquad:
                deltaZ = deltaZfromTriangle([X,Y], triangle)
                if deltaZ != "not found":
                    break       

    # use matrix lookup
    else:
        # Here's where I'd like to do a linear interpolation to get a better Z estimate.
        #

        # find X, Y for the move and divide it by 10 for the 10mmx10mm cell size
        for part in lineParts:
            firstChar = part[0]
        
            if firstChar == 'X':
                X = part[1:]  # <===== changed
                X = int(round(float(X)/10) + columns/2)
            
            elif firstChar == 'Y':
                Y = part[1:]
                Y = int(round(float(Y)/10) + rows/2)

        deltaZ = heightMap[X][Y]
        
    newZ = float(deltaZ) + float(layerHeight)
    zLine = 'Z' + str(newZ)

    lineParts.insert(3, zLine.strip())
    newCodeLine = string.join(lineParts, " ")

    return newCodeLine

I think those were the only two places.

[radicaldev]

Happy to help! I know next to nothing about the math, but I know a lot about python and programming

Enough about the math to know X coordinates matter in an algorithm that depends on them.

[radicaldev]

Haha!

I figured it out!

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


0.016 extreme spread!

Turns out, past a certain negative z value, I can't go down any further, which is why I had a tilted looking bed.

If I start from slightly ABOVE zero, however, I can get REALLY precise!

That means I need to do some hackery though... Either modify the firmware to let me go down further, or Set z=0 below the glass plate, and alter every z value in the gcode regardless of wether or nor it needs compensation, BUT... WOW, I'm good with 6 ten-thousandths of an inch tolerance!


UPDATE:

Nevermind all of that. I upgraded to repetier 0.92, which lets you have negative Z values a couple of ways. Was kind of scary uploading it to the Orion. I based all my config.h and pins.h values on the ones from seemecncs github/my eeprom settings/judgement. Seems to be working OK. Pretty cool being able to set my printer name =)

I did accidentally invert my Y tower, but luckily I learned from my initial hour with this machine that homing axes can be dangerous, and you should not do that until you know all of them are going to move/move in the right direction/stop when they get there. There was a bug in the 0.92 code though. I dunno if I fixed it or not.

On line 2599 in ui.cpp,

INCREMENT_MIN_MAX(Printer::maxTravelAccelerationMMPerSquareSecond[num],100,0,10000);

caused a compilation error -> num not declared
I looked around for things that might be nums, and found action being used two lines before that one for a similar purpose that num probably has. I haven't found the consequences of my action, yet, but if I understand the code correctly, it's just printing some stuff to the LCD, which I don't really care all that much about.

[enggmaug]

I had a quick look into the python script.

I don't believe you would split the movement in several commands if it appears that the gcode goes a long straight line over several Z height measurments.
That could be a future improvement.

Other than that, I am not fluent enough in Python to read it like an open book, but your code looks clean.
However I'm pretty sure you can find some librairies to perform interpolation, like maybe scipy. Maybe it could be more efficient ?

[mhackney]

Thanks enggmaug. I have a fair amount of experience with interpolation algorithms. The Barycentric Interpolation is almost perfectly suited for this application and is very efficient. I do not like to pre-maturely optimize things until I know the concept works. I'm still waiting to get validation on that. Once we know this will solve a problem, I know how to make this code MUCH faster. But, even as it is, it takes maybe 2-3 seconds to process a reasonably large gcode file. Not really bad at all.

[mhackney]

This is the latest version that has some bug fixes (as discussed a few posts ago) and enhancements.

Starting with this version, the probe data file is now stored in a separate txt file and loaded with the -t command line option. So, you can either load a matrix of values from a a CSV using -z OR the file of triangle probe points for the Barycentric Interpolation using the -t option. I HIGHLY recommend using the later, this is where I need feedback.

You can run the script from the command line:

python /Users/XYZ/Desktop/KISSlicer-v1.5-beta-2.7/ZMapper.py -t ./SampleProbePoints.txt -i /Users/mhackney/Desktop/KISSlicer-v1.5-beta-2.7/SomeSpecial.gcode

Zmapper 2.zip

(57.89 KiB) Downloaded 353 times

I started to investigate supporting Cura gcode but it is very difficult to parse. i finally gave up after multiple hours. I will consider re-investigating once the POC is proven. It isn't worth the effort until then.

[radicaldev]

Cura's easy to parse. It's Slic3r that is a little more difficult.

I'm going to print something today without a script, with my script, and with your script, to see how they work.

Here's my Cura processor.

Code: Select all

class CuraPostProcessor(PostProcessor):
    def process(self, outfile=None):
        if not self.interpolation_engine:
            raise Exception("No interpolation engine specified")

        if not outfile:
            outfile, ext = os.path.splitext(self.gcode)
            outfile = outfile+"-processed"+ext

        layer_height = 0
        layer_count = 0
        with open(outfile, 'w') as out:
            with open(self.gcode, 'r') as gcode:
                for line in gcode:
                    line = line.strip()
                    if "LAYER" in line:
                        layer_count = int(line.split(":")[-1])
                    elif "G0" in line and "Z" in line:  # Your get layer_begin_height function would look for this
                        layer_height = float(line[line.rindex("Z")+1:])
                    elif "X" in line and "Y" in line and not "Z" in line: # Your getZ would look for this
                        try:
                            x, y = re.findall("(?:X|Y)(-?\d+(?:.\d+)?)", line)
                            z = self.interpolation_engine.get_z_offset(x, y, layer_height)
                            line = line + " Z{0}".format(z)
                        except Exception, e:
                            print "WARNING: Unrecognized movement line: ", line, " Error: ", e
                    out.write(line+"\n")

[mhackney]

I'll take a closer look at your code but it looks similar to what I was trying earlier in the week. The issue is, I see a fair amount of variability in the Cura gcode samples I have and not all files have the Z height in a G0 line, sometimes it's a G1 line and that can either have. Also, the files Jim sent me have no comment at the top to identify them as Cura. I have some old files I made here and they have something like ;Cura Steam Engine - easy to parse.

I'll take a look and see if this works on my test Cura files.

thanks,
Michael

[radicaldev]

Hmm... Could be version issues. I'll try playing around with my cura settings to see if I see anything weird going on. In all my samples, Cura produced consistent gcode.

[mhackney]

Do your Cura files have the ;Cura Steam Engine (or similar) as the first line?

[radicaldev]

All mine start with ;Generated with Cura_SteamEngine 14.09

All layers look like
;LAYER:X
<Occasionally M command>
G0 F9000 X-32.692 Y0.223 Z<Z layer height>

All X,Y movements (sometimes with E, sometimes not) are G1 or G0 commands.

[mhackney]

Great. For some reason none of Jimustanguitar's files did.