Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Position error peak and encoder loss
#1
Hello everyone,

We have a rotary stage with the following setup:

- AC Brushless motor with 18 poles;
- Sensor hall;
- Incremental encoder (sinusoidal); with interpolator x20k 40 MHz;
- EncClockDiv = 0 (100 MHz).

We already did the Manual Phasing procedure to find the PhasePos on the encoder index and we're able to use the sensor hall for the commutation.

A good stability performance was achieved, but during the jog it apresents a strange behavior. In the positive jogs a peak of 2000 counts occur in the PosError.

Trying to find the reason we discover that the LossCapt bit is always 1, even if we set to 0 in the terminal.

The plot with the LossCapt together with the LossStatus show us that the LossStatus gets high many times before the LossCapt rise up.

We also did some teste with a interface of x20k 10 MHz, and with the EncClockDiv = 2 (25 MHz) the 2000 counts in the PosError doesn't happens anymore.

Does anyone have any suggestions for what may be happening?

Thanks in advance.

Leandro Martins
Reply
#2
(06-28-2019, 11:09 AM)leandro.martins Wrote: Hello everyone,
We have a rotary stage with the following setup:
- AC Brushless motor with 18 poles;
- Sensor hall;
- Incremental encoder (sinusoidal); with interpolator x20k 40 MHz;
- EncClockDiv = 0 (100 MHz).
We already did the Manual Phasing procedure to find the PhasePos on the encoder index and we're able to use the sensor hall for the commutation.
A good stability performance was achieved, but during the jog it apresents a strange behavior. In the positive jogs a peak of 2000 counts occur in the PosError.
Trying to find the reason we discover that the LossCapt bit is always 1, even if we set to 0 in the terminal.
The plot with the LossCapt together with the LossStatus show us that the LossStatus gets high many times before the LossCapt rise up.
We also did some teste with a interface of x20k 10 MHz, and with the EncClockDiv = 2 (25 MHz) the 2000 counts in the PosError doesn't happens anymore.
Does anyone have any suggestions for what may be happening?
Thanks in advance.
Leandro Martins

To be clear, you are running an external interpolator and generating a 40 MHz edge rate on the quadrature? This is the extreme edge of what is possible and will require near perfect signals. Since you have a sine encoder have you considered using the Delta Tau sine interpolator, either the normal or the newer AutoCorrecting Interpolator (ACI)? At very high effective count rates these work much better.
Reply
#3
The encoder-loss detection circuit in the ASIC looks at the states of the differential signal pair inputs (A+ vs A-, and B+ vs B-) to see that they are in opposite states as they should be. If in the last 2 out of 3 encoder sample clock cycles, the signals in either pair are in the same state (both high or both low), the encoder will be considered to be in the the "loss" state.

It sounds like there is something in your signal that being caught at 100 MHz sampling, but not at 25 MHz -- possibly asymmetrical edges (e.g. faster fall than rise) or noise -- that is fooling the loss detection signal. Note that this error does not necessarily mean that the decoding and counting circuitry is also failing.

Lowering the sample clock frequency improves this, as you have seen, but it does limit the highest real count rate the ASIC can accept. If the input frequency is too high for the sample clock frequency, the "count error" flag will be set.
Reply
#4
Thanks for the answer JeffLowe and curtwilson,

Almost all of the stages that we acquire uses Renishaw's external interpolator. We already evaluating to get a Delta Tau sine interpolator.

Summarizing, if "count error" flag doesn't get high we don't have to worry about the quality of the sinal acquired. Right??

Our main concearn now is the peak in the PosError, that increases the control effort during this peak.
This value of 2000 counts occur only during one clock cycle, and in the Servo Frequency that we're using (20 kHZ), it represents the maximum count rate that the interface of 40 MHz can read.
Emphasinzing that this peak is not periodic and only happens in the positive direction movements.

We came to consider that it could be a rollover problem, but this hypotesis was discarded plotting the PosError and the ServoCapt register.

We tried to set the MaxDelta=32767 and apparently it compensates some of theses peaks, but in some point the response begins to diverge.

Some useful information:
- CPU: PowerPC,APM86xxx
- Firmware: 2.4.0.180
- IDE: 4.2.1.19

What is the possible cause of this peak and is possible to work with the 40 MHz interface since we set properly the MaxDelta?
Reply
#5
Encoder systems that convert the fundamental sinusoidal signal frequency to a higher frequency quadrature signal must use some kind of tracking feedback loop to perform the interpolation. (How exactly each encoder system does this is usually proprietary.)

Sometimes the dynamics of this tracking loop can be a little strange, especially if something in the loop saturates, and then the loop must "catch up" later. It sounds like something like this is happening here. You may have to take a very close look at the incoming quadrature signals with a good scope.

Note that Delta Tau's own interpolators are "direct", using an instantaneous snapshot of the signals, and so do not have these issues.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)