Home › Forums › TinyG › TinyG Support › Tests with Updated tinyG and tgFX versions – Linux Environment
- This topic has 27 replies, 3 voices, and was last updated 10 years, 5 months ago by cmcgrath5035.
-
AuthorPosts
-
April 1, 2014 at 11:05 am #5728mcgyvrMember
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.
April 1, 2014 at 2:29 pm #5730cmcgrath5035ModeratorI’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.
April 1, 2014 at 8:22 pm #5731aldenMemberCarl – 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.
April 2, 2014 at 7:22 am #5732cmcgrath5035ModeratorAlden
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 ?
April 2, 2014 at 7:32 am #5733aldenMemberThe 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.
April 2, 2014 at 7:53 am #5737cmcgrath5035ModeratorThanks – 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?
April 3, 2014 at 3:28 pm #5741cmcgrath5035ModeratorI 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
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
You may find it easier to view this in a downloaded windowThe 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.
April 3, 2014 at 6:37 pm #5743aldenMemberI ran the test on a probotix v90. This is what I got:
https://farm4.staticflickr.com/3710/13611819744_5f2de23222_o.jpgKind 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.
April 3, 2014 at 9:48 pm #5745cmcgrath5035ModeratorI 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.
April 4, 2014 at 10:08 pm #5746cmcgrath5035ModeratorI 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).
April 8, 2014 at 11:00 pm #5749cmcgrath5035ModeratorOK, 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.
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.
April 28, 2014 at 12:32 pm #5853cmcgrath5035ModeratorUsing 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 interestedVery similar to my ShapeOko results above.
This might be a tinyG bug, or it might be an inevitable rounding error.
- This reply was modified 10 years, 6 months ago by cmcgrath5035.
May 30, 2014 at 7:56 pm #6048cmcgrath5035ModeratorI 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
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
On to bigger and better challenges
- This reply was modified 10 years, 5 months ago by cmcgrath5035.
-
AuthorPosts
- You must be logged in to reply to this topic.