- This topic has 9 replies, 4 voices, and was last updated 11 years ago by
.
-
Nearing 8 months ago I had my Z axis stall on with my old stepper drivers which were only 30 volts and weren’t enough for my machine.
In the end the machine was was cutting 1″ thick MDF in one pass with a .25″ endmill, nicked my Y axis slides, and the acme drive screw. Everything is working nicely with some sanding and buffing, however, I’m if stalls are bad I can’t think of what a controller fault could do !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”
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
Settings are here
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
And the parameters again
I ran the Gcode twice and happened to catch the error on the tgFX display, here is a partial tgFX display
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
Same TinyG parameters as previous post
With these results
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.
- You must be logged in to reply to this topic.
