Tests with Updated tinyG and tgFX versions – Linux Environment

Home Forums TinyG TinyG Support Tests with Updated tinyG and tgFX versions – Linux Environment

Viewing 13 posts - 16 through 28 (of 28 total)
  • Author
    Posts
  • #5728
    mcgyvr
    Member

    I’m confused…
    So is this a know issue in tinyg? or is this a machine specific mechanical issue (like missing steps due to mechanical issues/binding,etc..) or do they not know yet..

    I’ve seen this and sparkcrafters posts and can’t tell if the cause is known yet or if you guys are just over driving your machines and experiencing missed steps/backlash,etc..

    • This reply was modified 10 years, 7 months ago by mcgyvr.
    #5730
    cmcgrath5035
    Moderator

    I’ll call it still TBD.

    As you can see, my issue is subtle, may be tinyG or hardware or?.
    It becomes obvious when one cuts .07″ slots .1″ apart with good nearby adjacent references, not your normal part milling.

    And it could just be still a sub-optimal set of config settings or just cockpit error on my part

    Stay tuned.

    #5731
    alden
    Member

    Carl – I don’t know what the diagonal mis-alignment issue is but I’m treating as separate from the very-short line work we’ve been doing. I’ll do some more testing to see what I can find.

    #5732
    cmcgrath5035
    Moderator

    Alden
    Do it take it the issue was still there on the screw machine?

    With 421.01 or 421.06?

    Did you see my $ja question in ?

    #5733
    alden
    Member

    The junction acceleration of 2000000 is the correct way to enter it – as to whether 2000000 is a good value for your setup – you have to test.

    The only number that is taken with a million multiplier are the jerks, as these numbers are well over a million. The rule for jerk values is that any number less than 1m is multiplied by 1m internally, and any number over 1m is not. This allows old configs that had all the zeros to continue to work.

    I hope that answers your question.

    I was not able to test on a screw machine last night. Hopefully tonight.

    • This reply was modified 10 years, 7 months ago by alden.
    #5737
    cmcgrath5035
    Moderator

    Thanks – slick solution for jerk multipliers!

    I am contemplating a couple enhancements to my simple test
    A. Modify such that diagonals are drawn first then continue to horizontal movement. Objective – start point for the diagonal will be a G0 X.. Y..
    B. Hand code in a “tool up-tool down” before performing the horizontal to diagonal motion. I am assuming that tinyG might handle that code differently?

    Any other thoughts/suggestions?

    #5741
    cmcgrath5035
    Moderator

    I believe I finally have a design and two sets of test GCode that demonstrate my issue in a testable manner. The design is still like this
    Test design

    A design file may be found here

    In this design, the diagonals are spaced 0.1″.
    When run on my shapeOko, I found that the cut width of the lines should be 0.06″ or a bit more to make the error better viewable.

    One set of GCode, Optimized GCode, is found here.

    This set of GCode seeks to minimize the total tool path for the job and cuts the red line above in sequence, clockwise from the lower left corner.
    This Optimized GCode shows offset diagonals when compared to the free drawn adjacent diagonals.

    The second set of GCode is non-Optimized and found here

    With the optimizer turned off, the GCode generator (in QCADCAM 3.6.4) appears to cut the paths in the order they are drawn by the CAD system, and cuts from the start of the path to the end of the path, as defined in the CAD world. If you run a GCode simulation on this file, you will see that every diagonal and horizontal or vertical path are cut separately.
    The non-optimized GCode runs do not show any offset, as seen with the optimzed code.

    I captured the image below on my flatbed scanner then Gimp’ed to improve contrast.
    Note that the non-optimized runs(right side) appear to be cut with slightly wider lines, most likely due to material surface variation.
    The wider cut actually acts as a visual difference “enhancer”, and still you see no perceptible variation between the diagonals.

    I ran each set of code three times, once with $ja=200,000, again with $ja = 750,000 and finally with $ja=2,000,000. I perceive minor improvement as $ja increases
    Six Runs
    You may find it easier to view this in a downloaded window

    The config file for these runs is found here

    Root cause remains a mystery or work in progress.
    I have not tried the latest edge FW, 421.06.

    I am about to disassemble and expand my ShapeOko a bit.
    I will re-run this set again to see if a possible mechanical cause is implicated.

    • This reply was modified 10 years, 7 months ago by cmcgrath5035.
    #5743
    alden
    Member

    I ran the test on a probotix v90. This is what I got:
    https://farm4.staticflickr.com/3710/13611819744_5f2de23222_o.jpg

    Kind of hard to tell, but it looks like there is some variation on lines, but they are very close. My pen mount on this is pretty bad (ad-hoc), so it might be due to that. I ran this with the dev build.

    Curious what happens with your shapeoko build.

    • This reply was modified 10 years, 7 months ago by alden.
    #5745
    cmcgrath5035
    Moderator

    I would say I see a definite offset in yours picture, but interestingly, I see it as to the upper left, while I see mine as to the lower right….
    Perhaps that has to do with machine dynamics and connections.

    I am also surprised it is a noticeable with fine lines; I seem to need the enhancement factor of broader drawn/cut paths.

    I’ll report back when my rebuild is complete and up and running again.

    Thinking about it, I should probably try to Overlay my optimized and non-optimized GCode, starting from the same origin, with a very fine cut.

    #5746
    cmcgrath5035
    Moderator

    I did run both sets of GCode from the same starting point, one after the other, and was able to see the cutting of the problem diagonals offset from the run of non-optimized GCode, which looks to be “perfect”.

    The resulting image is no more useful than what is already posted, so I won’t bother.

    Back again mid week with results of from my ShapeOko 1.75 (almost a 2).

    #5749
    cmcgrath5035
    Moderator

    OK, rework is complete.
    I now have an oversized ShpeOko2, useful area 290mmx650mm.

    I reran a version of the test detailed in thread 5741 above, results are similar to prior reports.
    test results

    A much more detailed view is here:

    The only way that I find to effectively reveal this is to run with a wide cut relative to the spacing.

    Something is hiding (lurking) in there, I know not what.

    I am moving on to sub-projects that will not be affected by this for now, will keep tabs on performance from time to time to see if this gets resolved.

    #5853
    cmcgrath5035
    Moderator

    Using lessons learned from thread started by member flux, focused on apparent drift in X0,Y0, found here

    I went back to my 2D CAD design tool and can recreate what is happening here.
    For this, I set the design grid in the CAD system to be the same size as a microstep on my ShapeOko, 0.0228mm.
    I drew three parallel lines, separated by 0.1″ (2.54mm), my original design.
    I copied the three lines and pasted. I then offset the center line by One microstep in X and Y .
    On the bottom, you see what CAD draws with 0.7mm stroke.
    On top, same lines, stroke now 2.0mm.
    CAD file is here if interested

    Very similar to my ShapeOko results above.
    CAD drawn results

    This might be a tinyG bug, or it might be an inevitable rounding error.

    • This reply was modified 10 years, 7 months ago by cmcgrath5035.
    #6048
    cmcgrath5035
    Moderator

    I am encouraged to report some success and hopefully the final entry in this thread.
    My tinyG is now running FW build 429.04. I reran my Gcode files using tgFX build 3259.
    Results
    test

    It appears to me that the error resulting motion overshooting the “best’ available x,y by 0.0228mm (the resolution of my ShapeOko setup) has been eliminated.
    If interested, scroll back in this thread to see the original error.
    I first observed this error in the ShapeOko test pattern shown here
    test

    On to bigger and better challenges

    • This reply was modified 10 years, 5 months ago by cmcgrath5035.
Viewing 13 posts - 16 through 28 (of 28 total)
  • You must be logged in to reply to this topic.