tahoe brian

From the response curves it is impossible to tell just how good you can get, but I can tell you a) your Ixx30 can be raised to increase bandwidth, I see no evidence that you are near instability. Raise Ixx30 until you get just a bit of overshoot in your step response. Your Ixx34 should be set to 0 instead of 1 so that the integrator is working all of the time. You may also try raising Ixx33. This will also help with the low frequency tracking that the sinusoid in your test requires. From the curves it seems that mechanical friction is getting in your way and that the servo gain is simply not high enough. The adjustments I suggest will help. I would expect that you should be able to get the tracking error to less than +/- 50 counts (+/- 500 nanometers) even with mediocre mechanics. If you are hoping for much, much better than that then there is no way to answer the question without knowing more about your machine.

When you lose counts in powers of two it sounds like you are getting a false signal on one pin of a parallel feedback word (i.e. lsb, lsb+1, etc). However you mention Acc-24. What type of feedback are we talking about? I once had a problem where bad cabling was causing a similar problem, which caused a huge jump when it was the 2^16 bit.

if there is a structural or syntax problem in any of your PLC's this will happen. Could one of the PLC's have a bug, i.e. missing some code?

The problem is your commutation phase advance sense is backwards using your technique. You did the encoder part correctly. You want to leave Ix30 in the "positive" sense as it was and adjust the bit 22 of Ix81 to change the phase direction of the Hall sensor. The user manual should clarify this.

Thanks Steve for the reply. This is a non-turbo PMAC, the machine has been running flawlessly for ten years, without ever having this error. It had already executed this program about 30 times and it stopped several hundred lines into the program. The servos and PLC's were all working fine as evidenced by proper operation of the control panel and spindle PLC. The program is a parametric program that uses a DO loop, but nothing terribly unusual about it. After restart it hasn't come back. We will just take a closer look if it comes back.

On one of our older machines running NC 2.36(1) we received the following error message, which is an Inhibit message: system: 3007 Pmac run-time error System was in Auto mode running a program that has run many times before. Servo control was just fine, there were no other glitches. When system was switched from Auto to Manual mode, error was reset and no flags were tripped as viewed by PEWIN32, so no debugging could really be done. What are potential causes of this error?

I am assuming that it is a three phase motor and you have a three phase current loop amplifier to drive it. I am also assuming that your 8 ppr "tach" is just a pulse train, not in quadrature, so you have no direction capability. Perhaps you could use the 8 ppr signal and feed it to PMAC as a step and direction encoder, clamp the direction one way or the other, use standard PMAC induction motor vector control, and simply run it open loop using "O" commands. It would then behave like a variable frequency drive and there would be enough data from the 8ppr to get the mag vector to spin around correctly. You might need a way of changing the "direction" signal to be in phase with the "Oxx" or O-xx" command. I am sure there is something that I am forgetting, but I think this will work. P.S. I once controlled a large induction motor with a 50 line quadrature encoder (don't ask) and it worked pretty well even in closed position loop mode.

I agree with you Jeff, 4000 counts is much larger than where he will end up, but still under some level of control, hence, my comment. Just so I am clear on which definition of counts that we are using here , isn't one servo error count = 34 picometers, and thus 4000 counts = 136 nanometers, or are we talking that the LSB is a fractional count? Please straighten me out.

Keep in mind that I111 is in units of 1/32 of a count, so you are actually setting your limit to about 125,000 counts, which is not that big if you are doing step inputs with the FE limit enabled. Your 4000 count FE while jogging slowly is not huge, but is not small either. What is the FE if you just close the loop and not try to move it? As Jeff said above, if you can look at an FFT of the FE signal it will tell us more about what might be happening. Can you do this? Another thing that would be helpful would be to tell us what the gains (Ixx30-Ixx39) currently are set to. Then, do a test where you close the loop with no jogging, and keep raising the Ixx30 until it goes unstable and starts to whine, or the FE trips. Raise it about 10% at a time. That would tell me some things about where things stand with the loop gain. Perhaps report the "typical" max FE at each gain as seen by a watch window. Questions: was this machine positioning well before the retrofit? Is it air bearing or oil hydrostatic? Do you know what the gains were on the original D-T controller?

also make sure you are not limited by Isx87, Isx88, and Isx89, coordinate system default accel and feed limits.

