Strange Axis problem after Ballscrew Change

[AKFALAR]

I just swapped the x of an (x,y gantry) ballscrew. Originally the x and y screws were .25/rotation screws. The new screw is .5/rotation and the y is still .25/rotation.

I made adjustments in the CNCSETUP (RATIO setting) and jogged both axis to verify linear accuracy @ 1-ft.

We started running parts and everything seemed to be working fine. Until the operator complained that all moves in the x were faster (still linearly accurate). At, suprise a 2-1 ratio.

What the heck am i Missing here?

Thanks in advance,

AKFALAR

[Karl_T]

QUESTION 114
I gave the machine a feedrate but the table doesn't seem to move at that rate?

First you have to determine why the feedrate is inaccurate. It is either only one of two scenarios. Most likely the problem is that the number of encoder counts or steps for each axis being moved are not consistent or equal with one another. Check your RATIO parameter settings in the CNCSETUP.EXE program. Only compare the RATIO values on the axes you specified in the AXIS parameter setting. The total number of axes or any axis defined above the number specified by the AXIS parameter setting does not matter. Those axes move independently and are not coordinated together. If the RATIO values are not the same, read answer number (1) below. If your RATIO values are of equal values, then the only other possibility is that the encoder is mounted to the back of the motor or some place that does not represent the actual table position. Therefore, the inaccurate feedrate is caused by some gearing or a non 1-to-1 ballscrew ratio increasing or decreasing the amount of actual table travel by some percentage or scale factor. If the RATIO values are equal, then read answer number (2) below.

(1) Having a different number of encoder counts per axis is causing the axis with the largest value to move faster over the same amount of time as the others. For instance, let's say we have to move 10 inches in both X and Y at a feedrate of 10 inches per minute (IPM). We used RATIOX=10000 encoder counts per inch and the Y axis as RATIOY=5000 because it only needed 5000 counts to move one inch. In the interest of position accuracy and keeping both axes coordinated in a straight line while moving to the target position, the controller must tell the motion card to move X 100,000 counts and Y 50,000 counts. The controller must also be told the velocity of each axis so that both axes arrive at the target position at the exact same time. The counts per inch are what matters most to arrive at the target position together. Therefore, the trade off is that the number of counts given over the same amount of time will differ when the RATIO values of all the coordinated axes are not equal.

As in our example, the X velocity was told to travel at 100,000 counts per minute while the Y velocity only needs 50,000 counts per minute to arrive there at the same time. If these velocities were not given as such, then the Y axis would arrive at the target position first before the X and you would not have cut a straight line. All moves, no matter how small or long without regard to the fact that one of the axes need not even move at all, are always calculated as coordinated moves together. The effect is more drastic when one of the axes only moves a small distance or no distance at all and the other a longer distance. There are no parameter settings or logic that can overcome a physical/mechanical situation like this. The only solution is to design a system or install gearboxes that require all coordinated axes on the machine use an equal number of encoder counts.

There is also another method that is not recommended because of possible unwanted side effects in accel and decel. Please refer to the [FEEDRATE ADJUST] macro for a logic example that you could use. You may adjust or override the accel and decel rates per G code or position move and also adjust the FEEDRATE accordingly to result in the desired velocity, but this method is advised to be viewed as a temporary solution.

(2) Since the encoder is measuring before the gearing or leadscrew, you can either mount the encoder after the gearing or leadscrew or as close to the table travel as possible even if you have to use linear glass scales. The only alternative is to set the FEED parameter setting in the CNCSETUP.EXE program to an unused variable and then give that variable in the STARTUP.FIL file the correct percentage that would reflect an accurate feedrate. For example, if the table travel was moving twice as fast as it should, enter \73=50. If it was moving half as fast, then enter 200 as the percentage value: \73=200. The drawback is that you cannot use the on- screen slider bar control for feedrate override but you can use a FEEDPOT knob since this would not affect the percentage value in the FEED variable.

Explanation of the Solution

In essence, if you are willing to consider changing the parameter settings on your micro stepping drive to a different micro step, or if you have physical encoders changing the gearing ratio or the encoder itself to a closer PPR (pulse per rev) to the other motors, then you can skip the advice below, your problem is solved.

When it appears that the feedrate (Velocity) is only correct when a single axis is being positioned but the same axis is not correct when making a move in combination with others axes, then ask yourself if the axis you are observing changes velocity when the other axis it is moving in conjunction with travels a further or shorter distance.

