curtwilson

Your torque per unit current is proportional to the cosine of the error in determining your phase angle, so is maximum when the error is zero. Small errors don't reduce torque much. Moderate errors can be insidious because the servo reacts by asking for more current, and you can get overheating much later (when it is difficult to relate the failure to its ultimate cause). Also you have effectively lowered the gain of the loop, which throws your tuning off. But the real danger is when your error is greater than +/-90 degrees of the commutation cycle. This changes the sign of the torque applied, which creates unstable positive feedback instead of stable negative feedback and can cause a runaway. So, if I have interpreted you correctly, an improper phasing search move or absolute phasing read is causing your problem. I think that is where you need to look first. I would start by making sure that the "stepper motor" phasing search works reliably and repeatably with an unloaded motor, even if you plan on using a different method in the actual application.

On both the outer (position/load) loop and inner (velocity/motor) loop, there are two scale factors that can be employed in processing the feedback. The first is the output scale factor from the encoder conversion table entry processing the hardware registers: EncTable[n].ScaleFactor. The second is the motor input scale factor for the feedback, which multiplies the result of the ECT entry: Motor[x].PosSf for the outer loop, and Motor[x].Pos2Sf for the inner loop. For performance, it does not matter what these scale factors are, because the double-precision floating-point math that closes the servo loops has enough dynamic range to process feedback with any reasonable scale factor. However, it is important to realize that, technically, these scale factors act as gain terms in the servo loop. So if you double one of these scale factors, you would need to halve a subsequent gain term (e.g. Kp or Kvfb) to get the same performance. The only thing that the inner-loop scaling affects is the velocity loop gain terms Kvfb, Kvifb, and Kafb. But we do have some general recommendations on the scaling for ease of understanding and use. We usually recommend that the ECT scale factor be set so the entry result is in units of the feedback. For digital quadrature encoders, this is for each quadrature count to be a unit (4 per line). The "1/T" timer-based sub-count interpolation is fractional. For sinusoidal encoders, most users also scale the feedback into quadrature counts as well, with the arctangent interpolated data used as fractional values (no resolution is lost this way). Some users do prefer the output to be scaled in LSBs out of the interpolator (1/16384 of a line for you). For the motor scale factors, we generally recommend that the inner-loop scale factor Pos2Sf be adjusted so that after this multiplication, the scaling of the inner loop feedback position numerically matches that of the outer loop. Again, this is not a performance issue, but it can make testing easier when switching between single and dual feedback for evaluation. This is true whether you decide to scale your motor in feedback units like quadrature counts (usually outer loop PosSf = 1.0) or in engineering units like millimeters. In either case, the ratio of Pos2Sf to PosSf would be the same.

To answer your questions: Yes, it is possible for multiple segments to be processed in a single RTI (provided of course, that the CPU has enough time to do the computations!). So it is possible, but maybe not wise, to have the RTI time larger than the segmentation time. You are correct in your guess of the order of calculations within an RTI. Unless you are doing kinematic transformations or circular interpolation, and since you are not using lookahead, I don't think that segmenting the moves is adding any functionality for you -- just adding complexity and computational overhead. By computing very short move sections, you are effectively already performing segmentation yourself. Most people who want this kind of functionality do this straight from a looping Script motion program. For example: linear abs while (Looping) { MyMoveNum++; MyXpos = {whatever} MyYpos = {whatever} MyMoveTime = {whatever} N(MyMoveNum) X(MyXpos) Y(MyYpos) TM(MyMoveTime) TA (MyMoveTime) TS0 } The sequencing engine of PMAC's Script environment will automatically execute a loop once per move. This eliminates all of the handshaking complexity you are struggling with. If you want to do your calculations in C, you can call the "CfromScript" subroutine each time through the loop.

Each RTI, the coordinate system checks whether it is time to calculate the next move in the program buffer. During a continuous sequence of motion, the trigger for it to do this computation is the transition in move execution from one move to the next. This sets a flag telling the CS algorithms it is time to fill the move equation pipeline again. For example, if you have an RTI period of 1 msec and moves of 10 msec, new move calculations from the buffer will only be done 1 out of every 10 RTIs. It appears that you are not doing any handshaking between your program generation algorithm and the program execution. Whatever the reason for the drift between the two that you are seeing, a lack of handshaking is not wise. A simple fix would be to add a numeric line label to the beginning of each program line you create (e.g. N475). When the motion program calculates that line, it sets Coord[x].Ncalc to the value of the number. When it starts the actual execution of the move from that line, it sets Coord[x].Nsync to the value of the number. Your code-generating algorithm could monitor one or both of these elements to stay the desired amount in front of calculation and execution.

I think one way or another you will have to create your threshold in user code. If you are tracking the input with one of our automatic algorithms like position following, you will want a PLC program that monitors with something like: if (abs(Motor[x].DesVel < MyEpsilon)) Motor[x].SwZvInt = 0; else Motor[x].SwZvInt = 1; If you are implementing the tracking in user code, it would be easy to create a deadband in that algorithm.