At any rate, we are multi-threading at this point, but try using 1,905,000 counts/cycle per my other post (or if I have the wrong data for your encoder, scale it up or down)

I might be wrong (I have had my head up my a** all day), but I think your encoder is 128 nanometer line pitch, and with x4 decode your hardware pitch is 32 nanometers. So for a 60.96mm motor pitch, you have 60960000 nm / 32 nm = 1,905,000 hardware counts per cycle. As your example that you posted says, the commutation routine ignores the intepolated counts and only uses the "hardware" counts

No. I171= 2.4*25.4*lines/mm *4 (quadrature decode of the line counter) =1773382 (assuming quadrature decode of 7 or 3 in the gate setup) @ Jeff: 25.4 lines/mm (physical lines) for the Sony scales seems too coarse. What am I missing?

The Ixx70 should be set to 1, the Ixx71 should be set to the number of hardware counts per commutation cycle (not the shifted software counts), which is hardware counts/pole pitch. For the Trilogy motors the pitch is 2.4", don't remember for Aerotech. The acc-51 manual makes this real clear...I would look at that rather than use the utility software.

Thanks for the reply. Just so I am being clear, we have all of the tool offsets that we need (columns in the tool table) defined, but I am talking about using buttons to set the data. For example, in Lathe code the operator has a cell in the Tools page where he can enter the diameter of the "touch off" point. When you hit SetX, the correct tool offset for X Geometry gets taking the diameter of the "touch off" point into consideration. In the Mill code, you have Block Height, where the operator enters the height of the "touch off" block and when you hit SetZ it uses this data. I am looking to have both entries available on the lathe code, so the operator can enter both the diameter and the height of the "touch off" point and then when SetX and SetZ are pushed, the respective data are used in the calculation of the zero point for the offsets. The reason I want to do this is probably obvious, put it is because the tool set station is shifted in both X and Z from the desired tool origin point on ths spindle. The "standard" lathe code only lets the operator enter the diameter (just like the standard mill code lets the operator enter the block height). Is there a way to add a cell for the operator to enter this data, or does one have to create some hack to do this? One possible "hack" that we use now is to enter the set station Z offset as a "wear" offset value, but then we lose the advantage of having a pure wear offset.

Is it possible to modify the functionality of the SetX and SetZ button page in the Lathe code? The UI in the Lathe has an input cell for the diameter of the tool set location (analogous to the block height for the mill code) from which the tool offset is calculated. Is it possible to add a cell for the Z height of the tool set location as well? Rarely do necessarily want the tool set station location to be Z0. This would be equivalent to having both Diameter and Block Height as input variables on the UI. The most generalized solution of course would be to allow the operator to enter the set station offset in each coordinate that is active (five offsets for a five axis machine, etc.) I am assuming the answer is no, so does anyone else have any nice solution to this problem?

The BD95s are kind of pricy for what they do. You should look at: http://www.oztekcorp.com/products/interpolators-and-accessories/ea100-encoder-adapter/ Sony Scales, interpolated to 34 pm, Pmac, Sunx switches... Sounds familiar Amplifier selection for this will be critical for this resolution: Low Noise, zero crossover distortion is a must. I agree with you Mr. Lowe, amplifier performance (especially crossover performance) is a limiting factor these days. What amplifiers and power supplies can you recommend?

Unfortunately, I am not a Clipper guy, so I don't know about issues daisy chaining the 8Es and 51s, but I will say that if you follow the information in the 51 documentation on encoder setup that it works. Regarding +5VDC power for your I/O, I am a fan of using a separate, isolated supply. The PMAC can be jumpered for separate supply for the I/O The signals themselves should change state if you bring them to ground. You can test them by shorting the signals to ground and watching in PEWIN. Once you see that the card side is working, you can trace your signal path back. Try reading examples of the E-stop plc. There are a number of ways to integrate this. If it were me I would get the discrete I/O working at the PMAC level, then the encoders, then the amp control signals and DAC's, then worry about the e-stop integration. In the meantime, your hardware relay kill of the amps will provide safety. It sounds like you and I work on the same types of things. Feel free to email me if you would like to keep a dialog going.

