curtwilson

It should read: X:$000xB8/38 Motor commanded quadrature current Y:$000xB8/38 Motor commanded direct current X:$000xB9/39 Motor actual quadrature current Y:$000xB9/39 Motor actual direct current My apologies for the error.

The deadband function modifies action from the proportional and integral terms when the following error is within the band. With a gain factor of -16, they should provide no action. However, the deadband function does not inhibit the action of the Ixx31 derivative gain term, which responds to actual velocity. It looks to me that your Ixx31 value is too high for this motor, causing it to overcorrect continually and dither across the set point. I don't see why Ixx68 would be changing. Make sure you don't have anything writing to it on a continuous basis.

The correct descriptions of the registers is as follows: X:$000xB8/38 Motor commanded quadrature current Y:$000xB8/38 Motor commanded direct current X:$000xB9/39 Motor actual quadrature current Y:$000xB9/39 Motor [actual] direct current (Corrected 04-24-2013) The real data is in the most significant portion of the 24-bit registers. If you want to treat the data as a 16-bit value (the same scaling as the key I-variables), you will simply divide the (signed) 24-bit value by 256 (2^8). Scale factors like 1/96/32 are appropriate for position registers, but not these current registers.

Ah, the Acc-24E3 manual is incorrect in this regard. (The main Power PMAC manuals are correct.) My apologies. The choice of disabling the serial encoder interface and using the pins for quadrature interface is done on a per-channel basis by setting Gate3.Chan[j].SerialEncEna to 0.

A few points: The main encoder interface on a hardware channel has the ability to accept and count a single pulse train instead of quadrature. This can be done with Gate3.Chan[j].EncCtrl, setting a value for either pulse-and-direction or pulse-up/pulse-down input instead of the default quadrature setting. The serial encoder input for the channel can be used for quadrature if SerialEncEna is 0 (note that you did not do this), but not for single pulse counting. You would see the count value toggling back and forth a single count (in SerialEncDataA, not ServoCapt) if you fed it a single toggling pulse. As to signal levels: the sine encoder inputs on these cards use the same differential line driver input ICs as the serial encoder inputs, and as the quadrature encoder inputs on other cards. The sine encoder input lines do not have pullup resistors, and the lines also drive A/D converters through op-amp networks. Even at the 1Vpp analog levels, the receivers create digital quadrature signals into the ASIC counter. If you feed it 5V digital pulses, these will pass through the receivers properly into the ASIC as well. The A/D converter circuits will be saturated, but not damaged.

The analog (sinusoidal) encoder card can take 5V digital signals and process them properly.

I have duplicated the problem when the coordinate system is not in segmentation mode (i.e. Coord[x].SegMoveTime = 0). I do not get the problem when the coordinate system is in segmentation mode (i.e. Coord[x].SegMoveTime > 0). Try it with segmentation active, which you usually want for these path type applications, while we figure out what is going on.

The only way I can duplicate this problem is by having my TA acceleration time and TS S-curve time both set to 0 (and no segmentation time as well). When this is done, the move time evaluates to exactly 0. This would also command infinite acceleration in your trajectories, so should be avoided.

The most likely remaining possibility is that something else is overwriting the DAC register every servo cycle. What happens if you set Motor[1].pDac to another register? Try: Motor[1].pDac = Gate1[4].Chan[0].Dac[1].a Motor[1].pDac = Gate1[4].Chan[3].Dac[1].a Motor[1].pDac = Sys.Idata[256].a Do you see your values in these registers? Look at the other motor numbers. Are any of them activated (Motor[x].ServoCtrl > 0)? If so, are any of them writing to the same register?

The purpose of the Csolve "lockout" for axis definition statments is to prevent a program from running in cases where Power PMAC cannot properly compute the starting positions for the axes through a mathematical inversion of the axis definition statements. If the only axis definition statement for the coordinate system is: #1->X+Y or if you have #1->X+Y #2->X+Y PMAC cannot calculate the starting axis positions from the motor positions when the program begins, so it will refuse to execute the program. When you have your own kinematic routines, PMAC fundamentally has to assume that you have done the calculations correctly.

The "input deadband" set up by the BreakPosErr and Kbreak terms modifies the following error that the servo terms use. If you have Kbreak = 0, then when the magnitude of the following error is less than BreakPosErr, the proportional term Kp and the integral term Ki will operate on an effective input of 0. This means that the output of the integrator will not change as long as you are within the deadband. The integrator output does not have to be zero in this case, and probably will not be, but its value will be constant. Note that the velocity feedback (derivative) gain is still active within the input deadband, counteracting non-zero actual velocity. When using the output deadband, it is important to realize that the DesVelZero bit refers to trajectory velocities into the servo loop position command node. It does not refer to any states internal to the servo loop. So when the trajectory generator is commanding a stop, DesVelZero will be true and the output deadband function will be active even if the integral term is acting to try to reduce the following error.

