TinyG edge drifts on series of small movements

Home › Forums › TinyG › TinyG Support › TinyG edge drifts on series of small movements

Tagged: , ,

Viewing 15 posts - 31 through 45 (of 69 total)
1 2 3 4 5
  • Author
    Posts
  • April 28, 2014 at 8:29 pm #5859
    cmcgrath5035
    Moderator

    flux – I got the impression that your original short test.gcode was a path extracted from test.7.gcode.
    That short path had some very short segments in it, if you want to focus on that path for the evaluation of ‘epsilon’ impact.
    In fact, looking at test.7.gcode in my simulator, there seemed to be a lot of discontinuties and “sharp” corners, obviously smoothed out somewhat by the gcode generation process.

    May 6, 2014 at 3:11 pm #5884
    alden
    Member

    Flux, Carl – can you please post test.7.gcode – or any other files that illustrate the problem? Please also let me know your build number and settings, if different than what you posted earlier in this thread.

    No guarantees about when I can get to this. Soon, I hope. –Thanks

    May 6, 2014 at 3:34 pm #5885
    flux
    Member

    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 :).

    May 7, 2014 at 1:22 am #5886
    flux
    Member

    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.

    May 11, 2014 at 7:57 am #5898
    alden
    Member

    Flux – Are you getting good results from 412.11, just not master and earlier edge builds? It seems that the gcode7 test still fails.

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

    (The last few weeks have made it impossible to spend enough time on this but I’ve finally got some time to pay more attention on a regular basis).

    • This reply was modified 10 years, 6 months ago by alden.
    May 11, 2014 at 9:48 am #5900
    alden
    Member

    Flux – I had a chance to run your files. You found a nice “perfect storm” test for the short-line issues we’ve been working on. I’m sure it’s not much consolation, but thanks for that! I’m getting much much better results with changes that we made in dev. Please check the email with which you registered for this forum for a note I sent you about connecting up directly, or try me at the synthetos gmail address. I’d like to try a few experiments if you have time.

    May 11, 2014 at 10:40 am #5901
    flux
    Member

    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.

    May 11, 2014 at 11:37 am #5902
    flux
    Member

    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).

    May 12, 2014 at 1:47 am #5904
    flux
    Member

    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.)

    • This reply was modified 10 years, 6 months ago by flux.
    May 12, 2014 at 3:54 am #5906
    flux
    Member

    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..

    May 12, 2014 at 12:39 pm #5907
    flux
    Member

    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 :-).

    May 14, 2014 at 12:49 pm #5908
    dataway
    Member

    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.

    May 14, 2014 at 1:54 pm #5909
    dataway
    Member

    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 ..

    May 15, 2014 at 7:29 am #5910
    cmcgrath5035
    Moderator

    dataway – You did not say what version of tgFX you have loaded.

    If I assume you loaded tgFX build 3256 to run with FW 412.01, your first post, then I am not surprised that things did not work when you installed FW 380.08 into tinyG. tgFX build 3256 requires FW 412.01 (or later) and will attempt to download and install 412.01 it. And, by the way, earlier versions of tgFX (<build 3256) don’t work well with 412.01.

    Drift issue- The drift issue highlighted by Flux’s test cases resulted from multiple extremely short segments repeatedly changing direction. Alden has been working the issue and appears to have a code tweak in a Dev build for tinyG, 426.02. I have not seen that build posted yet, most likely still being more thoroughly tested.
    When you say “large circle”, how large?
    Does Vetric Aspire generate GCode with arcs, or just continuous X,Y short segments?

    It is also unclear if you ran your ShapeOko 2 with GRBL, with good results, before migrating to tinyG.

    If you can, place a copy of your GCode in a Dropbox (or similar ) and post a link to it here. Additionally, a listing of your tinyG config parameters in a similarly linked file may be helpful.

    May 15, 2014 at 4:05 pm #5912
    dataway
    Member

    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

  • Author
    Posts
Viewing 15 posts - 31 through 45 (of 69 total)
1 2 3 4 5
  • You must be logged in to reply to this topic.