curtwilson

"Third harmonic injection" is a commonly used technique for electronically controlled 3-phase motors that increases the effective supply voltage by about 15%. It adds a small component of a 3x frequency signal to the "base" sinusoidal voltage output of each phase. Because the phases are 1/3-cycle apart, all of these third harmonic additions are exactly the same for each phase, and the net phase-to-phase voltages do not change, but the use of the available voltage is better optimized. However, with 2-phase motors, the phases are 1/4-cycle apart, so adding a 3rd-harmonic component would change the net voltages applied across the phases as a function of angle, introducing a lot of current and torque ripple. The Geo Brick LV was the first product that had a power stage to support 2-phase motors, so there was a late addition to the firmware of this control bit to inhibit the addition of 3rd harmonics.

The manual is in error on the scaling of the AdcEnc registers. The processor reads them as full 32-bit registers (even though there will never be more than 24 bits of data, so the lowest bits are not "real"). So these registers have a numerical range of +/=2^31. To these values, the user-settable 32-bit AdcOffset values are added before arctangent and sum of squares are computed. The interpolator front end circuitry is scaled to provide full range into the ADCs (and therefore these numerical registers) when the input voltage is 1.2Vpp.

The HomeComplete bit is write-protected in the Script environment, as I'm sure you have noticed. There are a couple of possible tricks you could use to clear the bit, but they should be considered tricks, so it may be best you to create your own status bit to do this. (One trick is to command a homing search move with zero or very low velocity, and abort it before it can find the trigger. This will clear the bit.) In the V1.5 firmware we are in the release process now for, a new saved setup element Coord[x].HomeRequired, if set to 1, means a program cannot start unless all motors assigned to axes in the coordinate system have their HomeComplete bits set to 1.

(1) You are correct that these AdcOffset values are not used to make any corrections in the zero-crossing detection of the incoming sine and cosine signals, so these do not help in the hardware capture and compare circuits in the ASIC, which are based on the zero crossings. (2) These hardware offset registers in the ASIC for the ACC-24E3 interpolator perform the same function that the encoder table SinBias and CosBias software offset values perform for the older ACC-51E interpolator, where the arctangent is calculated by the processor. These hardware and software offset values can be used to compensate for DC offset in the signals, but not phase offset or magnitude mismatch. In the new V1.5 firmware being released this month, the encoder table entry for arctangent extension of sine/cosine encoders has several added features: a) A new correction element EncTable[n].TanHalfPhi for phase error correction (Phi is the error angle from the ideal 90 degrees). b) A new correction element EncTable[n].CoverSerror (cosine over sine error) to compensate for magnitude mismatch c) A new control element EncTable[n].index5 to permit this software extension to be used with the newer ASIC. Note that this bypasses the hardware extension done in the Gate3 IC, and replicates it in software, but with these additional correction terms. Note that these corrections are used at the servo update rate, so will improve the quality of servo feedback, but will not help with hardware capture and compare features.

Motor[x].DesPos is most equivalent to the "net desired position" register in Turbo PMAC, which is the sum of trajectory, master, and compensation positions. It is automatically computed from its components each cycle, so you cannot write to it. Motor[x].Desired.Pos holds the trajectory commanded position only. While no trajectories are being computed, you can write to it, and the new value is maintained.

The whole point of going to double-precision floating-point and keeping a residual was so that our users would never have to worry about this and play these games. Looking at your numbers, I don't think you would have any problems for the life of the universe. If you really want to do this, it looks like Motor[x].Desired.Pos is the best register to overwrite. You would execute: Motor[x].Desired.Pos+=Motor[x].MasterPos Motor[x].MasterPos=0 This works for me when nothing else is going on. I have not verified all aspects of this, or exactly what needs to be done (e.g. PMATCH) before subsequent motion.

We went to the double-precision floating-point format for motor registers so you would not have to worry about these things. Yes, the range is not infinite, and in theory you could potentially get to a point where you would start losing effective resolution. However, with a 52-bit mantissa, I have not seen an application where this is a real-word worry. In addition, in our position accumulation algorithms, we keep "residuals" such as Motor[x].ResMasterPos (also 64-bit floating-point), to ensure that in the tiny chance you start losing effective resolution of the 52-bit mantissa of the main register, the residual is there to prevent this. Effectively, here we have a 128-bit floating-point value. With this, I strongly doubt that it would be physically possible to run into the problem you are concerned about during the entire lifetime of the machine.

Is the plot one of position-versus-time for a single axis, or the path in a Cartesian (e.g. XY) plane? I'm confused from the description. In either case, I would probably use short spline mode moves of uniform time in a loop, calculating each destination position as the sum of the cyclic and linear components.

