curtwilson

To get the equivalent of this Mx61 Turbo PMAC register in Power PMAC, use Motor[x].DesPos - Motor[x].ActiveMasterPos - Motor[x].CompDesPos - Motor[x].HomePos Motor[x].Desired.Pos is the position at the start of the present section or segment of commanded motion (i.e. p0 for the present equations of commanded motion.

If it is just a motor move rolling over between maximum positive and negative values (in either direction), there will be no problem in operation. However, if the motor is moving because it is assigned to an axis, and the motor position rolls over because the matching axis position goes out of the motor range, you will get a fault because the math cannot work out to a proper position. It is a very rare Turbo PMAC application where this is even a potential problem. Reducing Ixx08 in these applications extends the real range proportionately.

There are controllers that do explicit jerk limiting for single-axis moves, where the math and logic are much easier, but limit jerk by low-pass filtering for multi-axis path moves. Check the implementation very carefully. The low-pass filtering needed for jerk limiting once acceleration limiting has been done through lookahead can have a much higher cutoff frequency and so have very little effect on the path.

Limiting jerk in the general case is a very difficult problem. When all of the moves are long -- long enough so that they always have a constant-speed section between blends -- it is not so difficult, and properly computed TS times can limit jerk. In Power PMAC for these types of moves, you can specify maximum jerk and let PMAC calculate the TS time automatically. But when you use a TS time to limit jerk, the blend between moves (and to or from a stop) always starts and ends at zero acceleration. Again, for long moves with a constant velocity section, this is fine. But in this case, you would not need lookahead even just for acceleration control. When you have short moves, for example when you need to accelerate up to full speed over many moves, jerk limiting with S-curve at the programmed move level is not appropriate, because each little move starts and stops at zero acceleration. If you would plot the velocity versus time profile here, it would look like a series of steps (or escalators). This is almost never desirable, so in these applications, virtually everyone sets TS to 0. Ideally for these applications, you would have a maximum jerk parameter for lookahead just as there is maximum acceleration and velocity. But it turns out that jerk limiting in lookahead is much, much more difficult than acceleration control in lookahead, just as acceleration control in lookahead is much more difficult than velocity control. When a lookahead algorithm tries to solve a jerk problem in one axis, it can make the jerk, acceleration, or velocity of other axes worse. Even if a general multi-axis solution is available, it would take at least 10 times the calculation of the present lookahead. Some users add a low-pass filter to the trajectory after lookahead. With Turbo PMAC, you can use a 1st order filter with Ixx40. With Power PMAC, you can use up to a 4th-order filter. This is not as good as an ideal lookahead limit, but some people find that it is good enough.

Yes, move times in Power PMAC for PVT and SPLINE mode moves are double-precision floating-point values. In Turbo PMAC, if I42 is 0, the time has a resolution of 1/4096 of a millisecond, but also a maximum time of 4096 milliseconds.

It is possible to limit the maximum voltage that will be applied to the motor in operation with a reduce value of Ix66. However, there are two key considerations you must take into account. One is that you lose some output resolution. If you want to limit to 1/3 of the bus voltage, you lose ~1.5 bits of output resolution. You have to evaluate if this reduces performance for you at all. The other is that a mistaken setting of Ix66 (too high) could allow your motor to be destroyed. Some people are willing to take this risk; others are not. It is a system decision you must make. On the scaling of Ix66: it depends on the details of how the PWM signal is generated in hardware. The internal algorithms first calculate a normalized value between -1.0 and 1.0. This is multiplied by Ix66 before it is written to the hardware PWM register. In the Geo MACRO hardware, and in the PMAC3-style ASIC that can be used with Power PMAC, a value of +/-16,384 in the PWM register produces +/-100% duty cycle and applies full bus voltage, regardless of the PWM frequency. In the PMAC2-style ASIC used in Turbo PMAC for PWM generation, a value of +/-I7m00 in the PWM register produces +/-100% duty cycle. I7m00 sets the PWM period, so is inversely proportional to the PWM frequency. Therefore, the value of Ix66 that produces a certain maximum voltage is inversely proportional to the PWM frequency.

Unfortunately, changing the default would create major backward incompatibilities for users "right out of the box".

Try setting Sys.NoShortCmds to 1. This disables most single-letter commands so that they cannot be confused with user names. (e.g. you must use "begin" for "b", "abort" for "a")

What firmware version are you using? The algorithm worked as advertised on firmware versions before the one you are using (the pre-release versions where we tested and documented the setup), and it also works on firmware versions after the one you could be using (the pre-release version we have in development). We have no record of any changes to the deadband algorithms, and no other reports from the field that it does not work properly using the prescribed setup. We have been using this technique successfully for 20 years now on various PMAC controllers. This is why we are trying to identify whether there is something else in your setup that could be preventing it from working as it should.

Did you change Motor[x].Ctrl from the default of Sys.ServoCtrl to Sys.PidCtrl? If you selected this very basic PID algorithm, the deadband terms are not used. In the standard algorithm selected by Sys.ServoCtrl, the suggested deadband terms stop dithering at rest from fractional count errors even with a non-zero integral gain value.

Frankly, the change was not intended (combination with NAND gate rather than AND gate), but it was not caught until the chip design had been frozen. That's the only one like that I'm aware of.

To answer your questions: 1. The tables have no automatic inversion function. The math to do the inversion is fairly complex for first-order interpolation; I have not even attempted it for third-order interpolation. 2. Yes, the tables require equally spaced points. 3. The problem that comes from FK and IK conversions that are not exact inverses of each other is this: At the beginning of a motion program, the FK routine is automatically called so that that starting axis position (your magnification value) is computed from the present motor position. Immediately after this, the first little programmed increment (a segment of a few milliseconds) of the commanded axis trajectory away from this starting position is converted to motor position through the IK routine. If the two functions are not exact inverses of each other, there will be a jump in executing the first cubic position segment from the starting point to the first segment endpoint. If it's really bad, say due to an outright programming error in the routines, this could cause a fault. I doubt that 0.7% would cause any kind of fault, but you (and/or your customer) would have to assess whether it is tolerable or not. This could be tempered somewhat with a trajectory pre-filter acting as a low-pass. I should mention that many people do an iterative solution for one of their routines, especially for the FK, so they can get it to converge very closely to the true inverse of the other function.

You may want to consider using the kinematics subroutines to convert between your magnification values and the matching motor positions. The forward kinematic subroutine would convert from motor position to magnification ("axis") value. This would be used for reporting purposes. (It is also needed to compute present "axis" value when starting a motion program. The inverse kinematic subroutine would convert from magnification value to motor position. When you command an axis value, this is used to compute the underlying motor position. The mathematical functions in these two subroutines must be exact inverses of each other, so for any position you can convert back and forth and end up with the same value.

Thank you for catching this. The line should read: Motor[2].pCaptPos = Gate3[0].Chan[1].HomeCapt.a

From the User's Manual for pulse-and-direction output mode: Deadband Because it is easy to command end positions with fractional-count components and the system can only resolve full count (pulse) values at rest, it is strongly advised to implement a count of true deadband in the simulated servo loop to prevent dithering at rest. To do this, the following settings should be made: Motor[x].Servo.BreakPosErr = 1.0 // For motor scaled in counts (pulses) Motor[x].Servo.Kbreak = 0 // Zero gain inside deadband zone

It seems to me that you are making this far more difficult than it needs to be. What virtually everyone does in this type of application is to turn the entire sequence of moves into a single "part program" that is very much (or exactly) like a CNC "G-code" part program. I don't see any need for subprograms or parameters - just a straight sequence of programmed motions.

If you must poke values directly into a motor register servo cycle by servo cycle, you can use one of three registers: Motor[x].Desired.Pos Motor[x].MasterPos Motor[x].CompDesPos Power PMAC will automatically sum these three into the net Motor[x].DesPos and calculate Motor[x].DesVel from this. Motor[x].Desired.Pos can be used if no trajectories are being calculated for the motor. Motor[x].MasterPos can be used if no position following is active for the motor (Motor[x].MasterCtrl=0). Motor[x].CompDesPos can be used if no cam table or compensation table targeting this register is active.

An Open Servo is really just a PLCC 0 that executes under the servo interrupt instead of the real time interrupt. Look at the User's Manual chapter on Servos for instructions on how to set it up.

We do not have a de-compiling tool for these. Many users want the security of knowing that the source code of compiled PLCs cannot be derived.

1) The required wire diameter should be based on acceptable voltage drop over the length of the cable. Especially for the voltage inputs and outputs, the current flow is very low, so the voltage drop is typically negligible. We have never seen a situation where the required wire diameter caused connection problems. 2) Typically, twisted pairs provide much better noise immunity than parallel conductors. They are strongly recommended for high-resolution ADCs and DACs. 3) We provide +/-15V on the connectors in case the circuitry needs to be powered from the UMAC. If the external circuitry has its own supply, there is no need to use these.

