curtwilson

Yes. The method I suggested is for Power PMAC. It's easier in the Power PMAC because you can use the "switch" statement. For example: open inverse switch (AxisMode) { case 1: // Motor 1 and 2 as XY KinPosMotor1 = KinPosAxisX KinPosMotor2 = KinPosAxisY KinPosMotor3 = KinPosAxisU KinPosMotor4 = KinPosAxisV break; case 2: // Motor 1 and 4 as XY KinPosMotor1 = KinPosAxisX KinPosMotor2 = KinPosAxisV KinPosMotor3 = KinPosAxisU KinPosMotor4 = KinPosAxisY break; (etc.) open inverse switch (AxisMode) { case 1: // Motor 1 and 2 as XY KinPosMotorX = KinPosAxis1 KinPosMotorY = KinPosAxis2 KinPosMotorU = KinPosAxis3 KinPosMotorV = KinPosAxis4 break; case 2: // Motor 1 and 4 as XY KinPosMotorX = KinPosAxis1 KinPosMotorV = KinPosAxis2 KinPosMotorU = KinPosAxis3 KinPosMotorY = KinPosAxis4 break; (etc.)

When you have an absolute encoder, the only purpose for the stepper-motor phasing search is to establish the difference between the sensor zero position and the commutation cycle zero position. This difference is put in Motor[x].AbsPhasePosOffset, and then in subsequent startups, PMAC just reads the absolute encoder position and adds this offset -- no need for a search. So you only need to do this successfully once. I would definitely do this on an unloaded motor so things like friction and gravity loads can't screw it up. The purpose of the "stepper method" is to try to drive the motor to the zero position in the commutation cycle by forcing current in a phase as you do for a stepper motor. You can do this manually with a command like: #x out0 Motor[x].IbBias=3000 (Remember to return IbBias to (at least near) 0 when you are done.) What is your value for Motor[x].PhaseFindingDac? Does increasing it help? The built-in search function first forces it to 90 degrees so it cannot possibly be stuck at 180 degrees. It can also confirm that reasonable motion occurred between the two steps before it declares success and allows the loop to be closed. I did just confirm on my test system that the two steps are 90 degrees apart, not 60. I got about 500 commutation units between steps each time I tried this search. You claim a motor with 7 commutation cycles per revolution. How many encoder LSBs do you have per revolution and what are your settings for AbsPhasePosSf and PhasePosSf?

I would always use XY circle commands. I would change which motors are assigned to the X, Y, U, and V axes. These changes are most easily done with logic in kinematic subroutines. To support all of the possibilities, you would need 4 modes in each kinematic subroutine. This could be done with a switch statement. It is very important that your forward and inverse kinematic subroutines match properly in all 4 modes. Whenever you change modes, you must do a PMATCH function before you command your next move. In Power PMAC, you do not need to do CMD"PMATCH" -- you can just do PMATCH in your program.

You are correct that the current loop is not affected by rescaling of the position loop.

I think you rescaled twice when you only needed to do so once. Most people leave the output of the encoder table in counts. I would return the EncTable[n].ScaleFactor to its default value. For digital quadrature, this value is 1/256, which makes the result of the table entry in units of quadrature counts, with 8 bits of estimated sub-count fraction. (If you just converted this value from 1/256 to 1/20000, you did NOT rescale from counts to mm, because you did not change the scaling by a factor of 20,000.) I would start with a Motor[x].PosSf and Pos2Sf = 1.0 so that the motor units are also in counts. With the motor disabled, move it by hand and see if you get the expected numerical change with distance. Then change these scale factors to 1/20000 and repeat the hand movement to see if the reported units look like mm. Now you can try to tune the system.

Have you made #define assignments for B1 and B2 as variables?

When you are trying to hold position at zero desired velocity, I don't think you will be getting a high-frequency signal that the ASIC sampling cannot handle. If the sampling limitations cause an error, the PowerBrick.Chan[j].CountError bit will be set. This means that there is an unrecoverable position error from the decoding (from two signal edges -- real or noise -- in the same sample cycle). In general, you should not expect a 10x increase in position resolution to result in a 10x improvement in position stability. However, with good feedback and tuning, it should be somewhat better, and it should not be worse. (I think your math is off on the x10K interpolation. It looks like 0.67urad ptp.) When you increase your resolution by a factor of 10 -- from x1K to x10K -- you should first reduce your Kp and Kvfb by a factor of 10 to see if you get equivalent physical performance. Then, in theory, you should be able to raise these gains somewhat to get tighter control. If you do not get the same physical performance with 10x increase in resolution and 10x reduction in gains, I would be concerned about the quality of your feedback signal. I emphasize again that the digital quadrature signal output from encoders like these comes from a feedback loop in the encoder trying to track the value of the sine and cosine signals. I worry about its ability to represent the true position as it dithers back and forth about a position, and it may be that the higher interpolation setting is worse.

