curtwilson

The thing you have to watch out for is what happens to the zero position of the resolver when you change direction. I think the Ixx75 phase position offset will be your key variable here.

I can't duplicate this problem. My own user servos run fine assuming an externally computed PosError term. I checked the internal code. PosError is computed before the specific servo algorithm is called. Our own built-in servo algorithms do not compute PosError inside them -- they also rely on this term being computed before they start.

Thank you for the diagram. That helps a lot. If I understand you now, the problem is that one of the two motors on one single track is faulting on I2T. Both of these motors are - or should be - getting the exact same torque (quadrature current) command, so why is one failing on overcurrent, and the other is not? I think the most likely reason is that the coils on the two motors are not installed to the same phasing relative to the magnet common magnet track. The motor that is out of ideal phasing will see less back EMF and therefore permit more current to flow.

I have been trying to figure out where this problem is coming from. I will say that it is far more common in this type of application to put the motor in following mode with Motor[x].MasterCtrl = 3 so it is in "offset mode", permitting the following and any trajectory to superimpose. In "normal mode", any motion command, even an implied zero-distance command, tries to take out what the following has put in. This might be creating the So please try the following in offset mode. Make sure that a "pmatch" command is executed, either explicitly or implicitly (as when starting a motion program), each time the mode is changed. In most of these applications, you changing activation and mode at the same time (MasterCtrl between 0 and 3), so that is when you must make sure the "pmatch" is executed.

Yes, changing between the "clockwise" and "counterclockwise" conversion of the resolver inverts the direction sense of the resulting position, without any cabling changes. Internally, this changes the value of bit 19 of the first setup word for the entry. It is the equivalent of changing I7mn0 between 3 and 7 for a quadrature encoder. You will have to evaluate the effect of this on the absolute power-on phasing read as well as on ongoing position.

The ACC-24E2A has an interlock circuit monitoring its supply voltages. If a supply is lost or dips below a threshold, power is dropped out to the output op-amps, and the "power good" LED is turned off. The primary intent of this circuit is to prevent the outputs from pulling to one rail when the opposite supply is lost (obviously a very dangerous possibility). It also can indicate an overloaded supply. Do you still trip on enabling when it is disconnected from the drive? Can you see a dip in the supply voltage(s) when enabling? Does your drive draw significant supply current through the ACC-24E2A when enabled?

Yes, Power PMAC uses the corrected motor position to compute the axis position that it reports.

I'm sorry, but I am not understanding your configuration. If there is only one feedback for the two motors in a gantry system, both motors will have the same command and feedback, and therefore the same servo command output going into the I2T check. Of course, if there is separate feedback for each motor, the servo output could be different if there is different load on the two motors. You can read Motor[x].Servo.Integrator at any time, but the servo algorithm will overwrite any value you write to it from outside. Remember that this is the position error integrator, not the command output integrator. The command output integrator value is in Motor[x].I2tSum. This is compared to I2tTrip for the fault calculations. If your I2T limits are set well, then a fault is a real problem that must be dealt with by figuring out how to reduce the demand on the motor.

The units of the MaxChange word are LSBs of the source data word per servo cycle. This is explained in the software reference manual for the variable (where detailed information usually resides). Since you are getting your data over the MACRO ring, it probably already has been interpolated to 1/32 count, so 1 LSB of the source data equals 1/32 count.

All of your M-variables are represented by elements of the GateIo data structure, with "i" = 0 for your address. Your M7000 - M7005 use GateIo[0].DataReg0 through GateIo[0].DataReg5. Your M7006 uses GateIo[0].IntrReg. You M7007 uses GateIo[0].CtrlReg. You can use the "alias" of Acc14E[0] instead of GateIo[0] if you want - it may make your commands more obvious. In Power PMAC, these ICs have saved initialization values using the GateIo.Init (or Acc14E[0].Init in your case) substructure holding memory registers. You can set these up once to eliminate the need to configure the actual hardware registers in your own PLC code every time you power up.

There is nothing in the sent messages that encodes for color -- just ASCII characters and escape sequences. Any color coding is done at the application level. You could set up your own encoding scheme for telling the host computer what color to display the message in.

Usually these types of errors occur when the position feedback data is transferred numerically to PMAC, as a parallel or serial word. If noise causes a bit to be read wrong, PMAC can think there is a huge position error. For example, if bit 15 is flipped, that causes a 32K count error. To counter this, we have "filtered" reads for this kind of data in the encoder conversion table that allow you to specify a "maximum change" value (from one servo cycle to the next) that you will regard as "real". If the data read in a cycle creates a change from the previous cycle that is bigger than your threshold, PMAC will discard it and calculate a substitute position that uses the same change (velocity) as in the previous cycle. You should set your threshold slightly greater than the maximum true velocity you expect to see.

