curtwilson

The issue of jerk control in lookahead is a thorny one. The algorithms for acceleration control in lookahead are by far the most complex we have ever done, and are very computationally intensive to execute. As we have evaluated jerk control lookahead algorithms, they look to be at least 5 times more complex and 5 times more computationally intensive. It also is not clear that they could be done in real time at all -- with acceleration control, as long as you are looking ahead your stopping distance, you will be fine, but there does not appear to be any hard and fast rule when you add jerk control to the mix. (Note that the jerk control that Power PMAC does with the InvJmax term is not part of lookahead. It works only on the initial move calculation. For basic LINEAR moves, it can extend the TS time if the time you specified creates a jerk that exceeds this limit.) What lookahead gives you that you like is the ability to separate out your corner size from your acceleration magnitude. You can set a small corner with a small TA time (the corner blending starts and ends F*Ta/2 distance from the programmed corner point) but control your rate of acceleration with Ixx17 in lookahead. This allows you to slow down before you start cornering, take the corner slowly within limits, and accelerate after you come out of the corner. (This is the way you take a sharp corner in your car.) Unfortunately, this is done without good jerk control, as you have noticed. So what to do? The short answer is that the best strategy presently is to control acceleration with lookahead, then add a low-pass filter to the resulting trajectory with Ixx40 in Turbo PMAC, or the higher-order trajectory pre-filter in Power PMAC. Several Turbo PMAC users with similar concerns have achieved what they consider satisfactory results with this combination. Some background: Turbo PMAC's Ixx40 filter and Power PMAC's trajectory pre-filter are, in signal-processing jargon, "causal" filters, because they do not have access to any future information. By contrast, PMAC's blending acceleration control (TA and TS) and buffered lookahead algorithms are "non-causal" filters, because they do have access to future information in the trajectory -- the simple blending looks one move ahead, and the buffered lookahead can look many moves ahead. (They are also technically mathematically non-linear filters, but that is not of concern here.) In general, non-causal filters will have superior performance characteristics because they can "know" more. (Digital audio generally uses time-symmetric non-causal filters and just delays the output by the time required to complete these filters.) In the case of motion trajectories, the non-causal filters disturb the path much less than the causal filters. Adding acceleration control to your trajectory does two important things. First, by limiting the magnitude of acceleration, you are respecting the physical limits (torque, force, current) of your system. But second, it is a low pass filter, reducing the high-frequency energy in the trajectory, so it will not stimulate the high-frequency dynamics of your machine. However, to do this with a causal filter requires a long time constant, and so a low-cutoff frequency, and gross path distortions. Adding jerk control to your trajectory also does two things. By limiting the rate of change of your desired acceleration, it also limits the rate of change of your desired motor current, thereby respecting the inductance in your windings. But mainly, it is a low-pass filter that reduces the high-frequency energy in your trajectory. It turns out that if you have done the bulk of your low-pass filtering with a non-causal acceleration filter (TA and/or lookahead), you can add a causal filter on top of this with a short time constant (high cutoff frequency) to further roll off the high-frequency content of your trajectory with minimal distortion to the path. That is what I am recommended. It just so happens that I have been experimenting this week with various combinations of non-causal acceleration filtering and causal filtering added to that. Lots of combinations, and lots of FFT plots. Qualitatively, I have confirmed the results I have just stated above. I hope to get more quantitative results soon.

The standard frequency accuracy specification from our component suppliers for the crystal clock oscillators is +/-50ppm from the nominal frequency. On a few of our products, we offer at extra charge an oscillator with a +/-10ppm specification. Ultimately, all times in the PMAC are derived by counting these clock cycles, so this is also the tolerance for things like commanded move times.

In external time base mode, the relationship of setting outputs and reading inputs relative to the motion is not changed. You can think of the mode as compressing and stretching time in proportion to the input frequency. You will have to do something special to protect against significant negative motion of the MPG. External time base can pass through a negative time increment in any given servo cycle. This is valuable in the more common use of slaving the motion sequence to a true master position -- if the master stops and oscillates a little positive and negative, the slave position is maintained in proper relationship to the master. However, this reversibility is only maintained in the present motion section's equations of motion. PMAC does not check to see that it has gone back past the beginning of this section and load the previous section (which may be gone). Of course, in the forward direction, it checks to see that it has gone past the end of the section and loads the equations for the next section. People who create this functionality generally just check in a PLC program to see if the master position is going negative, and if it is, they set the output scale factor of the encoder conversion table entry that processes the MPG position to 0.

