Rotary VCarve + CV = Clunk

[spinningwood]

I am running tests on the CNC Lathe I just built. Some background info:

I use Aspire and Mach3.
Motor tuning is as follows:
A = 18810 velocity and 3151 acceleration (in degrees / min)
X = Z = 200 velocity and 50 acceleration (in inches / min)
CV = on
Set CV Dstance Tolerance = not checked
Set Stop CV On Angle > = not checked
Look ahead = 200

The good news: 3D carving works great. Fast and smooth cutting.

The less good news:

Yesterday I tried vcarving (projected onto 3D model) and ran into a problem. When mach tries to execute the G00 move to safe Z I get a clunk on my Z axis (probably losing steps on the stepper). If i run the exact same toolpath on a flat surface (x, Y, z instead of x, A, z) (using the appropriate post processors), it runs without any clunking. The problem only seems to happen when I'm using the rotary (it's not the A motor clunking). Here's a code snippet. I get the clunk on line 690.

N680 G1 X0.0965 A-19.6482 Z0.1927
N690 G00 X0.0965 A-19.6482 Z0.4050
N700 G00 X0.0965 A-30.9263 Z0.4050

After some discussion on the Mach Support Forum, it seemed like a blended acceleration / velocity might be my problem, with Mach treating the rotary degree per minute numbers as though they were inch per minute. I found that the following settings eliminated the problem for me.

Dropped A axis to 9000 (degrees/min) velocity and 1000 acceleration.
Dropped X/Z axes to 150 (inch/min) velocity and 17 acceleration.
CV on.
Set CV Dstance Tolerance = 1
Set Stop CV On Angle > = 89

While it stopped the problem, things run slower this way.

I received a suggestion to add a "G4 P0" zero length dwell before the G00 moves (between line 680 and 690 in the code above) instead of the adjustments above. I returned everything to my original speedy settings and manually added the G4 P0 before all the G00 moves to safe Z (there are a bunch of them in the vcarving toolpath I'm using). Clunking is gone and I'm able to run at my original speedy settings. This seems like a better solution than dumbing down the machine with slower speeds and CV adjustments.

This leaves me with other questions:

1) is there an option in Mach that would accomplish the same thing as manually putting the G4 P0 before the G00 code?

2) is there a way to modify the Aspire Mach wrap post processor to insert a G4 P0 before a G00 (and probably when I have a G1 with a direction reversal)? I could probably write a little program to do this, sort a post post processor, but it would be one less step to possibly forget (or screw up) if the post processor could do it.

3) Has anyone here experienced anything like this and found some other way to solve it?

I know this is more of a Mach issue than a Vectric issue and I will continue to discuss the issue on the Mach support forum. I'm just taking a chance that somebody here has already been down this road and can share a solution.

Thanks for reading. All thoughts / suggestions welcome. Sorry for the long post. I'm running Version 3.042.020 of Mach.

Ed

[spinningwood]

The answer to my question 2 "is there a way to modify the Aspire Mach wrap post processor to insert a G4 P0 before a G00 (and probably when I have a G1 with a direction reversal)?" is yes. It was pretty easy.

Adding "[N] G4 P0" to the rapid move section (before the G00 definition) does it. Unfortunately it does it for all G00 moves, not just the problem ones. I does nothing for the reversals on the x axis that are G1 moves. I don't see any way to have the processor put out a G4P0 before a reversing move. Like in this code:


N370 G1 X-0.7127 A-177.3830 Z0.1891
N380 G1 X-0.4783 A-177.3830 Z0.1964
N390 G1 X-0.2103 A-177.3830 Z0.2015
N400 G1 X0.0080 A-177.3830 Z0.2031
N410 G1 X0.2392 A-177.3830 Z0.2011

A "G4 P0" between line 390 and 400 would eliminate a possible clunk on the x axis from the reversal

Maybe there are other ways to solve this without giving up speed. I continue to play.......


Ed