gmschoon Posted July 18, 2019 Posted July 18, 2019 We have encountered a problem with filtering of the resolver position feedback. We have the following configuration for a 4 speed resolver (as per snaps attached). Enctable[18].pEnc = ACC24E3[0].Chan[1].AtanSumOfSquares.a Enctable[18].type = 1 Enctable[18].index2 = 255 (max value for 1st order filter) Enctable[18].ScaleFactor = 1/2^16 This configuration results in the attached snap, where "Motor[2].Pos" appears to move backwards slightly periodically while the motor shaft is being rotated consistently in one direction. This only happens when the motor is rotated at a sufficient speed. When we do not use filtering (i.e. index1 = index2 = 16) the position reported as we rotate the motor is as expected and increments consistently in whatever direction the motor is moved. Also of note: As far as we can determine from the manuals, we should be able to point "pEnc" to "ServoCapt" as this is the configuration used for sinusoidal encoders and other than slightly different interfacing hardware on the ACC24E3 variants it should be the same at the register level. When we look at "ACC24E3[0].Chan[1].ServoCapt or ACC24E3[0].Chan[1].TimerA" we see a sawtooth response that has a 16 bit magnitude (see trace in attached snap), far from what we would expect. Any comments appreciated...
Omron Forums Support Posted July 18, 2019 Posted July 18, 2019 What is the value of Gate3[].Chan[].AtanEna?
gmschoon Posted July 19, 2019 Author Posted July 19, 2019 What is the value of Gate3[].Chan[].AtanEna? AtanEna = 1 TimerMode = 0
curtwilson Posted July 22, 2019 Posted July 22, 2019 The data in the hardware arctangent value is 16 bits, as you have noticed. If you simply read this register as you spin the motor in one direction, you will get the sawtooth pattern you observe as the register rolls over. When PMAC uses this value for motor position, the encoder conversion table computes the difference between this cycle's value and the previous cycle's, putting the result in EncTable[n].DeltaPos. It assumes the change is always the "short way" around the cycle, so it handles the rollover of the source properly. When the motor uses this result from the ECT, it adds this "delta" value to the previous cycle's motor position. So if you were to plot the motor position while the Atan value shows a sawtooth, you would get a nice ramp. I believe what is happening with your filtering is that you are applying such a heavy tracking filter than when the speed gets up to a certain point, the tracking filter periodically starts tracking the source data the wrong way around the cycle. Note that it doesn't do this initially when the speed is lower. You really want the filter to have a time constant of only a few servo cycles to remove some of the high-frequency electrical noise.
gmschoon Posted July 24, 2019 Author Posted July 24, 2019 The data in the hardware arctangent value is 16 bits, as you have noticed. If you simply read this register as you spin the motor in one direction, you will get the sawtooth pattern you observe as the register rolls over. When PMAC uses this value for motor position, the encoder conversion table computes the difference between this cycle's value and the previous cycle's, putting the result in EncTable[n].DeltaPos. It assumes the change is always the "short way" around the cycle, so it handles the rollover of the source properly. When the motor uses this result from the ECT, it adds this "delta" value to the previous cycle's motor position. So if you were to plot the motor position while the Atan value shows a sawtooth, you would get a nice ramp. I believe what is happening with your filtering is that you are applying such a heavy tracking filter than when the speed gets up to a certain point, the tracking filter periodically starts tracking the source data the wrong way around the cycle. Note that it doesn't do this initially when the speed is lower. You really want the filter to have a time constant of only a few servo cycles to remove some of the high-frequency electrical noise. For our application we are not too bothered about the larger filter time constant, but rather need as clean a velocity signal as possible. Part of what we are unsure of is what the difference might be between the tracking filter (index2 set to max 255 and all other index=0) for a resolver and the same tracking filter used for a sinusoidal encoder. We have been using the tracking filter with index2=255 for some time with a sinusoidal encoder which goes through many more cycles per motor mechanical revolution than the resolver, without issue. From the manuals it appears that we should be able to setup the resolver in the same way as the sinusoidal encoder, however, the result we see in .ServoCapt or .TimerA is not the same (sawtooth for the resolver and a nice ramp for the sinusoidal encoder as detailed in your response).
curtwilson Posted July 24, 2019 Posted July 24, 2019 When you read the ServoCapt or TimerA register for a sinusoidal encoder, you are reading a full 32 bits of position data (as opposed to only 16 bits of position data for a resolver). In this are 18 bits of full cycle data, so it covers a quarter million lines of the encoder before rolling over. This amounts to hundreds of motor revolutions, compared to just one revolution for the resolver data. I think you can either shorten your time constant for the first-order filter you are using, or use a non-zero value for index1, providing integral action and making it a true tracking filter. This should not affect the smoothness of the result.
Recommended Posts