Unexpected Motor LED operation

If you told me the machining (engraving) was not working it would be an issue, but the lights are truly advisory. You shouldn't care too much about what's happening. Here's my take on what's going on.

There is no simple "indicator light" function on the stepper drivers, so the LED is just wired across one of the motor phases (A phase). The indexer inside the stepper chip decides exactly where the phase outputs are. There are multiple states the phases can be in and still get correct stepping. The indexer can be set to a known starting point by a HOME signal to the chip, but we don't do this as it's not necessary for proper operation and would take a valuable IO line to do it. So what you are seeing (I suspect) are the indexers on the 2 Y axis chips being out of sync with each other. This does not affect the stepping, but does affect the LEDs.

LEDs - OK, thanks, understand.

I am having some issues with the machine - One particular program (Gcode) seems to somewhat randomly loose track of X axis zero point at the same point late in the run. I have no reason to suspect overheating, everything running cool.
I realize that is a needle in the haystack, so am continuing to debug with various experiments and will be back with something for you to maybe look at when I have better info.

@cmcgrath5035 Please post the file you are having issues with and your settings ($$). If you can link to these on dropbox or some other file site, great. Also, please remind me what kind of machine you are running? If home built then a description would be useful. Thanks --Alden

Alden
I have a ShapeOKO V1, with extended Y axis, Dual Y Motors, Double X, ACME screw upgrade for Z and retrofit to V2 Motor plates.

The job I am running is engraving on plastic laminated material, 4 labels for a boat I am building

Here is what it looks like in "physical space"[image: Selection_173.jpg, no longer available]

The design is in QCAD3, and QCAD/CAM generated the G Code.
I manually added the comments.

What happens is when Gcode line N14120 executes, the tool moves to a position less than X=7.938mm. The termination of that line of code is at the tip of the red arrow above.
Then line N14140 executes, and since it is a relative move, the left end of the lower boarder box (blue arrow)is offset by that amount.
I have run several times, the error is somewhat random but always small.
It is interesting that the end after the word Anchor is aligned with the end above it, as it should be.

GCode is here

https://dl.dropboxusercontent.com/u/50261731/Dash%203%20cy2%20test%200.4%20depth_with%20comments%20.nc

Settings are here

https://dl.dropboxusercontent.com/u/50261731/TinyG_10-17-ShapeOko.log

My next debug will be just to run the 4 "bounding boxes", no text, to see if that makes a difference.

Also, I note that after termination of the program, if I issue a G0 X0 Y0 from the command line (using tgFX), the tool moves to a new (0,0) point that is offset by the same error as the vertical line at the end of the blue arrow.

If you have any other debugging suggestions let me know.

OK, new and interesting additional results.

I created a Gcode set for just the four bounding boxes.
They are now machined from bottom to top, rather than top to bottom.
For some reason the Gcode generates this way.

Here is the Gcode

https://dl.dropboxusercontent.com/u/50261731/Dash%203%20bounding%20only%20.nc

And the parameters again

https://dl.dropboxusercontent.com/u/50261731/TinyG_12-06-140121.log

I ran the Gcode twice and happened to catch the error on the tgFX display, here is a partial tgFX display [image: Frames_only.jpg, no longer available]

On the first run, the lower bounding box drew correctly.
The tool then moved up , Gcode line N140; see red arrow above.
Then for some reason, Arc commands on N160 and N180 got skipped and a vertical line was drawn along X=4.842 rather than rounding back to X=3.175. The bottom of the second bounding box is correct, as is the remainder of the program.

When it completed, I issued G00 X0 Y0 and reran the program, this time it ran correctly start to finish on both the engraved result and tgFX. The two tgFX traces are overlayed.

With the tgFX display actually catching the error (via the status updates), I am now more suspicious of a TinyG computation error. I am hoping you will see something obvious or non-optimum in my settings that could be the culprit.

Here is an additional bit of information/results.

I ran this GCode File

https://dl.dropboxusercontent.com/u/50261731/ShapeOko_Calibration_Pattern_01b_cjm2_complete_2.nc

Same TinyG parameters as previous post

https://dl.dropboxusercontent.com/u/50261731/TinyG_12-06-140121.log

With these results[image: 2013-12-07T15t04t27_1_v1.JPG, no longer available]

I am overall impressed with the results, with the exception of the highlighted areas, Some of the diagonal lines are not properly spaced and one arc of the side-by-side laege diameter circles has a slight error.

I like this particular test because the GCode draws in a rather random fashion, so and errors such as belt slips/skips would be very obvious.
The job runs for 15 minutes plus, and from start to finish the intersection precision is very good, except in those two areas.

Comments and suggestions welcome.

Thanks for the input - frankly I don't think so but it could be belt related.

Primary reason I don't think so is that the problem, when it appears, is always in the same area of the workpiece. There are several identical areas on the design, not at all clear why backlash would not be a somewhat random event or, perhaps, very unique intersection.

I would particularly expect to see more areas on the last piece I posted, the SpapeOko Test, since the cutting is VERY random (not well ordered) so I would expect to see issues in more locations.

I am using the stock MXL belts, where does one find the GT2?