TinyG edge drifts on series of small movements page 3

Sure thing. So here are the test cases I've used:

This is the original test case where I found the issue. It has been accelerated (F2000) for faster runtime. The problem occurs on edge/412.10/412.11 and I imagine on master as well although it hasn't been exactly this I've run on this:

http://www.modeemi.fi/~flux/tinyg/test.7.gcode

This is a short part from it that also reproduces the error at least on edge/412.10, didn't try it on master:

http://www.modeemi.fi/~flux/tinyg/test.gcode

For these tests I have used http://www.modeemi.fi/~flux/tinyg/tinyg-settings.txt and http://www.modeemi.fi/~flux/tinyg/tinyg-settings-2014-04-27.txt , both producing pretty much the same results.

These seem to fail on master but they work on edge/412.11:

Numerous small circles: http://www.modeemi.fi/~flux/tinyg/circles.gcode

A small zigzag: http://www.modeemi.fi/~flux/tinyg/segments.gcode

Good luck :).

Oops, when I mentioned edge version 412.10, I always meant 412.01!

I should add that test.7.gcode typically drifted by around x:-10 mm while test.gcode much less, around x:-1 mm. (Both probably drifted in y as well but X is easier to notice.) The tests that work on edge but failed on master drifted about x:-10 mm as well.

Hello,

I replied to the email you sent me, I hope you were able to receive it :).

test.7.gcode still fails for all firmwares I have tried. Master (can't recall the revision, but latest as of two weeks ago or so), 412.10 and 412.11.

Are there any other problems in 412.11 that you are aware of?

Well, while testing this I'm -pretty- sure I maybe have seen a lone "moves to completely to the other direction" problem. But I don't have a reproducible test case for this.

Another more reproducible issue (but no reproduction test case) is that if I re-home one axis (say, with G28.2 Z0) the following moves may move to the opposite direction. (Ie. G91 Z-5 moves up, not down.) This is fixed by homing the rest of the axis as well. This is quite an interesting case, I should look into the exact reproduction recipe.. It could be that the probing command is related, as I use G38.2 quite often.

Here's the original test file with Z-lifts: http://www.modeemi.fi/~flux/tinyg/test.1.gcode . If someone is testing this with non-default coordinate system (as I am) be aware that the file has M02 at the end of the job (end job, reset coordinate system).

All the test cases I mention here are available at http://www.modeemi.fi/~flux/tinyg/ .

As I told in the email, after the success with test.1.gcode on dev/426.02 I tried test.20.gcode and noticed that there is a small negative X drift visible after the test run, < 1 mm.

So next I executed test.1.gcode but with the F2000 replaced with F100, so very slowly, to see if speed is a factor. It still worked fine. Then I removed the Z moves from test.20.gcode and increased the speed to F1000, but the drift persisted, so it seems speed is not the issue here (no clicking noises either). The modified test case is available at at test.21.gcode .

Technically the difference between test.0.gcode and test.20.gcode could be that test.0.gcode has been generated with epsilon 0.00254 mm (meaning the generator creates no shorter lines than this) and test.21.gcode has been generated with epsilon 0.05 mm. I have not verified if the setting actually works as described. But it's interesting if the ultra-short lines now work but it's the still-quite-short lines that make the effect visible.

Next I took notice of the curious fact that it's always the X axis that is off and it's (almost?) always off to the negative side. So what if we swapped the axis? So I swapped X and Y from test.21.gcode for test.22.gcode and tried again (twice). And indeed, it's now the Y that drifts to the negative Y. (I also notice that there might be a veeery tiny X drift as well; there may have been such a similar Y drift with test.20.gcode as well but I could easily have missed it.)

I did some more testing.

test23.gcode: converted test.21.gcode by flipping negative X coordinates to positive ones, all coordinates are positive. No drifting.

test24.gcode: converted test.22.gcode by flipping negatiev Y coordinates to positive ones, all coordinates are positive. No drifting.

Then I executed test.24.gcode again, but at another coordinate system at

[g58x] g58 x offset            -220.000 mm
[g58y] g58 y offset            -200.000 mm
[g58z] g58 z offset             -82.000 mm

where as the original coordinate system had been

[g59x] g59 x offset            -170.000 mm
[g59y] g59 y offset            -200.000 mm
[g59z] g59 z offset             -82.000 mm

Interestingly, running test.24.gcode in the coordinate system 5 (G58) resulted in drift. This would suggest maybe the machine has trouble moving at that point? But on the other hand, how both Y and X would have the same trouble at that point and both not have it at another? Alternatively it could suggest there is some indeterminism at play. I have not yet hooked up the microscope to get better readings on the drift.

I did another run of test.21.gcode at

[g58x] g58 x offset            -120.000 mm
[g58y] g58 y offset            -200.000 mm
[g58z] g58 z offset             -82.000 mm

and I saw no drifting. Could it just be the machine or firmware..

Uh oh,

It seems my belts had loosened (probably damaged) while I was working on wood all Saturday, so if those results cannot be reproduced, I'm perfectly willing to believe that that's the end cause :).

So I'm pretty sure that in fact the dev/426.02 indeed is the final fix for this issue!

While it seemed strange that the issue affected both my X and Y axis, it is quite possible that they are both similarly worn out, which would explain why moving the working area (with coordinate systems) seemed to remove the issue. (Switching X/Y coordinate signs altered the work position as well.)

I don't have yet enough belt for replacing all the belts - I'll do it in one go - so I think I may not be able to proper testing until they arrive (earliest next week, the upper bound of the ETA is next month). But, I'm now seeing so small difference (probably in the range of <0.5 mm) that I'll still try with the PCB.

Thanks for all the hard work :-).

I am very interested in this issue as I have just setup my Shapeoko 2 with the tinyG controller replacing my GRBL controller and I am seeing this drift issue in both the +-X and +-Y axis and by my measurement it is up to 7mm of drift. I am milling a larger circular object and on each clearing pass the drift happens and the circle is offset. I use Vectric Aspire to generate my tool paths and am running Firmware V412.01 on my tinyG using tgfx to stream my gcode.

also wanted to add that I am using a new V8 of tinyG which had 412.01 loaded on it already. I attempted to load 380.08 which loaded fine and after making all my settings for my shapeoko 2 the motors would not function just sit and hum with the 412.01 motors run fine, I don't understand the issue there but I am back on 412.01 now. Very Frustrating ..

Thanks for the reply..

To address your questions:

When I tested with tinyG V380.08 I installed tgFX Build 2072 I then had the issues with the motors and reverted back to tinyG V412.01 and tgFX Build 3256

Here are my tinyG settings:

https://dl.dropboxusercontent.com/u/3848551/tinyg%20settings.txt

I have tested 2 post processors with aspire that I received in this forum one was for standard gCode and the other with ARC. Here are my gCode files :

Standard gCode:

https://dl.dropboxusercontent.com/u/3848551/3D%20Roughing%20std%20gcode%20mm.tap

ARC gcode:
https://dl.dropboxusercontent.com/u/3848551/3D%20Roughing%20tinygarc.tap

Both of these still had the drifting issue when attempting to run the jobs.

The circle was approximately 9" in Diameter.

When using GRBL the jobs ran perfectly as I ran multiple of these signs for gifts..The reason for me changing from GRBL is my Z Axis driver on the GRBL shield failed so I thought I would take my chances with tinyG ...

Thanks for reviewing this issue it sounded like the same thing to me...but can open a new thread in this Forum if needed.

Regards

John