We haven't seen this before and can't duplicate it so far. However, I'm concerned that you issue your "start" command immediately after the "abort" command. The abort command triggers a process that does take finite time. Try putting a small delay in between these two commands in your PLC program.

One thing to be aware of is that the trigger capture is level triggered in the Gate1 IC. Reading the HomeCapt register automatically re-arms the triggering circuit, and if the trigger input is still at the specified state, it will immediately latch the present position again into the HomeCapt register, and a subsequent read of HomeCapt can report a different position that what was captured at the front edge of the trigger. I'm not sure if your logic protects you against this. Remember that another task, such as the IDE watch window monitoring the value of HomeCapt, can re-arm the trigger before your code reads HomeCapt. Another possible issue is how the encoder generates its signal. Encoders like this typically synthesize a high frequency digital quadrature signal from a lower frequency analog sinusoidal signal through an internal tracking feedback loop. In some encoders, this loop produces excellent (stable, accurate) results, but in others, undesirable non-physical effects come into the signal.

With the phase clock virtually always running at a higher frequency than the servo clock (default by 4x), you can use the phase gathering feature to log the IC channel's PhaseCapt register at this higher frequency to check for how it changes at shorter intervals than the servo update. I'm very confident that your mechanical system does not have the physical bandwidth to behave in the manner you are concerned about.

Now that I've had a little time to get back to this, I want to focus on some basics: The purpose of triggered time base is to provide a very predictable and repeatable motion response to a hardware input signal -- with less uncertainty than a full software servo cycle. It does this by latching the count value of the clock in hardware the instant the trigger comes in. This count value is used as "t0" for subsequent motion interpolation calculations. But as a "sampled data" (i.e. digital) system, PMAC cannot respond instantly to this event. You will have a finite time delay -- it looks like a full servo cycle -- in response. Your analysis seems to assume this should be zero delay. But again, the purpose of this feature is to get very repeatable response, and it looks to be doing that. You mention the difference in response between using a flag input and the encoder index © input for your trigger. Remember that the flag input goes through an opto-isolator which has a delay in the tens of microseconds. Just another (very repeatable) delay you need to account for if you use this.

I think the first limitation you will hit is the frequency limit of the differential line receivers. They are rated to 10 MHz signal cycle input (they usually can go a little higher than this, but not robustly). With a "times-4" decode, this is a limit of 40 MHz count rate. Also, the ASIC must be set up to sample the resulting signals at a high enough frequency to detect all of the edges that pass through the receivers. At most, one edge per sample cycle is permitted. At the default sampling frequency of 3.125 MHz, you are limited to this count frequency (with perfect signals!), so about 750 kHz signal frequency. You should set PowerBrick.EncClockDiv to 0 so the sampling frequency is 100 MHz. With the 40 MHz count rate limitation of the receivers, your speed limitation is: 4x10^7 [cts/sec] / 2.36x10^8 [cts/rev] = 0.17 [rev/sec] = 10 [rev/min] You will not be able to move significantly faster than this, and it looks to be easy for an open-loop test to cause higher speeds than this. PMAC software can handle the rollover of the encoder counter as long as less than half the range of the counter register is changed in a single sample cycle. With 24 bits of full counts in the 32 bit register, the range is 16M counts, so you are limited to 8M counts in a single sample cycle. But with sample rates above a kHz, this is many billions of counts per second, which the hardware cannot support. Most people who want resolution this high use a serial numeric data format from the encoder (even if incremental) to get around the hardware frequency limitations. Do you have this interface format available?

On the jitter issue: Remember that your clock signals and PMAC's servo/phase clock inputs are fundamentally asynchronous. PMAC's "external time base" feature calculates the number of clock pulses received each servo cycle (with timer-based sub-count interpolation) and increments its trajectory time value by an amount proportional to this delta -- as opposed to its own internal time sense. This provides a software synchronization between the two independent clock systems. Motor position values -- DesPos and ActPos -- are updated once per PMAC servo clock cycle, and to repeat, this clock is asynchronous to your clocks. So I think it would be very easy to get an effective beat frequency in your test sampling this way. This does NOT mean that there is an actual beat frequency like this in the real motion.