There are a lot of different things going on, so it can get confusing. That paragraph was badly written (thanks for pointing it out). The paragraph above it is correct in specifying 12 bits of fraction in the compare registers. If TimerMode is set to 0, the ASIC is calculating timer-based sub-count estimation with 12 fractional bits. Not all of these bits are available in all registers in all modes. If AtanEna is set to 0, the ServoCapt, PhaseCapt, and HomeCapt registers only latch the first 8 bits of this information, as this is enough resolution for almost all users, and provides 24 bits of whole-count information in the 32-bit register. (Note that in this mode, the TimerA register has 12 bits of fraction latched on the servo clock, and TimerB has 12 bits of fraction latched on the input trigger.) If AtanEna is set to 1, the ServoCapt and PhaseCapt registers have 12 bits of fractional count resolution from the A/D registers through the arctangent function. (This is 14 bits of fraction per line, for a x16384 interpolation.) The CompareA, CompareB, and CompareAdd registers always have 12 bits of fractional data. The added resolution is particularly useful for the CompareAdd register, even if not needed for individual compare events. The subcount estimation used to compare against these registers is from the timers (when TimerMode = 0), even if AtanEna is 1. The A/D converters cannot be sampled often enough to be useful for compare purposes.

For purposes of the compare function, the subcount estimation is generated by timer circuits in the ASIC using the ratio of the time since the last zero crossing (hardware count) of the sine or cosine signals and the time between the last two zero crossings. Make sure that Gate3.Chan[j].TimerMode is set to its default value of 0 to enable this timer-based sub-count estimation. Typically, the biggest source of error in this technique comes from uneven spacing of the zero crossings, which can be due to voltage offsets, phase offset, or magnitude mismatch in the sine/cosine signals. These distort the ratio calculations of this estimation.

I have attached a file explaining how to use these I/O boards with the Power PMAC. It should cover your needs.Using Digital IO Boards with Power PMAC 2012-06.pdf Using Digital IO Boards with Power PMAC 2012-06.pdf

When Gather.Type is not in the range 0 to 5, it contains a code specifying what part of a 32-bit integer register the element specified by Gather.Addr occupies. That is, when Gather.Addr is set in the Script environment to the address of a partial-word element, Power PMAC automatically sets Gather.Type to this code. Note that this code does not affect the gathered value, which will always be the full 32-bit register. Rather, it can be used to isolate the desired portion of this 32-bit value. Gather.Type is a 16-bit value. The high 5 bits (11-15) specify the starting (low) bit number of the partial-word element in the 32-bit word. The low 11 bits (0-10) specify how many bits are used. The values of interest are: 1 bit: $7c6 2 bits: $786 3 bits: $746 4 bits: $706 8 bits: $606 12 bits: $506 16 bits: $407 So for Motor[x].AmpEna, Gather.Type is set to 26566 ($67c6). This means 1 bit ($7c6) starting at bit 12 (6*2 + 0). A value of 50694 ($c606) means 8 bits ($606) starting at bit 24 (c*2 + 0). More generally, the value in bits 6-10 is 32 minus the number of bits in the element.

Make sure the coordinate system is in "segmentation mode" by setting Coord[x].SegMoveTime greater than 0. (5 msec usually works fine.) When you are transitioning between LINEAR and PVT moves, the TA and TD times are not used -- effectively, the LINEAR move has a TA or TD time of 0 at that end of the move.

Either I'm not understanding your question or I'm not able to duplicate your issue. If I command a multi-axis move and abort it in the middle, multiple axes still show a non-zero "distance-to-go". This is an intended feature. If I then command a new programmed axis move with only one axis explicitly commanded (or even just not all axes that had non-zero distance-to-go), any axis that is not explicitly commanded is implicitly commanded to do a zero-distance move. As soon as this move starts, these axes will report zero distance-to-go. (In one test, one of my axes reported a distance-to-go of about 10^-16 motor units, probably due to some floating-point round-off issue, but any formatting for display would show this as 0.0.)

When you abort a motion program, the reported distance-to-go for each axis is still calculated as the destination position of the most recently executing move minus the present commanded position. This is as it should be, as many users would want to see that the move in progress had not finished. Fundamentally, the act of aborting, whether by command or due to some sort of fault, does not clear the target position buffer (nor should it). As you note, as soon as another programmed move is calculated, the distance-to-go is correct for this move. What you desire is the ability to clear the target position buffer at some point before you actually calculate your next move. Because we can't clear the buffer automatically on an abort, this must be done as a discrete step, from a command. (Loading another program cannot be the trigger for this, as we do not know why you are doing this.) We do not have an explicit command to clear the target-position buffer. However, you could easily clear the buffer with a command like: cpx inc x0 y0 z0 This commands a zero-distance move, making the target position equal to the present position, so all distances-to-go are zero. Alternately, you could use logic in your HMI to report zero DTG when in these modes.

