I've finally gotten my CNC mill up and running (again), but I seem to be having an issue with TinyG arbitrarily adding movement in the x-axis. If I didn't know any better I would say it was backlash, but the measured backlash is minimal (~0.0005in).
I designed up and posted a simple operation to create 4 triangular thru-pockets within a rectangle in fusion. The diagonals should be uniform in thickness. When the operation is complete, the result is not as designed, but only seems to affect the x-axis. On the two vertical cuts, for instance, it appears to be cut on the diagonal relative to the previously cut edge. If it were a tramming issue, both the previously cut edge and this vertical would still be parallel. The measured difference is 0.5mm.
There's other issues with the operation, but all seem to be related back to this x-axis issue. I'm thinking there might be some bad-mojo occuring between the G code provided by fusion in some of the operations (namely 2D contour and adaptive operations).
The following options are what is set in the fusion post dialogue:
(Built-in) Allow helical moves No
(Built-in) High feedrate mapping Preserve Rapid Movement
(Built-in) High feedrate 0
(Built-in) Maximum circular radius 1000
(Built-in) Minimum chord length 0.25
(Built-in) Minimum circular radius 0.01
(Built-in) Tolerance 0.002
Optional stop Yes
Preload tool No
Separate words with space Yes
Sequence number increment 5
Start sequence number 10
Use sequence numbers No
Use active spindle Yes
Use G28 No
Use M6 No
Radius arcs No
Write machine Yes
Write tool list Yes
What is needed from me to help me troubleshoot this issue?
I have no Fusion knowledge and some of the terminology you use is not familiar.
I have seen similar issues reported when folks were (generically) doing 2D profiling.
Your issues may be related to an arc rendering precision issue, if your G code has a lot of short XZ or YZ G2 or G3 commands.
Is your Gcode running in inch mode?
Try regenerating it in mm mode, that often helps
I'll assume you are running tinyG FW 440.20, that is the most tested version.
There is no complete 'fix'.
First I would suggest you run an experiment to verify this is the root cause.
The only known full(?) fix is to tell Fusion to not use G2 or G3 arc commands, which causes it to generate very short G2 linear moves.
This slows down the milling process and can result in very large Gcode files, but does work.
I am not sure how you set Fusion to do this.
If an all-linear-move file is way too big, perhaps you can generate a sub set of your complete job to test, first with G2/G3, then with just G2 moves.
Update (since my last one didn't seem to take for some reason): Swapping out G2/G3 for G1 movements fixed most of my problems. The other bit was increasing the min radius to Cutter Diameter/2 + 0.01in.
This topic is from the original forum (November 2018). Your reply starts a new discussion linked to it.