Tests with Updated tinyG and tgFX versions - Linux Environment page 2

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.

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.

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 ?

https://www.synthetos.com/topics/tests-with-updated-tinyg-and-tgfx-versions-linux-environment/#post-5727

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.

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?

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
[image: Screenshot, no longer available]

A design file may be found here

https://dl.dropboxusercontent.com/u/50261731/ShapeOko%20Test4/ShapeOko_Diagonal_Test_4_in_mm.dxf

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.

https://dl.dropboxusercontent.com/u/50261731/ShapeOko%20Test4/ShapeOko_Diagonal_Test_4_in_mmOptY.nc

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

https://dl.dropboxusercontent.com/u/50261731/ShapeOko%20Test4/ShapeOko_Diagonal_Test_4_in_mmOptN.nc

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
[image: Test4-mm-6 runs_2_Summary.png, no longer available]
You may find it easier to view this in a downloaded window

https://dl.dropboxusercontent.com/u/50261731/ShapeOko%20Test4/Test4-mm-6%20runs_2_Summary.png

The config file for these runs is found here

https://dl.dropboxusercontent.com/u/50261731/ShapeOko%20Test4/2014-04-03_14.00.05-tinyg.conf

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.

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.

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.

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

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.
[image: ShapeOko2_Testsm.png, no longer available]

A much more detailed view is here:

https://dl.dropboxusercontent.com/u/50261731/ShapeOko%20Test4/ShapeOko2_Test.png

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.

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

https://www.synthetos.com/topics/tinyg-edge-drifts-on-series-of-small-movements/

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

https://dl.dropboxusercontent.com/u/50261731/ShapeOko%20Test4/Design%20with%20offset.dxf

Very similar to my ShapeOko results above.
[image: CAD Synthesized Results.jpg, no longer available]

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

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
[image: 2014-05-30T18t55t00_v1.JPG, no longer available]

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
[image: Calibration plus Dash run_v1editsm.jpg, no longer available]

On to bigger and better challenges