Troubleshooting Inaccurate Cutting with Dual Tables

Mechanical backlash or a control problem could be causing performance flaws in a dual-table CNC setup. Here are tips of finding the source of trouble. May 16, 2005

I run a CMS machining center with independent V and Y tables. I have been experiencing an extremely horrible cut quality when using the V table. The rough cut is only experienced when interpolating the X and V axes. I can run the exact same program on the Y table and the cut is extremely accurate. Also, when the V and Y are slaved, the cut remains accurate and very acceptable. I am not sure what could be causing this problem, but I have a few ideas. It could be the servo drives or ball screw. I am not sure where to start in diagnosing this problem, so any help would be appreciated.

Forum Responses
(CNC Forum)
From contributor D:
Easy checks that I recommend include:
1) Check backlash on the X and V axes. To do this, use a dial indicator mounted on one of the ways and jog the machine in increments of .01mm, .1mm, and 1mm, while reading the actual movement from the indicator. Go several steps one way and then reverse. Any difference between the jog command distance and the indicator reading is positioning inaccuracy (probably, but not always mechanical backlash). Do this test on both sides of the X and V tables. If you get one reading on one side of the table and a different reading on the other side, your table is "crabbing" on the ways. With the indicator still attached and the drives still on, push and pull the table and see if the indicator moves and does not return to the original position. Failure of the indicator to return to the same reading almost certainly indicates mechanical backlash. Mechanical backlash is usually the result of wear in the screw or nut, or a problem with the support bearings. If you find backlash in excess of about .04mm, I would look into getting it fixed. Below that, you can probably compensate adequately in the control servo parameters.

2) If you find no mechanical backlash, I would slave the tables together. Mount the indicator base on one table and indicate off of the other. Jog back and forth incrementally and continuously. Ideally, the indicator should not move. If it does, note the amount of error, the situation under which the error occurs, and the characteristics of the reading (rapid oscillation, regular periodic deviation, etc.). If you have this sort of problem, then it is probably time to call in a tech to take a look at the control/servo/feedback system.

3) If you still see no problem and you can control both X and V separately, I would unslave the tables, but write a program that moves both tables back and forth the same distance at the same feed. Perform a test similar to test 2. This should yield the same results as test 2. If it does not, then the tech has some real head scratching to do, and will probably need to talk to the control folks.

As an aside, if you are covering both tables with a single spoil board when running in slave mode, the good table could very well be dragging the bad one along. I do not know if this is the case, but I have seen this sort of thing before.

From contributor D:
In previous post, please note that I was calling the axis parallel to V the "X" axis. It is obviously the "Y".

There is one more thing you might check. Do a backlash check with the tool carrier positioned over the Y table and then do one with the tool carrier positioned over the V table. It is possible that you have a mechanical problem in the X axis that is localized over the V table. You usually see this kind of problem in a rack drive axis, but it is possible in a ball screw system if there is way damage.

From contributor K:
Have you checked your hold down system? You might be loosing vacuum on your V table or you may have too much overhang of your part.