I note that your "PhaseFound" status bit is true, which implies that the setup element Motor[x].PhaseCtrl is greater than zero, enabling phase algorithms. If this is true for the motor, the output of the servo algorithm is not written directly to the pDac register, but used as an input to the phase commutation algorithm. Make sure PhaseCtrl is set to 0.

You can do this in a equivalent fashion in Power PMAC. Pick a 32-bit register treated as an integer, probably a Sys.Idata element in the user buffer. Process this through a Type=1 single-register-read entry in the encoder conversion table, and the result of that entry is ready for use as motor feedback, just as if it were from a real encoder.

Thank you for bringing this to our attention. The Coord[x].Csolve bit is only used for a coordinate system set up with axis definition statements. It determines whether the set of axis definitions is mathematically invertible to permit computation of starting axis positions. When you have a forward kinematic subroutine for the coordinate system, PMAC cannot evaluate whether it is "proper" or not, so it does not compute a value for the Csolve bit, and it does not look at the Csolve bit when program execution is started. We will update the documentation to clarify this.

You read them in the same way you would read a quadrature encoder on an ACC-24E2x board. The two servo channels in the "Gate2" IC of the Acc-5E each have a structure that is identical to each of the four servo channels in the "Gate1" IC of an ACC-24E2x board. So you can use Gate2.Chan[j].ServoCapt of an Acc-5E (the encoder count value latched on the servo clock) just as you use Gate1.Chan[j].ServoCapt on an Acc-24E2x board. The 1st handwheel (HW1) on an Acc-5E goes into Chan[0]; the 2nd handwheel (HW2) goes into Chan[1].

This setup is working for me here today. Here are some things to look at: What is the value of Motor[x].IqCmd (the servo output)? This should be 1/65536 of the desired position value, as it is scaled as a signed 16-bit value, not 32 bits. Double check the motor's output address. It should report back as Acc24E2A[6].Chan[0].Pwm[0].a, which is the same address as Dac[0]. This register is scaled as 24 bits at the high end of the 32-bit data bus. It only has physical circuitry in the high 18 bits. This means that the low 14 bits written over the 32-bit data bus are lost, so a value of 16384 is required even to get 1 LSB out on the DAC. Full range on the DAC corresponds to +/-2G. Try just jogging the motor while all key variables are monitored in the watch window. This should help you get a feeling for the numbers.

If the error bit is appears not to clear on re-enabling the motor, it is probably because the error is immediately occurring again. What happens if you issue an "out0" (open-loop, zero output) command to the faulted motor? This will re-enable the motor without the possibility of getting another fatal following error, because there is no following error in open-loop mode. What could be changing in your setup after power-up/reset that makes it susceptible to immediate following error? This change would get set back to saved values on a re-start.

