- This topic has 27 replies, 3 voices, and was last updated 10 years, 7 months ago by
.
-
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..
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.
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
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.I 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.
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.
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.
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 interestedVery similar to my ShapeOko results above.
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
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
- You must be logged in to reply to this topic.
