Forum Replies Created
-
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.
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.Foreword: I believe these results are consistent with the prior observations and results in this thread, this test is just a bit simpler to run.
Here is what I think is a definitive test case with some results
GCode isConfig is https://dl.dropboxusercontent.com/u/50261731/ShapeOko_Tests/2014-03-26_19.33.00-tinyg.conf
I created the GCode once again on QCAD. Here is the dxf if someone wants to play with it
My goal was one or two diagonals cut immediately after horizontal or vertical runs. Drawing it was easy, coaxing the GCode Generator to create the code I wanted was a challenge.
The red path below is cut continuously from the lower left and has 135deg right turn and a 45 degree left turn into the diagonals. The balance of the lines are “tool up-move to new location-tool down-cut” sequences individually.
I ran the code (it’s fairly fast) several times on the same piece of material.
I ran it at $ja=2,000,000 and $ja = 200,000.The prescribed cut depth was 0.4mm, again using my 60degree engraving bit. At -0.4mm, the cuts look reasonably good/accurate. By setting a new zero, with a negative adjustment to z=0, I was able to cut deeper, therefore wider paths, and amplify the position discrepancy. Also Shown below are cut depth = -0.6mm, where the issues become obvious to the human eye.
I scanned my piece of test material then Gimp’ed it (Photoshop for you Windows types) for contrast and color balance.
The design diagonal spacing here is 0.1″ between the parallel lines.
I’ll add the caveat that for someone trying to reproduce these results, at this level of precision the uniformity of the workpiece being cut is a significant issue. There is no guarantee that all four of these cuts are actually at the same Z=0, this is inexpensive primed MDF. I think we are all familiar with Z axis zeroing issues, using engraving bits as I am amplifies those issues, but here makes diagnosis much easier.Summary:
1. I better understand why some of these issues come and go over time – as I revise the Test pattern designs to add features, etc, new GCode gets generated that may or may not include what seems to be the problematic transitions. And, the problems are really only visible under the right conditions with multiple reference lines in close proximity.
2. From these tests, I would conclude that $ja=2M helps, but does not resolve. I believe that is what Alden is tackling.Also
1. I used tgFX build 3009 as GCode sender on this run. Now that I better understand what is going on, its seems up to the task. The Preview window, in-process drawing, does seem to get confused about where it is at times; I think Riley has already seen that as well.
2. I still can’t get shift+ctl+x (ctl-X) to cause a tinyG reset from the tgFX CLI. The GUI RESET button on the GCode Tab does work.$boot=1 vs. ctl-X : I guess I should have realized that, but didn’t.
Makes sense. I’ll retry ctl-X (from tgFX; I know it works from PuTTY).
There seems to be states when things typed into the tgFX command line don’t go anywhere/do anything.“What Fixed Calibration pattern?”: I wish I knew that, I hate it when problems just ‘disappear’. I have had problems with that area of the pattern since day 1. All the lines get cut(milled), the end points are on edges of the square, yet the spacing between 45deg lines has clearly been uneven to the naked eye. I actually built a separate test pattern for that, four squares plus a bunch of arcs, just to exercise the tinyG, which is here
It has always run OK, so more confusion than answers there.
I had hoped that FW 412.01 would clear up this Calibration Pattern problem but it did not. It also did not fix the somewhat random occurrences of what I call the mangled “D” in my engraving run Dash
Riley has, for a while, suggesting I try CoolTerm for GCode sending. I saw a reference on either this forum or the ShapeOko forum to using the plink solution on Linux for GCode sending and decided to try it, with good success.
I have, in a couple instances, compared GCode to the streaming position codes captured in the plink log file. Observable, but not incriminating, accumulated (?) math errors. That is tough analysis to do, but I prefer more data to less data, I suppose.So the evidence so far seems to implicate tgFX GCode sending as the cause of my issues, although I don’t understand how that could happen.
While I have your attention – what do you suggest as a “good” value for $ja for ShapeOko and FW 0.97build 412.01? I am currently running with $ja=2,000,000 (commas added here for clairty)
We are making progress!