What do you mean by "step through a motion program"? As the term is usually used, with a "step" meaning one full programmed move, Sina's suggestion is correct -- you would probably have a PLC program issue an step command after N pulses have been received. If what you want is to increment through the trajectory of moves proportionate to the number of pulses from the MPG, you would use a completely different strategy. Here you would probably want to use our "external time base" functionality, where the "time" elapsed in the trajectory is proportional to the number of pulses received. (It is more common that the pulses come from an encoder on a spindle or web encoder, but the algorithm doesn't care where they come from.) This simple technique works well for moving forward through the program, but it is not reversible. Bi-directional techniques are possible, but tricky to implement.

Most PMAC controllers with analog outputs have an "interlock" circuit to confirm that the analog supplies are solid. The key concern is that if you lost one of the analog supplies altogether, the output would pull to the other rail, possibly resulting in a runaway. So if any of the supplies drops below a threshold, a relay drops out all power to the output op-amps. The threshold for the nominal +/-12 to 15V supplies is about +/-10.8V (-10% from 12V). What can happen with an overloaded supply is that the load will cause the supply voltage to droop below the threshold, causing the relay to open. This reduces the load on the supply, so its voltage increases and the relay closes, increasing the load, etc., etc. You can hear the relay "chatter" as this happens. If it is fast enough, you might even describe this as a "buzz". So I would follow Greg's advice to see what happens with a better power supply.

I think there's a fundamental conceptual issue here. Each coordinate system in a PMAC should be thought of as having a completely independent execution thread for motion programs. So a motion program in one coordinate system cannot "call" a motion program in another coordinate system as a subroutine. However, it can start execution of a motion program in another coordinate system with a program statement such as: CMD"&2B2R" When this happens, the second coordinate system (&2 in this example) starts executing the specified program (PROG 2) in this example in a parallel execution thread. Note that the execution of the motion program that issues this command does not stop. If you want it to stop doing anything meaningful while the other coordinate system is executing its motion program, you must explicitly program it to wait. If this is what you want, you could do something like: P100=0 CMD"&2B2R" WHILE (P100=0) DWELL 10 ENDWHILE and have PROG 2 set P100 to 1 at the end. This behavior is true of all generations of PMAC controllers: PMAC, Turbo PMAC, and Power PMAC.

I got a chance to test it today. I had to tweak the forward kinematics so it could start properly after it had rolled over. Here's the full routine: global Motor1ScaleFactor = 1000.0; global Motor1Offset = 0.0; global Motor2ScaleFactor = 1000.0; global Motor2Offset = 0.0; csglobal OldTheta; // Saved for comparisons in next kinematics csglobal CycleTheta; // Degrees of full cycles to handle rollover csglobal FwdKinErr; // Flag to show failure csglobal FullTheta; open forward (1) local Radius; local Theta; if (Coord[1].HomeComplete) { if (KinVelEna) callsub 100; // Double pass for velocity-reporting use KinAxisUsed = $C0; // Tell PMAC routine calculates X & Y positions N100: Radius = (KinPosMotor1 - Motor1Offset) / Motor1ScaleFactor; FullTheta = (KinPosMotor2 - Motor2Offset) / Motor2ScaleFactor; // Could be outside +/-180 range Theta = rem(FullTheta, 360); // Location within +/-180 range, will be used by inv kin rollover CycleTheta = FullTheta - Theta; // Multiple of 360, indicates cycle count KinPosAxisX = Radius * cosd(Theta); KinPosAxisY = Radius * sind(Theta); OldTheta = FullTheta; FwdKinErr = 0; } else { FwdKinErr = 1; abort1; } close Here's the full inverse kinematic routine: undefine all &1 #1->I #2->I csglobal MaxRadius = 250; csglobal InvKinErr; open inverse (1) // Variables not needed outside of routine local Radius; // Distance from center of rotation local NewTheta; // Computed full angle including rollover local DeltaTheta; // Change in computed angle since last kinematics call Radius = sqrt(KinPosAxisX*KinPosAxisX + KinPosAxisY*KinPosAxisY); if (Radius <= MaxRadius) { NewTheta = atan2d(KinPosAxisY, KinPosAxisX) + CycleTheta; // Tentative, wrong if there has been rollover DeltaTheta = NewTheta - OldTheta; // Difference from last time (or from start) if (DeltaTheta >= 180) { // Negative rollover? NewTheta -= 360; // Correct for use this time CycleTheta -= 360; // For use next time } if (DeltaTheta < -180) { // Positive rollover? NewTheta += 360; // Correct for use this time CycleTheta += 360; // For use next time } KinPosMotor1 = Radius * Motor1ScaleFactor + Motor1Offset; KinPosMotor2 = NewTheta * Motor2ScaleFactor + Motor2Offset; // Convert to motor units OldTheta = NewTheta; // For use next time InvKinErr = 0; } else { InvKinErr = 1; abort1; }