Two things to consider: First, it looks like a non-zero acceleration time could explain the offsets you are seeing. Try programming linear moves with TA0 TS0 TD0 and no segmentation (Coord[x].SegMoveTime=0). Second, it may be important to understand that the trigger occurs partway through a servo cycle, so the first cycle after the trigger is a "partial" one. For example, if the trigger occurs 1/4 of the way through the cycle, the first cycle's "time" would be 3/4 of a full cycle, and so the position increment would only be 3/4 as much for this first cycle. (This is key for full synchronization.) I am not sure if your calculations take this into account.

Please provide us with manual name, date, and page where you found the error so we can correct it. In some places it is described correctly.

Your syntax is slightly off. It should be: MyTotalDist = sum(&IncrementDist(0), 512, 1)

You can set the upper limit to +32,768, and the lower limit to -32,768.

Wire the 1kHz signal into the C (index) for the same encoder as you have wired the 128kHz into the A (pulse) input. You will set Gaten.Chan[j].CaptCtrl to 1 to trigger on the rising edge of the index input. To the PMAC this now looks like a 128 pulse-per-rev encoder with an index pulse.

In the manual, we show an example of correcting for a 1 arcmin squareness error at 10,000 cts/unit with: #1->10000X-2.91Y #2->10000Y It would be easy to do the same functionality in kinematic subroutines. (You do have to mathematically invert this for the forward kinematics.) You can do matrix transformations "on top" of this just as for simpler configurations.

I can't duplicate this problem. My attempt works as it should. Here's what I used: CompTable[0].Source[0]=1 CompTable[0].SourceCtrl=0 CompTable[0].Nx[0]=1 CompTable[0].Nx[1]=0 CompTable[0].Nx[2]=0 CompTable[0].X0[0]=0 CompTable[0].Dx[0]=10000 CompTable[0].Data[0]=0 CompTable[0].Data[1]=100 CompTable[0].Ctrl=4 CompTable[0].Target[0]=Motor[1].CompDesPos.a CompTable[0].Sf[0]=1 CompTable[0].OutCtrl=0 As I jog slowly across the range of the table (0 - 10000), the correction increases in direct proportion to the commanded position and saturates at 100 as I go past the end of the defined range. It also saturates at 0 as I pass the negative end. Why aren't you using the axis definitions to correct for squareness?

Both sections of the manual are correct FOR THE PARTICULAR HARDWARE INTERFACE THEY DESCRIBE. If you have the resolver interface board installed on the ACC-24E3, the ALTSIN and ALTCOS input values will be found in AdcEnc[2] and [3]. If you have the auto-correcting interpolator board for sinusoidal encoders installed on the ACC-24E3, you can get the raw SIN and COS values (unfiltered and uncorrected) in AdcEnc[2] and [3].

Coord[x].Ldata.Status has that information.

For motion programs, saved setup element Coord[x].GoBack specifies how many times you can loop back in a single RTI. For PLC programs, local element Ldata.GoBack (externally accessed as Plc.Ldata.GoBack) specifies this for a single (foreground or background) scan of a PLC. You must set this inside the PLC. In this technique, I don't think multiple loops will be of much help.

I think your best approach is a hybrid one, using a twist. In your motion program, first set both Coord[x].DesTimeBase (target time base value) and Coord[x].TimeBase (immediate time base value) to 0. (We call this "freezing the time base", basically like issuing a "%0" command.) Next, set some kind of internal flag so a PLC program can start looking for the trigger. Finally, issue the move command in the program. PMAC will calculate all the equations of motion for the move and put them in the execution queue, and motion program calculations will automatically be suspended. At this point, the move execution has technically started, but it is "stuck" at T=0. Now your real-time PLC program, executing every RTI (Sys.RtIntPeriod=0), looks for the trigger, and when it sees the trigger go true, sets both Coord[x].DesTimeBase and Coord[x].TimeBase to Sys.ServoPeriod. In the interpolation calculations of the very next servo cycle, "time" will increment by Sys.ServoPeriod, starting true execution of the move. This should be a servo cycle or two quicker response than other methods you might try.

Thank you for reporting this. We have duplicated it here, and it will be fixed in the next release.