Firmware Z wobble compensation (Page 4 of 5)

Are we entirely WRONG about the causes of wobble?

After re-reading the reprap magazine post, I finally understand what the author is trying to say.  My solidoodle firmware is set to 2268 steps/mm for z-axis motion, which corresponds to 2268*1.411 = 3200 steps per rotation of the z-axis threaded rod.  The article implies that stepper motors are only accurate for 200 steps per rotation, and that there are 16 microsteps between each full step.  The problem is that stepper motors are non-linear when microstepping, so ideally you only want the stepper motor to move in 1/200th-revolution increments.

The calculations in the article seem to be a bit off.  It seems like you'd want your layer heights to be .1058,  .1976, and .3034 instead of .1, .2, and .3, respectively, and that this should eliminate wobble.  I don't have access to my sd right now, so can somebody verify this?

If this is true, this can have strong implications for firmware wobble compensation, since our current solution might only work for positioning that is a multiple of .1mm.  Instead, we'd want to base any compensation of raw motor micro-step (step%16) instead.

Yeah, I've been going back and forth in my mind about it this morning since I can't actually print anything at the moment to test.  But you're right that since we have an imperial threaded rod, we've in fact guaranteed that any roundoff-based wobble (if real) *cannot* have the exact same pitch as our lead screw. 

I did some calculations in excel to find out how the microstepped value (e.g. z-step % 16) varied with .1mm layer position.  The function is not quite periodic since there is roundoff in calculating the z-step value, but I got an interesting saw curve with a period of about .6mm, nowhere near our thread pitch wobble of 1.411mm (graph attached) that everybody is seeing.

Rince, can you update the parent post to let people know that the downloadable zip firmware is for SD2 users only and that SD3 users will need to do the manual include process. Would hate for someone to make that mistake.

Admins, if you are reading this, can we make this thread sticky? It seems that it's being referenced quite a few times now. Thanks

For software compensation to work, the measurements have to be repeatable.  If you're getting variability then I'm guessing something has loosened up in your setup.  If you have an anti-backlash solution, try tightening it up or adding a spring.  If you don't have one, you probably need one.

Don't you hate it when you type an error code into Google and it seems that you are THE ONLY one with this specific issue and the only link it suggests for you, is a link right back to here?

Sorry for the brevity, but i'm on the go. Tealvince is right. I just want to specify that this error just means that you haven't entered a valid set of parameters. And indeed the amplitude is zero, so no correction is applied. You would get the same warning if the amplitude was too big with respect to the period.

Here is the full output:

12:32:08.219 : ZWobble Amp (A) 0.00 phase (P) 0.00 period (W) 1.41 puls 4.45 Warning! Inconsistent parameters!
12:32:08.318 : Printjob finished at 4/25/2013 12:32 PM
12:32:08.318 : Printing Time:0s
12:32:08.318 : Lines Send:19
12:32:08.371 : Custom wobble function phase (P) 0.00 period (W) 1.41 puls 4.45
12:32:08.371 : Rod: 0.00 Act: 0.00                      +
12:32:08.371 : Rod: 0.10 Act: 0.07               +
12:32:08.371 : Rod: 0.20 Act: 0.16              +
12:32:08.371 : Rod: 0.30 Act: 0.28                  +
12:32:08.371 : Rod: 0.40 Act: 0.40                      +
12:32:08.371 : Rod: 0.50 Act: 0.51                        +
12:32:08.371 : Rod: 0.60 Act: 0.65                               +
12:32:08.371 : Rod: 0.70 Act: 0.76                                  +
12:32:08.371 : Rod: 0.80 Act: 0.88                                     +
12:32:08.371 : Rod: 0.90 Act: 0.96                                  +
12:32:08.371 : Rod: 1.00 Act: 1.06                                 +
12:32:08.371 : Rod: 1.10 Act: 1.15                               +
12:32:08.371 : Rod: 1.20 Act: 1.24                             +
12:32:08.371 : Rod: 1.30 Act: 1.32                         +
12:32:08.371 : Rod: 1.40 Act: 1.40                      +
12:32:08.371 : Rod: 1.41 Act: 1.41                      +

This is what happens when I run just the code and at the beginning of every print.

Unless I'm missing something, I also got that error when working with a 'zeroed' calibration... I think it even still turns up. But I just ignored it, followed the calibration steps, and I can see there is a noticeable difference on print quality.

Have you tried just moving on with the calibration steps and ignoring what I believe is merly a warning due to the 'zeroed' state of the paramters when first executing the M96.. the second M<96 produces the + graph you have presented.

I think you can basically ignore the error and proceed - thats certainly all I do

When I try to compile the Marlin sketch after making these changes, I get the following error message in the Arduino software...

ZWobble.cpp: In member function 'long int ZWobble::InsertCorrection(float)':
ZWobble.cpp:382: error: 'copy_position' was not declared in this scope
ZWobble.cpp:442: error: 'set_position' was not declared in this scope

Is that a problem?

I got the latest SD3 firmware from SD's website, and inserted the changes manually.  I didn't want to revert back to a previous firmware version because I could fix z-wobble, but maybe break something else.  I got the .h and .cpp files from Lawsy's GitHub and followed the step-by-step directions in this thread.  The only thing I can think of is that the copy_position and new_position variables are no longer used by planner.h.

Does Lawsy's fork use all of the current firmware features for the SD3?

Got a link to the latest version?  Are there instructions on what to set in the configuration file? 

I'm only hesitant about this because the printer is working decent already (I just want it to be great), so I don't want to break anything that already works.