Here's how I would handle it: In the forward kinematics, establish both Theta within one cycle and which cycle you are in: FullTheta = Motor2KinPos / MyMotor2ScaleFactor; // Could be outside 0 - 360 range OldTheta = FullTheta % 360; // Location within 0 - 360 range, will be used by inv kin rollover CycleTheta = FullTheta - OldTheta; // Multiple of 360, indicates cycle count ... In the inverse kinematics, look for rollover by checking for angle change greater than +/-180 NewTheta = atan2d(AxisYKinPos, AxisXKinPos) + CycleTheta; // Tentative, wrong if there has been rollover DeltaTheta = NewTheta - OldTheta; // Difference from last time (or from start) if (DeltaTheta >= 180) { // Negative rollover? NewTheta -= 360; // Correct for use this time CycleTheta -= 360; // For use next time } if (DeltaTheta < -180) { // Positive rollover? NewTheta += 360; // Correct for use this time CycleTheta += 360; // For use next time } Motor2KinPos = NewTheta * MyMotor2ScaleFactor; // Use corrected result OldTheta = NewTheta; // For use next time ... I haven't had the time to test this, but I think it should work -- it shows the principle at any rate.

The fix will be in the next release, which is expected in the 3rd quarter of this year.

No, the resolver at these levels is not compatible with the ACC-58E. The excitation output from the ACC-58E is a maximum of 7Volts (peak-to-peak), and the feedback values should be 1-2Volts p/p. Also, it was designed to use resolver frequencies over 1000 Hz.

When the software interpolation is done in the conversion table from an ACC-24E3, the interpolation factor is 16384 per line. We do not have automatic routines for determining the signal errors, but it would be quite simple to monitor the channel AdcEnc[0] and [1] registers for max and min values in a PLC program, then computing the sine and cosine offsets as the negative of the mean of max and min for([max+min]/2) each phase. The magnitude mismatch could be computed as the ratio of the span (max-min) of the two phases. Phase error would be a little trickier -- some just look at the Lissajous pattern on a scope.

A clarification is needed in the manual. Data structure elements that are simply registers (or part of registers) can have values assigned synchronously. This is the vast majority of elements. However, a few of the elements are "function" elements -- when assigning a value to one of these in the script environment, a whole host of actions are performed. Gather.Enable is one of these. "Function" elements cannot be written to synchronously. You can tell if an element is a function element by querying its address. If the returned value is 0, it is a function element, so its value cannot be set in a synchronous assignment. So if you query: Gather.Enable.a Power PMAC will return a value of 0. My apologies for the confusion.

Because this is purely a hardware function in the IC, I worked interactively directly with the IC registers to make sure that nothing else got in my way. Sys.WpKey=$AAAAAAAA // To enable writing to IC setup registers Gate3[0].Chan[0].EncCtrl=8 // Use internal PFM into encoder counter Gate3[0].Chan[0].TimerMode=0 // 1/T sub-count extension (so can read TimerA as position) Gate3[0].Chan[0].PackOutMode=0 // So PFM command comes from unpacked Phase D register Gate3[0].Chan[0].EquOut=1 // Output uses this channel's state only Gate3[0].EncClockDiv=5 // 3.125 MHz (default) Gate3[0].PfmClockDiv=5 // 3.125 MHz (default) In the IDE watch window I put: Gate3[0].Chan[0].TimerA // Present position with 12 bits of fractional count Gate3[0].Chan[0].CompA // Specified compare edge position A (w/ 12 bits of fraction) Gate3[0].Chan[0].CompB // Specified compare edge position B (w/ 12 bits of fraction) Gate3[0].Chan[0].Equ // Channel internal compare state Gate3[0].Chan[0].EquOut // Channel compare output I set values of CompA and CompB to one side of the value of TimerA. For now, at least, I kept CompAdd at 0. I made sure no active motor was using this IC channel - in my case by setting Motor[1].ServoCtrl to 0. Next I wrote positive and negative values to Gate3[0].Chan[0].Pfm. I watched the TimerA value as it passed CompA and CompB, and saw that the Equ value toggled as it passed each in both directions. This worked with EncCtrl=12 as well as 8, so TimerA moved in the opposite direction from PFM. I changed EncCtrl to 3 and 7 and moved the motor/encoder by hand. All this worked. With EncCtrl set to 8, I used the standard settings for a "stepper motor" setup, and was able to jog the motor back and forth past CompA and CompB. I suggest working manually with the IC registers directly first.