It sounds like you are doing a lathe, or something like a lathe. I have done many lathes, albeit not with the clipper. Your first experience will be frustrating, but the final result will be really good. Here is what I would do: I would consider going to training at Delta Tau if you really want to learn this stuff and have no Delta Tau experience. The training will mostly serve as an introduction and a forum for asking some high-level questions. If you simply want a working machine and don't care about learning it, hire a CNC Integration consultant, as this is not a trivial project. The people listed on the DT site are generally very good. That said, here are the steps: 1. Make sure that you have all of the correct Delta Tau interface accessory hardware. People on this forum could help if you told us exactly what type of signal your amplifiers expect (U/V sinusoidal, for example? plus enable and fault, etc are there Hall signals for commution), exactly what type of signal your scales provdide (quadrature or sin / cos, for example), and any other critical signals (limit switches, what kind of signal). You need to make sure you have all the hardware you need. If you can't determine this information, you will likely not be successful. 2. Wire your machine using guidance from the the Clipper manual and the accessory hardware manuals and good engineering judgement. If you don't have adequate experience here, you will need professional help, or you won't be successful. Beware especially of poorly grounded, noisy signals. It will wreak havoc when you get to the NC integration part. 3. Set the jumpers for the Clipper per the manuals and install in the host PC. Install PEWIN32 or equivalent. Establish communications. 4. Configure each motor by setting the I variables in the controller and get to the point where the limit switches work, the amps can be enabled, and you can jog the motors. As they are linear motors you will have to learn about motor phasing and phase finding. You will have to learn how axis homing works. You will have to learn about how to scale an axis and set up a coordinate system (ultimately this will be X and Z). Set safety limits for following error, velocity, accel. Don't bother to think about the NC side until this is done. You will be debugging your wiring most likely during this phase. Save your configuration file often. Once again, DON'T BOTHER TO PROCEED UNTIL THIS PART IS MASTERED 5. Make a block diagram of everything your CNC machine should have, i.e. control panel, handwheel, spindle, coolant system. 6. Install the NC software as a Lathe and go through the configuration and download the required lathe.g and PLC programs (i.e. panel, handwheel, homing, it depends on your configuration). This will be hard to learn on your own, but it can be done. Start with minimal functionality and add features according to your block diagram. Don't try to make everything work at once. The best way is to take the supplied PLC programs and modify them only as necessary. Backup the registry and configuration file often.

You should ask Delta Tau for this...not to be difficult, but I am not sure if I have a current revision version, and I am not sure if it is public domain code or not. Now that I look at it, the thing that I posted uses the master handwheel function, and not the jog to position function that I refer to. Ask Delta Tau for Handle.plc for an example of the other.

Now that the discussion has been taken offline, when you people resolve this problem, can you post a summary? I think I may have some related strange behavior on one of our machines and am curious about the resolution.

If the total accel time (2*TA or 2*TS, or combination, or default TA for the coordinate system) is longer than the move time at the desired feedrate then you will never reach the desired feedrate. This is common for short segments. In your case, the variation in velocity is likely due to the fact that the segments are different lenghts, and the amount of time accelerating and decelerating is varying, but it is never hitting the desired speed.

It sounds like what you mean by quantization error is that the slide motion is rough. You are saying that you scale it such that each click of your hand wheel is .0025". If you use the master handwheel function in PMAC you are essentially creating instaneous step inputs to the position command, with no commanded accel/decel/velocity, which, if the move is far enough for given machine might seem rough. Delta Tau mentions using an exponential filter (see User's Manual) as a possibility to smooth this, although I believe that most people implement a handwheel by writing a PLC to read the input from the handwheel and then "jog" the axis based on this input. That way the jog acceleration and jog velocity can be adjusted to make the operation more smooth. The handle.plc in the NC package is an example. This is from the delta tau web site: http://www.deltatau.com/Common/technotes/Handwheel%20Slewing%20PLC.pdf This should help

I agree with your comments, and would not have purposely created such a signal either, but thought that maybe there is an approximate signal that was created for some other purpose that I was not aware of. It turns out that what I really need is a band pass filter on the following error signal whose center frequency is variable, and I only need to have this signal occassionally, so I will just write a PLC that implements a digital IIR filter. Thank you for taking the time to respond.

Other than writing a PLC to calculate it, is there a signal within PMAC that is (or approximates) the RMS or some other time averaged value of a motor following error?