You write your subprograms to implement whatever "dialect" of G-codes you want. In most cases these subprograms are permanently saved on the PMAC. Then each part program is loaded as needed and calls the routines in the subprograms through its G-codes, M-codes, etc. If you have to support several different dialects on your machine, there are a couple of ways of doing this. First, you could load in different subprograms when you change dialects. Second, you could have logical branches in the subprogram that perform different tasks for the same code based on a global variable that specifies the dialect being used at the time.

The Laser Scanning Interface is implemented as new logic in the ACC-84x serial encoder interface boards (84E for UMAC, 84B for Bricks, 84S for Clipper. So instead of providing 4 channels of serial encoder interface, the board will provide 3 channels of XY2-100 serial command output, plus a PWM output for modulating the laser. We are demonstrating the system this week at the ATX show in Anaheim. We should have the "paperwork" for release (test procedures, manuals, price list changes) ready in about a month. The price will be the same as an ACC-84x with serial encoder logic.

If you set Motor[x].Ctrl to Sys.PosCtrl, you select the built-in "position output" algorithm, which has only a couple of lines of code in it to output the commanded position as an integer to the specified (by Motor[x].pDac) register. The main intent of this algorithm is for networked position-mode drives, but it is good for virtual axes as well. You might find this easier than maintaining a custom dummy servo.

With I64 set to 1, any "unsolicited" strings from the Turbo PMAC -- i.e. those resulting from an internal SEND or CMD statement rather than a host command -- are preceded by this character (ASCII 02, , STX). The purpose of this is to allow the host program to distinguish this from a command response. Most users prefer this setting, as it permits the host software to handle these easily and reliably.

To expand on my comment of Jan 15, if there is no motor (real or virtual) assigned to the axis, only the initial move calculations, such as endpoint position, will be done for that axis. So you will get CdPos endpoint values that change once per move, but there will be no servo cycle by servo cycle updates, as that only happens for motors. (Fundamentally, the transfer of information from axis to motor occurs a lot earlier than you have assumed it does.) So if you want information that is updated more than once per programmed move, you will need to assign a motor to the axis. For this virtual motor, I expect you will want to disable following error, amplifier fault, and overtravel limit faults.

The best way to figure out what is going on is to plot the desired velocity profile through data gathering. There are many different limiting factors that could occur at different stages in the calculations. I don't think it would be feasible to flag all of them.

If you command a phantom axis with no motor (physical or virtual) assigned to it, the initial axis calculations will be done for it. For instance, you can see the programmed move end position in Coord[x].CdPos. However, the subsequent calculations that would involve transfer to an assigned motor, which are much more time consuming, are not performed in this case. Conversely, when a motor is assigned to an axis, but that axis is not explicitly commanded in a program command, the initial move commands do not need to be done for it (as the axis move end position is the same as the start position), but subsequent calculations for the assigned motor must be done to provide zero-distance, zero-velocity move equations for the motor matching the other motors in time. To test the calculation times for things like this, I like to construct some looping motion programs with small move times inside the loop in the different configurations, then look at the PMAC CPU Task Manager screen in the IDE as they execute.

If you command a phantom axis with no motor (physical or virtual) assigned to it, the initial axis calculations will be done for it. For instance, you can see the programmed move end position in Coord[x].CdPos. However, the subsequent calculations that would involve transfer to an assigned motor, which are much more time consuming, are not performed in this case. Conversely, when a motor is assigned to an axis, but that axis is not explicitly commanded in a program command, the initial move commands do not need to be done for it (as the axis move end position is the same as the start position), but subsequent calculations for the assigned motor must be done to provide zero-distance, zero-velocity move equations for the motor matching the other motors in time. To test the calculation times for things like this, I like to construct some looping motion programs with small move times inside the loop in the different configurations, then look at the PMAC CPU Task Manager screen in the IDE as they execute.

I think that resistor will also be fine. You should calculate what the flow through this resistor would be if the field weakening failed at your maximum RPM.

I think that resistor will also be fine. You should calculate what the flow through this resistor would be if the field weakening failed at your maximum RPM.

More precisely, if the time for any of the non-feedrate axes, as calculated by (AxisDistance/AltFeedrate), is greater than the time calculated for the combined vector feedrate axes (VectorDistance/Feedrate), it will use this longer time, and the actual vector feedrate used for the move will be less than what was commanded.

More precisely, if the time for any of the non-feedrate axes, as calculated by (AxisDistance/AltFeedrate), is greater than the time calculated for the combined vector feedrate axes (VectorDistance/Feedrate), it will use this longer time, and the actual vector feedrate used for the move will be less than what was commanded.

The shunt circuitry turns on at 385VDC, which corresponds to 272VACrms. An external shunt resistor (15ohm, 300W) is recommended if there is a possibility of going above this.

The shunt circuitry turns on at 385VDC, which corresponds to 272VACrms. An external shunt resistor (15ohm, 300W) is recommended if there is a possibility of going above this.

A "feedrate" value is a commanded vector speed of your "feedrate axes". The intent of this functionality is to get a constant tool-tip speed in 2D or 3D Cartesian space without the user having to compute the individual axis speeds. PMAC does this by first computing the vector distance of the feedrate axes by Pythagorean theorem, then dividing by feedrate to get the move time. By default, the "feedrate axes" are X, Y, and Z. It is possible to change this with the FRAX command, but very few people do (and I don't think you have changed this). The idea of a constant vector feedrate regardless of direction does not make geometric sense with more than 3 dimensions. In your example, your vector distance is zero. Since you also have "non-feedrate" axes (U and V), it instead computes the move time by dividing the commanded distance of each non-feedrate axis by the saved parameter Coord[x].AltFeedrate, and taking the largest of these times. The resulting motor speeds are then compared to Motor[x].MaxSpeed for each motor, with the move time extended if any of these limits are exceeded. So you first need to check your value of Coord[x].AltFeedrate, then the values of Motor[x].MaxSpeed as Greg said.

A "feedrate" value is a commanded vector speed of your "feedrate axes". The intent of this functionality is to get a constant tool-tip speed in 2D or 3D Cartesian space without the user having to compute the individual axis speeds. PMAC does this by first computing the vector distance of the feedrate axes by Pythagorean theorem, then dividing by feedrate to get the move time. By default, the "feedrate axes" are X, Y, and Z. It is possible to change this with the FRAX command, but very few people do (and I don't think you have changed this). The idea of a constant vector feedrate regardless of direction does not make geometric sense with more than 3 dimensions. In your example, your vector distance is zero. Since you also have "non-feedrate" axes (U and V), it instead computes the move time by dividing the commanded distance of each non-feedrate axis by the saved parameter Coord[x].AltFeedrate, and taking the largest of these times. The resulting motor speeds are then compared to Motor[x].MaxSpeed for each motor, with the move time extended if any of these limits are exceeded. So you first need to check your value of Coord[x].AltFeedrate, then the values of Motor[x].MaxSpeed as Greg said.

Because PMAC closes a current loop to maintain the desired current level, I would not worry about overcurrent problems here. The worst case for possible overcurrent is at zero velocity, when there is no back EMF. The bigger worry in field weakening a permanent magnet motor is what happens when the field weakening is removed (as with some kind of fault) when the motor is at very high speed. Can the amplifier take the full voltage of the back EMF? For instance, at 700 rpm, your motor would produce 290V. (Is this RMS? I think so.)

Because PMAC closes a current loop to maintain the desired current level, I would not worry about overcurrent problems here. The worst case for possible overcurrent is at zero velocity, when there is no back EMF. The bigger worry in field weakening a permanent magnet motor is what happens when the field weakening is removed (as with some kind of fault) when the motor is at very high speed. Can the amplifier take the full voltage of the back EMF? For instance, at 700 rpm, your motor would produce 290V. (Is this RMS? I think so.)

You have a couple of options here. The easiest is to use the Ixx56 term, "commutation delay compensation". Most people just use this at very high commutation frequencies to compensate for the delay between input and output of the commutation algorithm. However, if you use values higher than what is necessary just to compensate for these delays, you create a "phase advance" that has the effect of field weakening at higher speeds. The second strategy is to use negative values for Ixx77 magnetization current at high speeds. You would have to implement this functionality in a PLC program, setting Ixx77 as a function of motor speed, making the values increasingly negative at higher speeds above "base speed" (the speed at which the back EMF is close enough to the supply voltage that you can just get the desired torque). If you do aggressive field weakening, you must remember that if your algorithm fails for any reason, including a fault, the amplifier will be exposed to the full (unweakened) back EMF of the motor at that speed. People have destroyed their amplifiers this way.

You have a couple of options here. The easiest is to use the Ixx56 term, "commutation delay compensation". Most people just use this at very high commutation frequencies to compensate for the delay between input and output of the commutation algorithm. However, if you use values higher than what is necessary just to compensate for these delays, you create a "phase advance" that has the effect of field weakening at higher speeds. The second strategy is to use negative values for Ixx77 magnetization current at high speeds. You would have to implement this functionality in a PLC program, setting Ixx77 as a function of motor speed, making the values increasingly negative at higher speeds above "base speed" (the speed at which the back EMF is close enough to the supply voltage that you can just get the desired torque). If you do aggressive field weakening, you must remember that if your algorithm fails for any reason, including a fault, the amplifier will be exposed to the full (unweakened) back EMF of the motor at that speed. People have destroyed their amplifiers this way.