curtwilson

I guess I wasn't clear enough. I'll put it in mathematical terms as well: Sum[n] = Sum[n-1] + (I^2 - Icont^2) * DeltaT If Sum[n] < 0 then Sum[n] = 0 If Sum[n] > Limit then Fault You can observe the running sum in the Watch window to see how it works. Define: M158->D:$DA,0,24 ; Motor 1 integrated current This is in the same units as the I158 limit.

The integrated sum never goes below zero. That's the only complication you missed.

Your forward and inverse kinematic routines MUST be mathematical inverses of each other over the entire workspace. That is, at any location in your workspace, if the X and Y axis position values Q7 and Q8 produce particular motor position values P1 and P2 in your inverse kinematic routine, the forward kinematic routine, given those same P1 and P2 motor position values, must produce the same axis position values in Q7 and Q8. When you start a motion program, PMAC uses the Q-variable outputs from the forward kinematic routine as its starting axis positions to compute the move. If these are not correct, there will be a very quick jump from the real present position to the position it thinks it is starting from.

You are probably going to have to use data gathering each time you do this change in order to catch the occasional problem. To answer your question 4: Yes, it does use the present state as the initial state for the first section of the new move.

When you change encoders, are they scaled in the conversion table so that their effective scaling is the same when use by the motor? Otherwise the acceleration values change with the square of the scaling change, and jerk values with the cube. Have you tried using the incremental encoder for the inner velocity loop and the absolute encoder for the outer acceleration loop? That is common in these telescope applications. Have you tried using the load absolute encoder as feedback for a virtual motor whose servo output is cascaded to modify (offset) the position of a real motor that uses the motor incremental encoder as feedback? A couple of telescope guys have told me this gives the best results. If the motor is at a closed-loop stop when the jog command is issued, starting velocity, acceleration, and jerk are all 0.0.

Your first understanding is basically correct; your second is not. If the motor is executing a trajectory move (jog or home), the initial states for the new command come from the Motor[x].Desired sub-structure coefficients (and time within the move section). This all commanded trajectory information, and is unaffected by actual position issues like encoder noise. You can change Motor[x].HomePos before commanding a jog move without messing up the derivatives. This is what PMAC does itself when the trigger is found in a homing search move. It writes to HomePos, then commands a move relative to the trigger position. Pending trajectory move sections are stored in the Motor[x].New sub-structures, ready to be copied into the Desired sub-structure as the move execution progresses from one section to another.

The hardware auto-increment feature in the ASIC is intended to handle update times that are short enough to be difficult or impossible to handle in software. That obviously is not the case here. It looks like you will need a two-step software process. In the first step, you flag that you want to write new values to CompA and CompB. In this step, you monitor motor position to see when you come within 2^24 (16M counts) of the positions you want for CompA and CompB. Once you see you have passed this threshold, you can execute the second step of writing the desired 24-bit values to CompA and CompB. You should have the auto-increment register CompAdd set to 0.

The correction of the compensation table is always a function of the source motor's "raw" position, how ever that position is referenced, whether to the immediate power-up position reference of 0, the subsequent trigger position of a homing-search move, or the subsequent sensor read of an absolute position. If the reference is changed, as in the last two of those cases, the raw position is changed, and the correction will be changed as well. You can monitor raw position Motor[x].Pos, table correction Motor[x].CompPos, and corrected position Motor[x].ActPos.

Look at register Y:$000x8E/0E (Y:$00010E for Motor 2), the "Motor servo extension timer"

Our own servo algorithms store the DesVel value for the next cycle in the "F" polynomial filter's uf1 element of the Servo substructure. Then you can just subtract this from the new DesVel term to get your desired acceleration value. MyDesAccel = Mptr->DesVel - Mptr->Servo.uf1; ... Mptr->Servo.uf1 - Mptr->DesVel; // For next cycle We don't save a desired acceleration term because we must save the desired velocity term from cycle to cycle for the F filter and it is one simple operation to derive it. The trajectory acceleration term you tried to use is the value of acceleration at the start of each segment (a0) when the trajectory is running at 100% and there is no master position change and no desired position compensation.