Make sure that your acceleration time is not zero. I think you are actually faulting out of the program due to "zero time" moves. Use ta or ts commands to specify your acceleration times -- the acceleration time is the minimum time for a move, even a zero distance move. Zero acceleration time is also pretty lousy dynamically, as it causes step changes in commanded velocity, which can be rather hard on the equipment.

I have not been able to get the toggling to fail in the negative direction (or the positive) with either a real encoder or using the internal pulse train (with the decode in either direction). We have had no other reports of this. I have occasionally been able to duplicate the issue of having the EQU bit toggle when CompA and CompB are the same value as the counter passes this value. This is something we will have to live with for at least the time being, since it would take a year to get a new revision of the IC into the field. You could continue to set CompA and CompB to values outside of the range of travel; but it might be easier to do the following: Gate3[0].Chan[0].EquOutPol = Gate3[0].Chan[0].Equ // To maintain the current output value Gate3[0].Chan[0].EquOutMask = 0 // Detach output from internal EQU states

No, the actual position register at $8B (etc) does not include the compensation. In Turbo PMAC, compensation corrections are added to the desired position. To make this work, there are a couple of things you need to consider. The first is scaling. You will only be able to combine the correction with the encoder if they are scaled the same, so Ixx08 must be set to 1 for the motor, so the compensation correction register at $90 (etc) is in the same units of 1/32 of a motor count that the result of the processed encoder value is. If Ixx08 is not already set to 1, you will need to change servo gains when you change Ixx08. You will be combining the correction with the result of the converted encoder entry (not the motor actual position) and using the combined value for the velocity loop. Since the compensation correction is added to desired position, you must subtract the value from an actual position value, not add it.

Sending program command lines to the rotary buffer can be done simply by sending text through gpascii. You can get a feel for doing this simply by typing lines into the terminal window in the IDE or through a terminal emulator like cmd.exe.

Your example worked just fine for me. Programs do use the present values of variables, not just the values when the program starts. Remember that the program will be working a couple of moves ahead of execution so moves can be blended together properly, so changes can appear to be delayed. Also, if you are not sure about whether you are in absolute or incremental mode, it is easy to get confused about what it is doing.

On TB1, which accepts the external encoder signals, you are correct that the pin 26 GND signal must be tied to the GND signal of the servo drive(s). But you are not correct that you can leave the pin 25 +5V signal unconnected. This side of the accessory is powered through this pin (which is why the manual says "MUST USE"). So you must have a 5V supply somewhere (it could be in the drives) referenced to this same GND level. On TB2, you can connect both the +5V and GND pins to comparable pins on the Clipper.

If I understand you correctly, you are sending an analog torque command to the Justek amplifier, which is executing the brushless motor commutation and current loops. In this mode, the PMAC does not have access to any of the information about the currents in the phases of the motor -- neither the actual magnitude nor the waveshape. All of those matters are completely within the amplifier. The analog output from the PMAC is just a current magnitude command. There is no current feedback to the PMAC in this mode, even just for monitoring.

The manual can be found under Resources/Manuals/Accessories on the website. This is the direct link: http://www.deltatau.com/manuals/pdfs/ACC-8D%20OPTION%206.pdf?id=635013658588146511

I have been looking into this. I have not been able to duplicate the issue of direction sensitivity. As far as edge suppression when CompA=CompB, on my system it is suppressed virtually all the time, but I do occasionally see an edge. We are continuing to investigate.

We are looking into this. However, it is not a standard operation to change the amp fault polarity in this manner.

The encoder interface circuitry on the ACC-1P is identical to that on the Clipper. Any differences in failure rates are much more likely to be due to different paths in for electrical disturbances. These types of problems are very difficult to diagnose from a distance. But obviously you need to examine very carefully your wiring, shielding, and grounding on the machine. You may want to examine adding protective circuitry, whether diodes or isolation. Our ACC-8D Opt 6 board provides optical isolation for 4 3-channel encoders, and is intended for noisy applications like this. Best regards, Curt

If you look at the block diagram of the servo algorithm in the User's Manual, you will see that what the deadband compensation algorithm does is to modify the size of the following error inside the band. If you have it set up to create true deadband (Ixx64 = -16), then if the magnitude of the following error FE is less than Ixx65, the modified following error FE' out of the block is 0. This modifies the effective gain of the position loop in the servo algorithm, but it does not modify Ixx30. Looking again at the block diagram, you can see that it does not affect the inner velocity loop action.