Tests with Updated tinyG and tgFX versions - Linux Environment

Wow. Great writeup. Thanks for the attention to detail. This will take a bit to digest, but a few quick comments.

- For reboot (reset) have you tried sending a control x? (^X)? That’s the software way to reset the board. The $boot command is intended as a way to enter the boot loader for reflashing, not as a way to reset the board.

- What do you think fixed the calibration pattern? Do you attribute this to communications, tinyg Gcode handling, other? I'm curious how this got "fixed" and would like to establish root cause if possible.

$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

https://dl.dropboxusercontent.com/u/50261731/ShapeOko_Tests/ShapeOko_Diagonal_Test_Arcs_test3.nc

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

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!

I'm running $JA at 2,000,000 for Shapeoko, but it might be high. I'd try dropping back to 200,000 and see if you get different results.

We've been funding a number of cases lately where users are having problems that appear to be communications or firmware that turn out to be settings related. They just go away once the settings are dialed back. I wish there were a silver bullet for this, but I'm afraid there is not. And there are a lot of parameters. Here are some things we are trying.

- Some parameters push TinyG into operating limits that are on the edge of the processor to handle. For these we are attempting to chase down root causes and putting in "traps" to report if these conditions are hit. These will report out as exception reports (ERs). In some cases we can also optimize the code so it has a bit more headroom, but that never actually gets rid of the case, just moves it.

- We are contemplating more input validation for those cases that can be detected on the front end. For example, we really should have limits or warnings on extremely high jerk values. Axis feed rate limits (xFRs) should not be higher than velocity max for that axis. For example.

If you can think of other things we can do to help users and setup I'd be interested. We appreciate your hard work and contribution.

I fully understand your observations on "firmware/communications" vs settings and agree that is likely a major contributor to "..it doesn't work...".
Of course, the challenges are A> a zillion parameters and B> Difficulty predicting what a particular setting change might do and C> Sometimes 30 minutes to see an error on the machine!.

My desire for a bit better capture of configs in a manageable manner stimulated my interest in the Python Grabber over on Google groups.
tgFX is a useful viewer(for what it views), but it only works when connected to tinyG.
I built my spreadsheet for the purposes of comparing among sets from the comfort (and horsepower) of my desktop, rather than the workshop.
This helps me see numbers and differences, but does nothing for better understanding of what might happen if....."

Is there any way (a trap, a message, etc) of determining if tinyG experiences a computational error or hits a boundary or similar?
Just knowing it was happening would be a plus, knowing what Line of GCode, etc would be even better.

Is there a simulation engine for the chip that could be useful here?

I find the log files being returned from tinyG, and recorded during my plink sessions to be interesting and might be useful here, but of course they are a lot of data.
My programming skills are not up to the task, but it would be interesting to have a "Process analyzer" that read in GCode and the resulting status stream and looked for significant deviations in "desired action" vs. "what the program told the servos to do". Perhaps a good assignment for a local Engneering School student?
I am only guessing that there is useful information hiding in that haystack (or pile of...).

So, to be specific using my files,
Here is GCode file:

https://dl.dropboxusercontent.com/u/50261731/ShapeOko_Tests/ShapeOko_Calibration_Pattern_01b_cjm4.nc

Here is what tinyG did with it:

https://dl.dropboxusercontent.com/u/50261731/ShapeOko_Tests/2014-03-29.14.37-file_calibration.log

Assignment: Create a program to compare the input-output results and flag issues.(An executive level requirements document :) )

I'm assuming there is probably useful results to be had here.

Whether it would catch 10% or 90% of the normal failures is T.B.D.

And, I just thought of an experiment I plan to run.
1. Select a GCode file.
2. Run it on the ShapeOko, capturing file.log1
3. Run it on the ShapeOko, capturing file.log2

How identical should I expect the files to be?
I sort of expect some differences due to due to status report skew.
But perhaps that can be more easily filtered out.

Then, for kicks, make a change like $ja=2,000,000 to $ja=200,000 and compare file.log3 to the others.

Hmmm, I'll report results a a few days

Sounds like a very useful tool. Perhaps you could open a page on the TinyG wiki for the requirements. That would be useful for discussion and ultimately serve as documentation. Let me know if you can't edit for any reason.

OK, I ran my experiment last night, I am still sifting thru the mounds of info.

I have four log files
$ja=2M Run1
$ja=2M Run2
and
$ja=0.2M Run3
This log not particularly useful, as the status messages are in text
mode, others are json. Again, probably my lack of precision procedure
$ja=0.2M Run4

Some initial observations:
1. As expected, the asynchronous nature of the status reporting results in some skew in the precision detail of the results
2. There is a different amount of "stuff" at the top of each log file. It appears to be json reports of some sort. The difference could likely be that my procedure was not adequately identical for each run for things like: I hit reset on tinyG, but did I wait long enough for the reboot process to complete?
3. Runs 1 and 2(jerk=2.0M); once the GCode processing begins, are nearly identical, 11061 lines in the files vs 11054
4. By comparison, Run 4 (jerk=0.2M)has 11861 lines in the log.
I expect Alden will say
"That is expected, higher jerk ramps velocity more aggressively, resulting in overall faster job execution for runs 1 and 2".