I'm not having any trouble getting my system to take this (pasted directly from your post). It also takes the auto-assigned form: ptr ACC34SW1->u.user:$00.0.32; I'm trying to figure out what could be different about your system, but no ideas yet.

The limitation in the format that is tripping you up is explained further below in the description: ******************************* Legal values for bit width and bit offset are inter-related. The table below shows the possible values of {width}, and the corresponding legal values of {offset} for each setting of {width}. {width} {offset} 1 0 -- 23 4 0,4,8,12,16,20 8 0,4,8,12,16 12 0,4,8,12 16 0,4,8 20 0,4 24 0 ********************** Two things to note: You cannot specify a width of 2 bits, and if you specify a width greater than 1 bit, the starting bit must be divisible by 4.

As a register in a hardware device, it is technically not part of shared memory, which is in RAM. In the Script environment, this is hidden from you, so you can access it through the element in the same manner that you would an element in RAM. This works in foreground (real-time) routines as well as background. In C, you must access hardware registers in a different manner from memory registers. The User's Manual chapter on "Writing C Functions and Programs" explains this in detail.

In the manual chapter "Synchronizing Power PMAC to External Events", in the section on position capture, there is a lengthy discussion on converting the raw captured encoder position to motor (and axis) position. It uses the trigger-latched "HomeCapt" position, but all of the equations are equally valid for the clock-latched "PhaseCapt" position as well.

Yes, the ACC-24E3 latches the encoder position every phase clock cycle. The data can be found in Gate3.Chan[j].PhaseCapt. The functionality is enhanced compared to the older card. If saved setup element Gate3.Chan[j].AtanEna is set to 1, there will be 12 bits of fractional count resolution (14 bits of fractional line resolution) from the automatically computed arctangent value in this 32-bit register. If AtanEna is set to 0, there are 8 bits of fractional count resolution (10 bits of fractional line resolution) in the register. If saved setup element Gate3.Chan[j].TimerMode is set to 0, this fraction comes from the 1/T sub-count extension. If TimerMode is set to a value greater than 0, the fractional value is forced to 1/2 count.

The ASIC in the ACC-24E2A automatically latches the encoder count every phase cycle. This data can be found in Gate1.Chan[j].PhaseCapt. This data is the raw encoder count, referenced to power-on/reset position, and without the 1/T sub-count extension you are probably using in servo feedback.

Each communications thread, each coordinate system (for motion programs), and each PLC program has its own addressed coordinate system (and motor). Changing the addressed coordinate system from inside a program will not change the addressed coordinate system for a communications thread (e.g. the IDE terminal window). It will change it for that program, and therefore for coordinate system direct commands issued from within the program (which is what you want, I think). To check this out, you could have something like the following program commands: Ldata.Coord = 1; P1 = Ldata.Coord; abort; This will let you monitor the global variable P1 to see what coordinate system the program is addressing.

There is light filtering on the analog inputs (there must be some), but less so than most interpolators. How does the value in Gate3.Chan[j].SumOfSquares roll off with velocity? At what signal frequency do you start to see the problem? Does increasing the EncLossLimit parameter help? This would de-glitch the error detection.

The single-bit EncLoss status bit in the ACC-24E3's ASIC is set if the highest four bits of the "SumOfSquares" magnitude of the sine and cosine signals are all 0. That is, when this magnitude is less than 1/16 of the maximum possible. However, if the most significant bit is ever set, that is an indication that your signal has saturated the ADCs, so the cutoff magnitude is 1/8 of the maximum valid signal. Since this is a square value, you will get the status bit set when the signal magnitude is less than 1/sqrt(8), or 35%, of maximum. It may be possible that your signal is shrinking this much at high velocities. While the effective resolution is reduced when the signal shrinks this much, it can be good enough for high speed operation. If this is all that is going on in your case, you will not want to use the hardware bit for your encoder loss detection. Instead, you may want to write a line of code in a PLC program that sets a bit if all of the (say) 6 highest bits in SumOfSquares are 0 - this would set the bit if the signal magnitude goes below 17% of maximum - and point to this software-generated bit with pEncLoss and EncLossBit.

It appears that the offset is from the 1/T extension being performed in the IC. It is computing a fractional count value in the direction of motion by dividing "time since last count" by "time between last two counts". When you stop, "time since last count" becomes greater than "time between last two counts", which would result in a "fractional" value greater than 1. Since this is not possible, the algorithm "saturates" the fractional value at 255/256. While the 1/T extension is wonderful for smoothness during motion, when used as a master in this way, it has this undesirable offset characteristic for you. You should disable this function by setting Gate3.Chan[j].TimerMode to 1. (Remember to set Sys.WpKey to $AAAAAAAA to enable changes if you are doing this manually.)