You have your algorithm in a background PLC program. You may want to move it into a foreground PLC program (PLCC0) with I8=0, or even an Open Servo algorithm for an additional virtual motor to get it to run at a higher update rate. I don't know if that will make enough of a difference for you.

The software limits are automatically disabled during the pre-trigger portion of the homing, because before you find the home trigger, you have no reference for the soft limit numbers. However, as soon as the trigger is found, the reference is established and the soft limits are enabled. This does NOT wait until the post-trigger move to the home offset is finished. So if you are homing into your hard limit and you have your soft limit set either inside of the hard limit or close outside (within the deceleration distance), you will get this limit fault if your SW limits are active at the time of the homing search move. When I tried this, I did get the "SoftMinusLimit" status bit set. A little more precisely, the "LimitStop" status bit indicates that the limit (HW or SW) was caught at move execution (rather than move calculation time). The HW limits can only be detected at move execution time. The SW limits are almost always caught at move planning time (but not in this case, of course).

You have several options here. 1. You can set the outer-loop Motor[x].pDac to Sys.Idata.a to write to a 32-bit integer in the user shared memory buffer. The conversion table can then pick this up with a single-register read using EncTable[n].type=1 and EncTable[n].pEnc=Sys.Idata.a. 2. Without caring where the outer loop writes its servo output, you can have the ECT pick it up directly from the (floating-point) holding register using EncTable[n].type=11 and EncTable[n].pEnc=Motor[x].IqCmd.a. The latest User's Manual has an expanded section on the setup of cascaded servo loops.

The added inductance limits how fast the current in the motor can change (di/dt = V/L). Sometimes a low-inductance motor is selected to achieve very high rates of change of current, and therefore torque.

This "input deadband compensation" is always on, modifying the FE into the algorithm.