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).

System: air bearing spindle with brushless rotary motor, 9000 line sin-cos encoder, ACC-51P. Was working fine and then after making some software changes to a PLC suddenly behaves very strangely in closed loop, even after doing $$$*** reset, power cycling, etc. Open loop the system is quiet, position noise is only an LSB or 2, closed loop the following error toggles close to 64 full counts (2048 LSB's), mostly in one direction. It ran away once. It is like something is stepping on either the DAC or the encoder channel. The system moves smoothly doing open loop command with modest currents, rotates endlessly in both directions. It doesn't appear to lose any counts when rotated. Have moved the motor to different DAC's, same result. Anyone know what failure mode or noise would cause this?

2.36 runs perfectly in Windows 2000 (which was the defacto 2.36 environment) if you can get it, I believe it also runs in NT. Not sure about XP. Don't run it in 98 or 95.

Just to clarify Unit101's comment: install the 2.36 and then install the four patch files immediately (it entails replacing the four files in a particular directory) before doing completing your integration. You want to work with 2.36(1) from the outset, especially on a lathe. 2.36(1) and the basic PLC programs that are supplied work well. The PLC's take some time to understand, but once you understand them it is actually quite easy to use. I advise you to get the servos and a limit switches, etc. working at a basic level using the PMAC executive program prior to messing with the NC part of it.

There is nothing wrong with the 2.36 software, although you will want to get ahold of a version called 2.36(1) which fixes some bugs. The bigger problem that you will have, assuming that you have an old ISA bus PMAC 1, is coming up with an ISA bus PC and software. When that code came out Windows 2000 was the standard. There is a company called NIXSYS that can sell you a "legacy" industrial PC with and ISA bus with WIN2K installed that will allow you to run NC 2.36 and your old PMAC. This might make sense if your machine is partially/mostly together, you have PMAC/NC experience, and you just want to finish it. If you haven't done anything yet, you don't have much Delta Tau experience and you want a machine that will be supported for a long time, then I would invest in Advantage 900 and a more modern PMAC for the support, IMHO.

One way to do this is to create a phantom (pretend) axis. For example, let's say you want the X axis to have a sinusoidal trajectory. Then create a phantom axis called V, and do circular interpolation in the X-V plane. There is no V, so it doesn't do a circle, it simply does sinusoidal motion on X.

Please accept that I would be trying to tune the axis "blind" as I don't know what frequency the slide resonates at when it goes unstable, and I don't know anything about the mechanics, but assuming that you have high resolution feedback, linear motors, and either aerostatic or hydrostatic slides, the I131 and I132 seem "high" relative to I130, and I133 seems "low". You might try looking at cutting the I131 and I132 in half and increasing I133 substantially, perhaps as much as 10X. Try doubling it and then doubling it again etc. It is possible that your proportional gain is being limited by the high I131 gain "buzzing" with quantization noise, and your I133 is also low, both of which is limiting disturbance rejection at 7.5 Hz. I am totally guessing here.

Another thing that would be helpful for me would be to tell us what the current Ixx30 settings are, and then tell me how high you can raise Ixx30 before the loops start to go unstable.

Unfortunately this is a very broad question that must first be addressed at the system level. As a very generic answer, your system has inadequate loop gain at the frequencies where the disturbances are showing up in the FFT's above. This could be because the gain of the transfer function of the controller is lower than it could be (i.e. system bandwidth is unnecessarily low), or it could be that the disturbances (i.e. vibration, electrical noise, etc.) are of such an amplitude that they result in unacceptable performance. Without knowing about the architecture of the machine one could only guess what is limiting performance. I do see that you have large errors at approximately 7.5 Hz, which is in a frequency range that could be vibration due to ground motion which is being transmitted into the base of the machine. You may be able to improve this with increased loop gain at 7.5 Hz, which you might be able to achieve by increasing the proportional gain (assuming that the stability limit of the loop has not already been reached). Given that he problems are at reasonably low frequencies, I seriously doubt you need a more complicated (i.e. more poles and zeros) controller, you likely just need to increase the bandwidth of the one you have. State of the art diamond turning machines achieve nanometer level surface finish with simple PID controllers routinely. If you could give a more complete description of the machine elements then I could be more helpful. Lastly, it takes a very good machine to do quality diamond machining. The controller can not overcome inadequate performance of the electromechanical systems.

Thanks. I am not trying to display the code within the G61.1. I simply told you approximately what was there to see if that is related to the problem. My problem is as follows: assume that I have multiple lines, N20, N30, N40, etc. ( I am not actually using line numbers, but it helps me illustrate my point) On each line there is a single command, a G61.1. When the machine is executing line N20, the UI might be highlighting N100, or some other line. I am guessing that the M20== assignment is not being done when the parser sees the G61.1, and is instead issuing M20== commands for certain lines inside of the G61.1. Is this possible?

What synchronizes the PMAC to the PC in this sense? Whatever it does it is either missing or is behaving asynchronously with my G61.1. Inside of the G61.1 it reads parameters, commands a G0 to a position, waits for a condition using a while loop, does a synchronous m-variable assignment, commands a second G0 position, waits for a condition using a while loop, does a second synchronous m-variable assignment, then returns. It is basically a canned cycle that turns an output on and off between moves and then returns. It works great, but the operators have a hard time knowing which line of code it is on because the "current-line" cursor display is not timed to anything. Is this simply a bug with user g-codes, or am I missing some command status somewhere, or will setting the code group m-variable that you mention above magically fix it?