The net desired position in Motor[x].DesPos is the sum of: * Trajectory command position in Motor[x].Desired.Pos * Following position in Motor[x].ActiveMasterPos (possibly slew-rate limited from Motor[x].MasterPos) * Compensation command position in Motor[x].CompDesPos The net actual position in Motor[x].ActPos is the sum of: * Raw measured position in Motor[x].Pos * Compensation position in Motor[x].CompPos * Backlash position in Motor[x].BlCompSize (depending on direction) The following error in Motor[x].PosError is the difference between NET desired and actual positions.

PMAC performs its lookahead limiting by selectively lengthening the times of motion segments produced by the coarse interpolation function in "segmentation mode". This is only active for linear, circle, and PVT mode moves commanded from PMAC motion programs. If you are computing your own trajectories in a custom servo algorithm, you have bypassed the key stages necessary to use lookahead.

To create a foreground failure, the easiest way is to set Sys.RtIntPeriod to a very large value (say, 1000). You should quickly see Sys.WDTFault set to 2 (RtFault). To create a background failure, I like to create a very long program as Brad suggests. I would create a program line with multiple I/O accesses (which take time) and some math, then copy this many times in the program. For example: M1=sin(M2)+exp(M3)-cosh(M4) where M1, M2, M3, and M4 point to I/O, not memory registers. You can combine this with the following trick: open plc 5 Ldata.GoBack=10000; // Permit looping 10K times before exiting while (P1==0) { M1=sin(M2)+exp(M3)-cosh(M4); ... } close You could also set Sys.WDTReset to 100 to make this as sensitive as possible. You should see Sys.WDTFault set to 1 (BgFault).

At that point in its calculations, PMAC is working with position in units of 1/16 of a count. We ask you to do the multiplication once, in entering the value, so that PMAC does not have to do the multiplication thousands of times every second. Also, many people find that a deadband of 1/2 count is useful to stop the dithering that can occur when stopping at a commanded fractional count value.

The line receivers are rated only to 10 MHz signal frequency. At 10 MHz and above, if you were to look at the output signals from the receivers into the ASIC, you would consider them "analog" signals, looking like they had an RC time constant. Most parts would operate successfully at quite a bit above 10 MHz -- I have run successfully several times at 12.5 MHz, but then you have to worry about part-to-part variation and possibly temperature variation. That said, you can try higher frequencies without worrying about damaging things -- it would just lose counts if you go past its real capabilities. Look for the ASIC's "count error" status flag.

That will work until the storage pointer wraps around to the beginning of the rotary buffer. Then your expression will report a negative number. To make it more robust, you could do the following: BufferUsed = (Coord[x].RotStore - Coord[x].RotExec) modulo (Coord[x].RotEnd - Coord[x].RotStart) Using the modulo operation with the size of the buffer would turn a -4000 value into a +6000 value for a 10000-byte buffer.

A clarification on the response to the "rotfree" query: Power PMAC responds with the size of the largest continuous block of open memory in the buffer, as there can be a block before the executing point and a block after. The reason that this value is reported is that a single program line cannot wrap around from the end of the buffer to the beginning. So the response to "rotfree" is the size of the longest program line that can be accepted. (If the space at the end of the rotary buffer is less than the length of the program line, the entire program line will be placed at the beginning of the buffer, presuming there is room there.) So in your test, the block of 9977 bytes open toward the end of the buffer is a far larger space than the ~40 bytes per line opened up by the executed program lines.

To set bit 17 alone, you can use: I124 = I124 | $20000 ; Logical OR with bit 17 To clear bit 17 alone, you can use: I124 = I124 & $FDFFFF ; Logical and with all bits except 17 To make the code more readable, you could use the following substitutions: #define Bit17Val $20000 #define Bit17Comp $FDFFFF

You will have detailed issues that need direct tech support to solve, but here are some general principles: You cannot break into an executing LINEAR move with another move (except to abort). If the next move is available in the buffer before the end of the front-end acceleration (blending) of this move, a blend without stopping to the next move will be calculated to replace the final deceleration of the executing move. You CAN break into an executing RAPID move with another RAPID move. However, this new move cannot come from a motion program, as the sequencing rules for motion program execution do not permit calculation of another move until full execution of this RAPID move is finished. So a new move sent to the rotary buffer will not break into the executing move, and a "cpx" command, which is a separate one-line motion program, cannot be used until the executing motion program is finished. The new RAPID move that breaks into the executing move must come from a PLC program, either one that is already loaded into the PMAC, or using the "cx" command for a one-line one-shot PLC program. So you could do something like: cx Ldata.Coord=1 Motor[3].MaxSpeed=200 rapid X25.3

