Felix Posted September 29, 2009 Share Posted September 29, 2009 The result of a home command for a motor that is connected to the ACC24E3 and uses a sinusoidal encoder for feedback with the arctan extension enabled appears to depend on the number and sequence of home commands given. This is what I have observed: After a home command has been given via the terminal (#1hm) the motor starts moving and reverses direction once it passes the index mark as expected. However, instead of coming to a stop once it reaches the index mark (no home offset is programmed Motor[1].HomeOffset = 0) the motor does not stop but keeps turning until it passes the index mark again after a full revolution of the axis and then comes to a stop about a 1/16rev past the index mark. If another home command is given immediately once the first home move has completed, the axis moves past the index mark, reverses direction passes the index mark again and comes to a stop about 1/8rev past the index mark with out going a full revolution first. If however any axis move command is given before the second home command is issued the axis behavior for the second homing move is identical to the first homing move. In other words, depending on the sequence in which home commands are given the resulting home position is different. In none of the cases described above is the result what I expected, a motor position of zero at the index mark. The encoder index mark is not direction sensitive and is a TTL pulse that is one encoder line wide. The gate array is configured to trigger on the index high (Gate3[0].Chan[0].CaptCtrl = 1) and the arctan evaluation is enabled (Gate3[0].Chan[0].AtanEna = 1). Any suggestions on what may be going on? Thank you, Felix Link to comment Share on other sites More sharing options...
bradp Posted September 29, 2009 Share Posted September 29, 2009 [quote='Felix' pid='208' dateline='1254235185'] The result of a home command for a motor that is connected to the ACC24E3 and uses a sinusoidal encoder for feedback with the arctan extension enabled appears to depend on the number and sequence of home commands given. This is what I have observed: After a home command has been given via the terminal (#1hm) the motor starts moving and reverses direction once it passes the index mark as expected. However, instead of coming to a stop once it reaches the index mark (no home offset is programmed Motor[1].HomeOffset = 0) the motor does not stop but keeps turning until it passes the index mark again after a full revolution of the axis and then comes to a stop about a 1/16rev past the index mark. If another home command is given immediately once the first home move has completed, the axis moves past the index mark, reverses direction passes the index mark again and comes to a stop about 1/8rev past the index mark with out going a full revolution first. If however any axis move command is given before the second home command is issued the axis behavior for the second homing move is identical to the first homing move. In other words, depending on the sequence in which home commands are given the resulting home position is different. In none of the cases described above is the result what I expected, a motor position of zero at the index mark. The encoder index mark is not direction sensitive and is a TTL pulse that is one encoder line wide. The gate array is configured to trigger on the index high (Gate3[0].Chan[0].CaptCtrl = 1) and the arctan evaluation is enabled (Gate3[0].Chan[0].AtanEna = 1). Any suggestions on what may be going on? Thank you, Felix [/quote] It sounds like your problem has to do with the difference of the captured position and the servo position. Here is an excerpt from the Power Pmac Users manual chapter "Power PMAC Motor Moves" [b]Processing the Hardware-Captured Position[/b] The hardware-captured position value in the counter register must in general be processed to ensure that any unwanted bits read over the 32-bit data bus are eliminated and that the final result is scaled the same as the position-loop servo feedback. The default setup on a $$$*** re-initialization automatically sets up the proper processing for “whole-count” hardware capture with servo feedback of 1/T extension from quadrature encoders. Also, setting the value of Motor[x].EncType through the Script environment (but not from internal C programs) automatically sets up the proper processing for interpolated sine encoders, quadrature encoders, and capture over the MACRO ring. Potential mismatch in scaling comes about because the servo-loop feedback position may have sub-count resolution due to 1/T extension of quadrature encoders or arctangent extension of sinusoidal encoders, and the hardware-captured position does not. Alternatively, the servo-loop feedback position may use a high-resolution arctangent extension (12 fractional bits per count) but the hardware-captured position uses a lower-resolution extension (8 fractional bits per count). There are other possibilities as well. [i]Note that software capture always uses already-scaled motor position values, so none of these processing steps is necessary when software capture is used. The settings of the processing-control elements are not used in that case.[/i] [b]Processing Steps[/b] Power PMAC employs three discrete processing steps after it reads the hardware-captured counter position over the 32-bit bus and before it uses it as the motor’s position at the trigger for the purposes of computing the post-trigger offset move. First, it takes the 32-bit read value and shifts it right (toward the least significant end) by the number of bits specified in Motor[x].CaptPosRightShift. This is done to eliminate any unwanted bits at the low end of the 32-bit value read, either because the bits did not come from real hardware (as in the case of the 24-bit PMAC2-style ICs) or because the captured data included sub-count estimated data that we do not wish to use, or both. Next, it takes the right-shifted result and shifts it left (toward the most significant end) by the number of bits specified in Motor[x].CaptPosLeftShift. This is done to make the resulting value have the same scaling as the position-loop feedback value. Finally, it can optionally offset the captured position one-half count to match the servo feedback, if necessary. When Power PMAC performs sub-count extension of position data, either through the “1/T” timer data, or from arctangent calculations of sine/cosine readings, it offsets the position data by a half count to put the integer count value halfway in between the whole-count edges, eliminating offset between directions. Simple whole-count data from the hardware counter does not have this offset, so to match the two data types properly, it can be necessary to offset the captured data by half a count. So if the position-loop servo feedback utilizes sub-count extension, whether done in hardware or software, and the hardware-captured position does not (or, in theory, vice versa), the captured position value should be offset a half count before being used as motor trigger position. If Motor[x].CaptPosRound is set to 1, Power PMAC will provide this offset. If it is set to 0, no offset will be performed. [b]PMAC3-Style Interface for Sinusoidal Encoders[/b] When a PMAC3-style interface with the “DSPGATE3” IC is used to process sinusoidal encoders, as with the ACC-24E3 UMAC board and its analog-feedback mezzanine board, the servo-loop feedback usually uses a position value with arctangent sub-count extension computed directly in the IC, found in Gate3[i].Chan[j].ServoCapt (or PhaseCapt if the servo loop is closed in the phase interrupt). This processing, enabled if Gate3[i].Chan[j].TimerMode = 0 (the default) provides 12 bits of sub-count extension (14 bits per cycle, for 16,384x interpolation). In this case, the hardware-captured position register of the IC (Gate1[i].Chan[j].HomeCapt) has different resolution from the servo-loop position, 32 bits, with the low 8 bits being 1/T sub-count extension if Gate3[i].Chan[j].TimerMode = 0 (the default). The user must decide whether he wants to use the captured sub-count value or not. Most users will want to use the captured sub-count value on triggered moves to obtain more resolution in the captured position, as in probing and registration moves. These users should set Motor[x].CaptPosRightShift to 0 to keep all of the sub-count extension bits, Motor[x].CaptPosLeftShift to 4 to match the resolution of the servo-loop position, and Motor[x].CaptPosRound to 0, because both servo and captured position already have the same offset. Some users will not want to use the sub-count estimation for homing-search moves, as they will want their position reference to be on an exact count (the zero crossing of the sine or cosine signal). These users should set Motor[x].CaptPosRightShift to 8 to eliminate the sub-count bits, Motor[x].CaptPosLeftShift to 12 to make the value the same scaling as the servo-loop position (but with all the sub-count bits set to 0), and Motor[x].CaptPosRound to 1, because eliminating the fractional bits in the captured position removed its offset, so it must be put back in here. Link to comment Share on other sites More sharing options...
Recommended Posts