If the answer is shorter, then the explanation is that the velocity of the other axis is the one traveling at the full velocity speed because it has a further distance to travel, while the axis you are observing must travel slower in order to arrive at the target position at the same time. Keep in mind that vector velocity is the path along, which all the axes travel in combination along the vectored trajectory while the path and velocity of a single axis in motion is always isolated from the rest and very easy to determine its speed visually. The important issue to remember is that the vector velocity along the path is true and correct, even though it does not appear so. This is most apparent when linear axes measured in inches or mm and rotary axes measured in degrees are used together.

Example 1: If the X axis is only commanded to travel 5 inches while the Y is commanded to travel 10 inches in the same move, both must reach the target position at the same time. The X axis must travel half the speed (Velocity) of the Y to arrive at the same time. To move in a straight, vectored line path is what is important.

Example 2: If the X axis is only commanded to travel 5 inches while the A rotary axis is commanded to travel 90 degrees in the same move, both must reach the target position at the same time. The key factor here is to break down both axes travel distances into a common unit such as encoder counts or steps. If X only takes 5000 counts to get to the target and A requires 10000 counts to travel 90 degrees, then the X axis must travel half the speed (Velocity) of the A to arrive at the same time. Therefore, the X velocity is scaled back to arrive at the target position together. To both begin and end motion at the same time is what is important.

If the answer is further, then the explanation is that there may be a max limit or cap set on the RAPIDSPEED settings of one of the other axes restricting the velocity at which the machine can move. The velocity of the total axes system will only move as fast as the slowest axis. The travel speed will be set by the slowest axis in the coordinate system in spite of that axis being commanded. If this were not so, then the machine motion would constantly be accelerating and decelerating while making transitional velocity changes between moves. Therefore, the cutting speed is limited by the speed of the slowest axis in the coordinate system.

RAPID moves are treated differently than feedrate controlled moves. Rapid moves are evaluated internally by the system. The travel speed will be set by the slowest axis commanded in a single RAPID command.

Other settings that affect the outcome of velocity are FEEDPOT, SLOWDOWN, NEXTMOVE, ACCEL, DECEL, AXIS parameter, RAPIDSPEED, the FEED variable and the SMARTPATH feature.

If these explanations make sense, then no further action need be taken since the system is operating as designed. However, if a solution is required by the user because it is too noticeable due to the mechanical design of the system, then here is the solution.

Inside each G code that controls motion, such as G00, G01, G02, G03 and G10, use the ISTHERE command to determine which axes are being commanded to move at that time. Next, create IF THEN statements that will reset the RAPIDSPEED values as needed while scaling the velocity with the FEEDRATE command per G code move. The worst that could happen is that the commanded feedrate varies slightly during acceleration and deceleration between moves. A high ACCEL and DECEL setting will nullify this effect. The important issue is that the actual cutting motion is always cutting and following the correct path no matter what, even if you took no action or miscalculated velocity. Each system design and axis configuration is so different there would be endless methods required. Therefore, no one internal algorithm or logic example we could provide would do. A custom solution would be necessary.

These suggestions are only programming methods to overcome the physical properties of the machine design itself. The true cure is to engineer an axes system with equal encoder counts or steps.

(A) From a machine design point of view, changing the gearing on the gearboxes, belts or ball screws or replacing the encoders themselves with proportional counts to the other axes, corrects this problem at the root.

(B) If the issue is mainly for tapping or threading such as in a G84, then the [RATIO FIX] macro may work for this. There are some other questions in this manual that refer to this same subject and macro.

(C) If perfect velocity accuracy is only for a single axis at a time such as Z, then separate the Z axis from the other axes by making it an independent axis and then put the Z axis back into the coordinated axes group in G80 when you cancel the tapping or threading cycle. This can be done with the AXIS command, but each machine design is different so contacting your installer is necessary to set this up.

(D) If all axes in a coordinated system must always be automatically compensated on the fly at anytime, then short of changing the machine design have the motion card company provide a quote for calculating the axes ratio directly on the board. Again, each machine design is different so a custom firmware change would have to be made per machine.


Q

[AKFALAR]

Fairly confusing but... I was able to change the gear setting on the AMP and i think were are solved....

Thank you for the reply!

[Al_The_Man]

It must get confusing if you are using intelligent drives with a Galil card?
Is their any PID tuning involved with those drives?
Al.

[AKFALAR]

I'm running them as steppers Pulse+Direction.

Still confusing for a rube like though.

[Al_The_Man]

This thread was deleted, I restored it and eliminated just the post and banned the spammer.
Al.