You have basically got it. When execution of a programmed move in the queue finishes and advances into the next move, an internal flag is set for the program calculation to resume and compute the next move to put into the queue. If variables are used to compute this next move, it uses the values of these variables at this moment, having no way of knowing what former values of these variables were. For linear moves, which can have multiple sections, the internal flag is set at the beginning of the blend from move N to move N+1, with move N+1 already in the queue. The queue must be longer than you think it is (so this point is not just at the final "blend" deceleration to stop) so that proper blending from one move to another within the set constraints can always be achieved.

Brian: I should have been clearer. My preference is to turn off the integrator during the feedforward-tuning moves themselves so you can see the pattern of the tracking errors clearly without the integrator trying to drive them to zero. This allows you to optimize the feedforward gains. BUT, and I forgot to mention this, once you have gotten the feedforward gains well tuned, my preference is to turn the integrator back on during moves to improve the tracking a little more. I view the integrator as the "last line of defense", and think as much as possible should be done before it is used. It's an intereresting report on the feedforward. In a single loop, feedforward does not affect stability, but in the cascaded format it is actually part of the overall feedback loop. Exactly why this happens in your configuration would depend on the dynamics of the system.

The key thing to understand about PMAC motion program execution is that it is automatically sequenced by the move. When it actually calculates equations of commanded motion from a move command in the program, putting these equations in the execution queue, it suspends calculations. Calculations do not resume until execution of moves from the queue depletes the queue enough that a flag is set for the motion program to fill the queue again. So if you have a motion program calculating a series of 50-msec moves, you will get a burst of calculations from the program every 50 msec, even if these calculations take less than a millisecond (which is typical). This is true whether the moves are in an in-line sequence or there is a single move command inside a loop.

The feedforward terms for a motor act on the net commanded positions, and so react to the sum of the calculated trajectory and master position from whatever source. So your cascaded command from your force loop will affect the feedforward of the inner position loop. The nice thing about having separate feedback and feedforward terms is that they effectively split the tracking and disturbance rejection functions. (Controls texts call this 2-degree-of-freedom control.) So the feedback terms are responsible for disturbance rejection, and interactive tuning for these typically uses the "step response" square-wave tuning. The feedforward terms are responsible for trajectory tracking. (If you got the feedforward exactly right and there were no disturbances, you wouldn't need feedback!) We find that our "parabolic move" tuning is much better than ramp tuning, because the parabolic move has continuously varying profiles in both velocity and acceleration that allow you to easily see what is causing your tracking errors. Do the step feedback tuning first, and make sure the integrator is off (Ixx34=1) during moves when you are doing the parabolic move tuning for feedforward.

The Brick AC, like any servo drive, is capable of full 4-quadrant operation. For the power transistors themselves, the continuous and intermittent current limits in generation should be considered the same as for motoring. The energy from generation mode goes into charging up the bus capacitors, and this will increase the DC bus voltage. When the voltage exceeds a threshold, the "shunt" circuitry is turned on. Current will start flowing through a built-in shunt resistor, dissipating this energy. The built-in shunt resistor does not have the capacity for heavy continuous use -- it is intended for occasional use, as for a rapid deceleration. If there is a possibility of continuous use, you will probably need to purchase a larger external shunt resistor. Contact tech support for assistance on this configuration. The Brick AC does NOT have the capability to regenerate this power back to the AC line. That is expensive to implement, and few users would want it.

As KEJR points out, the programmed rapid mode is the most similar to jog moves. It does use JogTa and JogTs for accel/decel, and it can even use JogSpeed if Motor[x].RapidSpeedSel is set to 0. If you still want to use the programmed linear mode, realize that this mode uses common accel/decel times (ta, td, ts) for all axes because that is necessary for a straight-line path. However, if you set the times small, then the Motor[x].InvAmax, InvDmax, and InvJmax limits kick in and can stretch out the times (for all axes of a multi-axis move). These limits are only applied at move calculation time if Coord[x].SegMoveTime = 0 to disable segmentation. Otherwise, you would have to set up buffered lookahead to get accel limits, which I think is way beyond what you want to do. The speed of a motor in a linear mode move will not be greater than Motor[x].MaxSpeed. PMAC will stretch out the (common) time for a move if this limit on any motor would be exceeded.