Here is an old application note that uses the same technique for a similar purpose - to obtain the electronic ID number internally for use as a software dongle.

Your setting for I8002 ($EC0009) is integrating the result for I8009, and it should be integrating the result for I8001 (the velocity command for Motor 1), so it should be set to $EC0001.

There should be no reason why you cannot execute a RAPID mode move from a motion program or its subroutines and subprograms. People do it all the time. You should not need to use the CMD"" structure in a motion program to execute a RAPID mode move, even a triggered move. A couple of notes on the differences between PLC program execution and motion program execution that you should be aware of: Commanding a move in a PLC program automatically puts the addressed coordinate system (Ldata.Coord) into RAPID mode. In a motion program, you must explicitly declare RAPID mode. At the start of execution of a motion program, the PMATCH function is automatically executed to calculate the starting axis position(s) from the present motor position(s). This does not happen in a PLC program. Things like this can be tested easily from the terminal command line with the "cpx" (one-line one-shot motion program) and "cx" (one-line one-shot PLC program) functions. Try commands like: &1 cpx rapid Z1000^-0.1 which functions as a motion program, and cx Ldata.Coord=1 Z1000^-0.1 which functions as a PLC program.

Did you get motor motion in these tests? If you did get motion, did PMAC detect it? If you turn the motor by hand, do you see the motor position in the IDE's position window change? Most likely, something in the encoder hardware or the software that processes it is not working properly, so PMAC thinks the motor is not moving.

We have tracked this down now. The re-initialization algorithm treats the two MACRO ICs on a fully populated ACC-5E as having separate bi-directional buffers. It sets up the first IC for clock outputs and the buffer for clock outputs. Then it sets up the second IC for clock inputs and the buffer for clock inputs, overwriting the original buffer direction. This has been fixed now in our working development firmware, and will get into the next maintenance release. Thank you for helping us track this down.

The simplest way to do this is to redefine the axis position after you are homed. From a motion program, you could use a program command like PSET C90. The on-line command is like C=90. From a PLC program you would use something like CMD "&1C=90". Your software overtravel limits and any compensation tables are still referenced to your home position, not your programming zero, but that is all "under the hood" stuff that users and part programmers don't have to worry about. For them, the home position is 90 degrees.

We have many times done very good velocity control of spindles, flywheels, etc. with feedback resolution this low, or lower (down to 1 pulse per rev even). Remember that, at speed, our 1/T extension gives you a much higher effective resolution. So I would advise as a first attempt to set it up just as a standard vector-controlled induction motor. It's possible you may need to do something special at stop to keep it from hunting between pulses. If you really need to Please refer to the Power UMAC User's Manual (Aug 2012) section on open-loop direct microstepping (starting on page 172), available here in. It appears to me that you will need to modify these instructions in two key ways. If I understand you correctly, you do not want to close the current loop in PMAC, so you will want to set Motor[x].pAdc to 0 to disable the current loop functionality, and you can of course ignore all of the current-loop settings. Second, you will need to rescale the processing of the output of your simulated servo loop in the encoder conversion table. A stepper motor is driven solely with "direct current" (Id), so we want to keep the "quadrature current" (Iq) component very small. To do this, we multiply the servo output by a large number in the encoder conversion table entry before it is used for simulated servo feedback. In the recommended setup for stepper motors, EncTable[n].index5 is set to 63 for a 64x multiplication factor. For induction motors, you will need more Iq, so I would use a smaller index5 multiplier.

Inside your PMAC, PROG 1000 contains all of your G-code subroutine implementations. You, or whoever wrote this program for your system, should add the subroutine for the G73 implementation you want.

The motor must be undefined from "within" the coordinate system in which is it is presently defined. This is a protective mechanism, as it is very easy to screw things up in redefining coordinate systems.

The manual correctly describes how the PMAC interprets the G-code numbers. The values are intrepreted mathematically, not textually (i.e. the label is the G-code number times 1000). This does permit some nifty extensions when the code number is calculated. It has worked this way in our controllers for over 20 years now.

In the Turbo PMAC, you can get at these with M-variables. Mxx75 and Mxx76 are the suggested M-variables for actual quadrature and direct current, respectively. Commanded quadrature current is the servo output, suggested Mxx79, and the commanded direct current is Ixx77.

The lookahead buffer size can be changed as part of the project properties window in the IDE. This requires the V1.5 IDE that was released this past summer.

A G-code in a PMAC system is simply a form of a subroutine call. A subroutine must be written to implement the desired functionality. Did someone else write the G-code subroutines that you are successfully using?