tahoe brian

Does anyone have a simple way to emulate quadrature encoder output that is tied to either motor or axis position? We have an external application that needs axis position as an AquadB signal. We can't daisy chain the encoder hardware because we are suing sine encoders and ACC51 interface. I could see doing what we need with a PLC, but not sure which outputs would be best. Is there an accessory that I am not thinking of that would help in this regard? Thanks.

The following line of code: G54.1P1G0X0 Wants to move all of the axes to zero with respect to the G54.1P1 coordinate offset system, which is incorrect. Whereas G54G0X0 Only wants to move (as it should) the X axis to zero with respect to the offset value. Is there a bug in the extended work offset implementation, or is there something else that I don't understand. This is the first time I have tried to use these offsets in my 20 years with NC. It's almost as if there is a PMATCH / PSET type of problem somewhere?

Thank you.

So, mathematically speaking, the algorithm is in essence: Sum = Sum + greater of (0 or I^2-continuous limit^2) so that only when the current is greater than the continuous limit is it integrated?

I am curious what the real algorithm is for integrated current limit. According to documentation it is a running sum of the difference between square of commanded current and square of continuous current limit, and when this sum exceeds a value set by the user, it trips. This implies that if commanded current is always lower than the continuous current limit, then the new value in the sum is always negative, and eventually the value will saturate as a large negative number. Therefore, it will take longer to trip from this condition then it should based on the physics. For example, if the average current is 99% of the continuous limit, eventually the register will saturate negative, yet the motor at this point is close to it's thermal limit (as continuous current limit is typically defined as the current required to raise the temperature to its continuous limit), and won't take long to overheat if the current goes to 101% of limit. I am guessing that the real algo is more complicated, or am I missing something? The actual algo has a big impact on how to set the values for max benefit.

I have a machine down for the lack of a working ACC51P board. We had one fail. Trying to get repair expedited, trying to buy a new one expedited, but our time frame is immediate. Anyone have a spare board they could sell / loan / rent?

If I understand, the encoders are on the motors, so backlash will not affect following error per se. If you can achieve +/- 10-12 cts in PEWIN, then you should see .0010" to .0012" in NC under the same conditions. If it literally only displays one of the two numbers then there might be something set incorrectly with respect to the display. To get the right "feel" for the hand wheel, you have to correctly trade off the distance per click, the hand wheel jog speed, and the jog acceleration. If the speed and acceleration are too low then it will be too easy to turn the hand wheel faster than the machine can move, causing it to "wind up" as you describe. Same for the PB's. I suggest setting the hand wheel step sizes small and work your way up. The wind up is a bummer, as it leads to crashing tools into things.

In my opinion primary benefit of the parabolic move is for setting the velocity feedforward and acceleration feedforward gains. For the test to be of any benefit in this regard the velocity and acceleration during the test have to be significant enough to have a measurable effect on the system. Specifically, for a machining center, you should push at least as hard as you would expect the machine to perform circular interpolation, i.e. for a given circle radius at a given federate, determine how one of the axes would move and approximate this with the parabolic move and then some. It should certainly be at least one rev of the motor for a rotary motor, IMHO. Without knowing what the mechanics of your system are and what 10 cts translates into, it is hard to say if you can achieve that or not. Many commercially available VMC's ball bar test to better than 50 millionths of an inch, some better than that (lathes typically even better), so clearly the following error of the servo is better than that in those examples. The highly specialized machines that I work on have following errors during a parabolic move of better than 1 millionth of an inch. In your case, if you have a rotary servo driving a screw and your encoder is on the motor and is roughly 2000 to 5000 cts/rev I would expect that you would achieve better than +/- 10cts unless you are pushing the system beyond the torque limits of the motor or the motor bearings or ball screw nut bearings are poor. This is because a typical modern servo motor behaves pretty ideally. Keep in mind that the motion of the carriages will be worse than this, as the mechanics of the rest of the machine will add additional error.

Yes, you are precisely correct. I was communicating qualitatively about what the deadband does to the loop gain, but you are correct, in implementation it does not affect the output of the integrator. For that matter, it doesn't affect the contribution of the velocity feedback either, so at high frequencies deadband doesn't do anything to attenuate oscillations just outside the deadband spacing.

These two statements are equivalent, as the proportional gain is applied to the following error as well, effectively. Think of deadband gain as an adjustable proportional gain that is only adjustable over a range of following errors that is finite. It is implemented by multiplying the deadband gain by the proportional gain over a finite range of following errors, thus it creates a non-linear loop gain.

Curt, that is an interesting idea. I don't know your system, but another way to deal with stiction is with a dither type input, for example superimpose a high frequency oscillation (above the position loop bandwidth) into the actuator at startup. It has the effect of lowering the friction closer to the kinetic value. This mostly makes sense if the actuator is well coupled to the source of the friction (i.e,. the stiction is in a ball-screw nut). If the source of the friction is decoupled by a compliant structure (i.e. you have sliding contact bearings, a bendy structure, and a lossy ball-screw actuator), then it is really tough to do anything.

I am not 100% sure if you want to limit the Vff contribution to a maximum value, or if you just want it larger in the beginning and smaller in the end. Either way, you can write a PLC0 to adjust the gains on the fly. You could adjust any of the feedforward gains that way and come up with all sorts of non-linear effects.

Do not modify lathe.g. Simply replace the old lathe.g with the new one, same with the other three files. Perhaps rename the original files something like xxx_old.xx and then you will have them around. The four files serve as a bug patch. I recommend using lathe.g and not one of the others. The other lathe types mimic certain standards on other types of machines. If you do this, all will be well. The primary fix that this patch accomplishes is making tool nose radius comp work correctly.

On further analysis, this looks like 120 Hz rectifier noise. I am not sure how it suddenly appeared out of no where, but perhaps we lost a ground somewhere or busted a component.

Here are some pictures, one with the system open loop with the drive disabled, two in closed loop at different scales. Frequency is just over 100 Hz, but definitely not 120 Hz according to FFT. Jumps appear to be 64 counts or 32 counts. When quiet, the system is still to a few LSB's (subcount).