Need Help!- Camsoft control axis position changing

[jguerrera]

I have a pc based camsoft control that uses a galil ethernet motion card. I have this system on a automatic swiss screw machine. The problem I am having is while the machine is running the X axis keeps growing as the machine is running parts. I run about 10 parts and the diameter in X grows about .002" which is .001" per side. I have checked the tuning several times and tried to use the backlash feature but nothing has changed this problem. I have the ratio set at 51200 and a motor with a 1024 line count. The machine axis stops right on the money and the readouts show that but when you measure the part the diameter is getting larger. I have been working with camsoft for 3 weeks about this problem and we seem to not be able to solve it. Anyone who has an idea on how to solve this please let me know.
Thanks
J.G.

[HuFlungDung]

I am a little puzzled by the ratio you are using as 50800 would be typical for a metric screw. Do you have a mechanical reduction in there as well? Is this a backlash free reduction?

Are the thrust bearings on the ballscrew in perfect adjustment? Encoder couplings tight?

Have you tried a trial cut at two different diameters that span the range of swing of the machine? Does it cut those two diameters correctly.

What about heat? Could this be a heat related issue where the spindle housing is warming up?

While I would not expect the readouts of the display to demonstrate a mechanical error, a series of programmed moves could be used back and forth between two positions, and a dial indicator to check for migration of the endpoint.

Have you tried adding in a return to home command at the end of every run of the program?

Do you have a shielded encoder cable? Is the shield grounded at only one end? Is it running in its own conduit?

[Bob Pierre]

A while back I had the same problem.

My customer was cutting slots and the more slots he made the more the slots shifted and grew.

I don't have there manuals with me but there is a common question in there about this.

Sorry camsoft you may remember that I fought you on this but your suggestion on changing the ratio count to something something .2 worked.

I would say try 15200.5 or 15199.5 and keep adding or subtracting small amounts to the ratio value until its right.

.001 is small. A bigger value would be easier to tell what is wrong. With .001 it maybe backlash, tool wear or something mechanical. Any of the things HuFlungDung said.

Bob

[Karl_T]

I also had this exact problem on my CHNC. Drove me friggin' nuts. (short trip for me) In my case, I had a single ended encoder and a switch to differential solved the issue. steps were getting lost from the encoder.

I talked with both Camsoft and Galil about a way to find the index mark WITHOUT resetting home. then you could check for drift buy just reading exactly where the index mark is. Bottom line, Camsoft couldn't do this; Galil wanted a custom program charge.

NOTE: I found its NOT a good idea to just re-home during a production run without a first part dimension check. Indicator work proved that home varies by .0004" diameter. If you've got a spec of +/- .0005 you're dead in the water with a re-home.

If, buy chance, there's enough people with this issue; I have an elegant solution with the custom Galil program. (I just need Galil FI without resetting home)

Karl

P.S. I should have added how I determined home was drifting. Put an indicator on the machine and move to machine 0 once/cycle, record indicator reading. My readings kept moving, in my case about .001 per 25 parts.

karl

[Al_The_Man]

I would think that the difference could be seen or not between a G53 X0 and a home routine.
The G53 will return the axis to the zero position without homing, and a home will reset the home position by marker seek, G53 might be better than G28.
If both these test move to exactly the same point, then it looks like machine growth, if they differ, then there may be something affecting count resolution or accumulation.
Al.

[HuFlungDung]

What about the ratio between the encoder resolution and actual mechanical movement?
For example, using a .2000" pitch screw, and 1024 encoder, gives a resolution of .2/4096 = .0000488 travel per count. One has to wonder when and where rounding takes place and how a systematic error can be prevented.

Might be better to swap the encoder for something with a count that is exactly divisible in whole commanded units, with the given ballscrew.

[Al_The_Man]

I don't think rounding does take place, from my experience with galil using software that utilizes native commands directly, for example if I am inputing positioning to two places of decimals, and my resolution is .0000125"/count, and If I check error using TE, I can maintain position, within zero to one count error, but even if my error was 10 enc counts, the card counter always keeps track of the actual count and knows the position is out 10 counts.
IOW the position is always recorded down to the resolution amount.
In this case though, even if my TE is zero, my recorded position can be out by the resolution value, i.e. the difference between the leading/trailing edge of A and leading/trailing edge of B, which is .000025".
At least that is my understanding.
Or HU, is this what you meant by rounding?
Al.

[Karl_T]

Rounding error problems certainly must exist because several folks have "fixed" the drift problem by changed their encoder count per revolution by a very small amount like 0.1 out of 10,000 or more. I can see rounding being a problem if you're got metric lead screws, an odd encoder count, and you're running engish parts.

Now if you're got an english lead screw like the very common 0.200"/rev, you can put a 1000 count encoder on and never have a part count encoder move for english dimension parts.

Karl

[Al_The_Man]

Define rounding error as it applies to galil feedback ??
Al.

[HuFlungDung]

Al,
I see what you are saying about whole encoder counts. However, with an oddball ratio between the encoder and the system resolution, the output command from Camsoft could contain couple of rounding errors before the command goes to the Galil. If the rounding errors are in one direction, they could accumulate if moves are then made in the reverse direction, but not the same series of steps, but let's say one long retract move with only one rounding error (because it is one move).

Wouldn't this bump the system in one direction systematically?

I think if one were planning to program in direct Galil encoder counts, then there would be no question that the desired feedback of the system should be an integral amount that worked out exactly as a whole number multiple with respect to the typical .0001" command units.

[Karl_T]

Originally Posted by Al_The_Man Define rounding error as it applies to galil feedback ?? Al.

How this is done is a bit "black box" to me. I know both the galil PA and PR commands only take a resolution of 1 encoder count for example. My understanding, if the move calculates out to XXXX.4 counts; you move XXXX and lose the .4. After 1000s of moves you can end up losing several counts. The resolution certainly may be more than 1 digit after the decimal point, but all computers round at some point.

The OP can eliminate this possibility by devising a program that only calls for moves of exactly 1 encoder count, no rounding. If there still is drift, look for another cause. Hu had a good list.

Karl

[toolmanwaz]

Jguerrera, Do you have an Oscope? I have run into this problem on machines that do not have Camsoft. What you need to do is monitor A+,A-,B+,B- phases on the encoder. You should have a very CLEAN square wave as you move the axis. What happened to me was the bearing in the encoder was shot. Ran fine one way and a crummy the other. Sometimes it would loose counts sometimes it wouldn't. Just a thought.
Jim