AND, in other news: I find that, in fact, I still am seeing the diagonal line spacing "skew"(inaccuracy) that I thought was gone. It's return (useful information, I believe) came about as a side effect of some less than optimal material I am cutting: I am using simple primed MDF board, not the most uniform surface in the world but cheap and expendable.
I am cutting with a 60deg engraving bit, so the cut line is wider as the bit penetrates deeper. On runs with wider cuts, the remaining uncut space between diagonals becomes narrower; it is easier for the eye to see the difference between 1mm and 1.1mm than it is 2mm and 2.1mm, etc.

I have a revised theory, see next post

Carl - to your observations

1. SR Skew. Yes. This is expected. What you should see, however, is the final status reports at a STOP should line up exactly as these report final conditions.

2. The "stuff" at the start is a collection of things. There are one or 2 header lines reporting the system revision. If a new settings file is present (after a load) it's 2 lines, in most other cases it's one. They you may see an initial status report with a bunch of values. Since it's the first one every value is reported as the filtering starts once a value is reported.

3/4. That is expected, higher jerk ramps velocity more aggressively, resulting in overall faster job execution for runs 1 and 2

As for diagonal skew - we did a bunch of stuff over the weekend (and over the last few weeks) to chase down some inaccuracies we were seeing. In high probability these will take care of what you are seeing. Experimental code is out on the dev branch with these changes. We will be validating operation with tgfx this week and will push to edge as soon as we are comfortable with it.

You are welcome to grab the dev branch, of course, but if you use dev you are on your own, pretty much. You will need to clone the project, set up Atmel Studio 4 or 6, compile and test. Project setup should all be documented on the wiki. The changes in dev are too frequent to post hexes - and frankly, not all dev builds work or are even intended to work.

I will comment on your next post when I see it.

Updated theory: Speed (of job) kills.

Here is the GCode I ran

https://dl.dropboxusercontent.com/u/50261731/ShapeOko_Tests/ShapeOko_Diagonal_Test_Arcs_test3.nc

This GCode was created by the QCAD code generator, you will observe that cutting is somewhat random, cuts some diagonals as continuations of pure horizontal or pure vertical movement, while others are "tool up-move-tool down-cut diagonal-tool up-....."

Load it into your favorite GCode analysis tool (I used JCNC) and step thru the GCode starting with line N550, The box that first caught my eye.
I'll summarize:

Tool up
Go to a point A(0,0)
Tool Down
Cut to a point A(1,0)
Cut to a point A(1,1)
Cut to a point A(0,1)
Cut to a point A(0,0)
[We now have a square]
Cut to a point A(1,1)
[We now have a square with a diagonal lower left to upper right]

The Sequence Cut from A(0,1) to A(0,0) to A(1,0) says "cut continuously the left side then change direction 135deg and cut the diagonal".

I believe that only a machine with zero mass(and therefore zero momentum to deal with) and infinite dynamic precision could do this 100% correctly. One instance of such a machine is a computer program plotting the movements on a monitor, which sort of defines the desired result.

I am theorizing that this code

Tool up
Go to a point A(0,0)
Tool Down
Cut to a point A(1,0)
pause for machine to settle
Cut to a point A(1,1)
pause for machine to settle
Cut to a point A(0,1)
pause for machine to settle
Cut to a point A(0,0)
[We now have a square]
pause for machine to settle
Cut to a point A(1,1)
[We now have a square with a diagonal lower left to upper right]

Would run much slower but more closely approximate the desired cut pattern.

Next I plan to hand code some GCode like this to continue the investigation.

Ah so, Alden, you commented while I was typing.

I think we are on a very parallel track, but you actually know what you are doing so are more likely to hit the goal with greater precision.

I will do my additional test, but knowing where we (YOU !) are heading, I'll wait for a tinyG.hex to show up rather than be impatient.

We also need to get this to Sparkcrafter and see if this addresses his Z axis issue.

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 is

https://dl.dropboxusercontent.com/u/50261731/ShapeOko_Tests/ShapeOko_Diagonal_Test_4_OptY.nc

Config 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

https://dl.dropboxusercontent.com/u/50261731/ShapeOko_Tests/ShapeOko_Diagonal_Test_4.dxf

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

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.
[image: ShapeOko Test4 ja=0.2M.jpg, no longer available]

[image: ShapeOko Test4 ja=02.0M.jpg, no longer available]

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.

I'm running this tonight. I'm wondering if some of the mis-alignment might be backlash in the belt mechanism, so I want to see if this behaves on a screw machine. I'll run this on a Probotix V90 that I use for test.

As for the reset, it's control x (ctrl+x) - no shift. Sorry if my post was misleading,

Here's an experimental hex file with the changes. You will need to update settings for your system
https://www.dropbox.com/s/tvz765z7b58kbs6/tinyg_421.06_dev.hex

Screw vs. Belt - that will be interesting info

ctl-x vs ctl-X I tried both, will verify again. It should be just ctl-x, with no CR needed, correct?

I'll try your 421.06 Wed or Thurs, I am away from my machine for a couple days. What do you mean by "update settings?" or will it be obvious when it gets loaded? Or is there a new .config file for tgFX to load?

Alden, I just noticed something in my configfile

https://dl.dropboxusercontent.com/u/50261731/ShapeOko_Tests/2014-03-26_19.33.00-tinyg.conf

In the version I posted,
[ja] junction acceleration 2000000 mm

But
[xjm] x jerk maximum 5 mm/min^3 * 1 million

Is this correct for 412.01 ?, or should it really be
[ja] junction acceleration 2 mm/min^3 * 1 million