Almost always, the coordinate system setup is part of the initial configuration that is saved for an application. Once saved to flash memory, it is automatically there as soon as you turn on the PMAC. There should be no need to execute a program each time you power up to re-create that setup. You can create the axis definitions interactively through the "Setup Variables" window in the IDE. (Delta Tau/Configure/Setup Variables/Coordinate Systems/Axis Definitions. Alternately, you can put them in one of your project files as on-line commands so they are made every time you download your project from the IDE.

A few key points you may be missing: You must always keep in mind the difference between buffered program commands and on-line commands. When you send buffered program commands to the PMAC, they are simply stored (in the specified open program buffer) for later execution. So when you send: open prog 1 X1000 close you have simply stored the program command "X1000" in motion program buffer 1 for later execution. Note that this program does not "belong" to any coordinate system in PMAC, but any coordinate system in PMAC can potentially point to it and run it. To get this program to cause actual motor motion, you must first have a coordinate system with one or more motors assigned to the X axis. This set up must be done before you try to run the program. This is done with "on-line" commands. On-line commands are executed immediately when they are sent to the PMAC, and then they are thrown away. They are not stored as program commands are. So to set up the coordinate system, you want to use two on-line commands: &1 // Address C.S.1, so that future C.S.-specific commands operate on C.S.1 #1->X // Assign Motor 1 to the X-axis in the addressed C.S. Remember that these are on-line commands, and not part of any PMAC program. You can just type them into the terminal window. You can check to see if your axis definition "took" with the query command #1-> You should get a response that includes: &1#1->X Now, we want to set the motion program counter for this coordinate system to the beginning of our motion program. This is usually also done with on-line commands. Again, you can type them into the terminal window. &1 // Address C.S. 1 (not needed if already addressed, but won't hurt) B1 // Point motion program counter to Beginning of Motion Program 1 You are now ready to run the motion program if all of the motors assigned to axes in this coordinate system (which should be just one motor in your case) are enabled in closed-loop mode with no error conditions. The on-line C.S.-specific "R" command should run the program at this point. Most of the time, you will combine these on-line commands into a single command line: &1B1R or if already addressed, just B1R

The ACC-24E2S uses MC3487 differential line drivers for its outputs: PULSE+, PULSE-, DIR+, DIR-, AENA+, AENA-. These have 1-kohm pullup resistors and 33-ohm in-line current limiting resistors on each line. If these cannot hold a high voltage close to 5V when attached to your amplifier, your amplifier must be providing a very low resistance path to 0V (that is, a very strong pull-down, much stronger than the 1-kohm pullup). This would be very unusual, and probably indicates that something is wrong. The line drivers can easily supply 10mA without significant droop. The AENA+/- output signals use the same pins that are normally used for the encoder index (C+/-) inputs. You must install the appropriate jumper for the channel (E11, E12, E13, E14) to be able to use these pins for the AENA+/- outputs.

Yes, that is correct. The external time base function just controls the numerical time value PMAC uses to update the mostor trajectories to the next servo cycle's set point in the fixed physical time for the servo cycle. Whether this set point is output directly to drives, as with position-mode EtherCAT drives, or used internally to close the servo loop, whose results are output to the drives, as in torque-mode or direct-PWM mode drives (whether on EtherCAT, MACRO , or a direct connection, the drives are kept in full synchronization to the external time base through this method.

Check for any software setup variable that could be overwritten to stop the operation of this function.

When I tune an axis with a net load like gravity on a vertical axis, I like to put a very small, but non-zero, integral gain term on early. It can be 1/1000 of the likely value you will end up with, and take take 30 seconds to reduce the steady state error to a minimal value. Once the error is minimal, I can do step responses to tune Kp and Kd for a good step response with minimal overshoot. At this point Ki is too low to affect the dynamic response of the step significantly. Once I have set Kp and Kd this way, I now start increasing Ki. This will increase the overshoot. Personally, I don't mind getting about 15% overshoot (others don't like this), but I find as long as the overshoot is not followed by some undershoot (this may be the "resonant" behavior you see), you will have good performance.

If you really want to compute an "arbitrary" (from the PMAC's point of view) position every servo cycle, what you are doing now is probably as good as any. The cost of re-computing position error and desired velocity is tiny. However, most users conclude that it is not necessary to compute an arbitrary point every servo cycle, and instead command points at short intervals in a motion program, letting the PMAC interpolate between these points with one of its move modes. A common example of motion program code to do this in a robotic application is: spline(MySplineTime) while (StreamingPoints) { // Calculate or read axis points here X(Xpos) Y(Ypos) Z(Zpos) A(Apos) B(Bpos) Z(Zpos) } "MySplineTime" is the time for each commanded move in milliseconds. It does not need to be an integer multiple of the servo cycle time. "StreamingPoints" is a Boolean control flag. The comment shows where you would insert your code for reading and/or computing the axis command positions. Most people just do it in our Script language, but you can also call a C subroutine to do this using our special "CfromScript" subroutine. In action, PMAC computes the move equations for each axis from the move description. In the Spline mode, positions, velocities, and accelerations are guaranteed continuous, even at the move boundaries. When the Spline moves are quite short (a few milliseonds, but still greater than the servo time), there are few systems with the mechanical bandwidth to do anything physical that does not conform to these constraints. The motion program must calculate two moves ahead to calculate a trajectory with two derivatives continuous. So there would be a time delay of two move times in this mode. Most, but not all, applications can tolerate this. Motion program execution is automatically sequenced so that it handles the timing of execution to stay two moves ahead.

It looks like the underlying issue is this: the PosError value computed automatically by Power PMAC before the servo algorithm is entered must use the value of DesPos that existed before the servo algorithm started. If you change the value of DesPos inside your custom servo algorithm, of course the value previous computed for PosError will be wrong, and if you want it to be correct, you will need to recompute it, as you have been doing. You will also need to re-calculate the DesVel term (as the difference between your new DesPos and the previous cycle's DesPos) if you want to use velocity feedforward properly. In the Script programming environment, we prevent people from writing to registers like these that PMAC computes automatically, because it has the potential to be very dangerous. The C programming language does not provide protections like this, so it is possible to write to DesPos in your own C subroutine. Do take great care in doing so.