Gate3[x].EncClockDiv

I have a PPMAC system with 2 Acc24E3 cards; the feedback encoders are 2000 cnt/mm quadrature encoders. We also have an Acc24E2 card in the same rack.

I found that we started to loose encoder counts at a motor velocity of approximately 1400mm/sec on the E3 card. Putting the same encoder on the E2 cards we didn't loose counts until about 2000mm/sec.

After re-reading the E3 manual I discovered the Gate3[x].EncClockDiv parameter and set it from 5 to 4; now the E3 encoders don't loose counts until about 1900 mm/sec (which is better for our process, 1400mm/sec is too close to where our process wants to run).

My question is: knowing that you rarely get something for nothing; what are the pitfalls of increasing the Encoder Clock Frequency? Can I just set EncClockDiv to 4 for all my E3 cards and call it good? Anything else I need to consider when changing the hardware clock frequencies? Are the default hardware clocks just higher in the E2 cards?

The motors are already setup and running, we just experienced problems at higher velocities.

Thanks,

Kevin Monroe

Kmonroe023,

You are very correct when stating

knowing that you rarely get something for nothing;

The following is from our Turbo PMAC Users manual, modified to match with Power PMAC terms, but the idea still applies and holds true.

After the front-end processing through the differential line receivers, the quadrature encoder inputs are sampled by digital logic in the Servo IC or MACRO IC at a rate determined by the frequency of the GateX.EncClockDiv encoder sample clock, which is user selectable. The higher the GateX.EncClockDiv frequency, the higher the maximum permissible count rate; the lower the GateX.EncClockDiv frequency, the more effective the digital delay noise filter is.

Each encoder input channel has a digital delay filter consisting of three cascaded D-flip-flops on each line, with a best two-of-three voting scheme on the outputs of the flip-flops. The flip-flops are clocked by

the GateX.EncClockDiv signal. This filter does not pass through a state change that only lasts for one GateX.EncClockDiv cycle; any change this narrow should be a noise spike. In doing this, the filter delays actual transitions by two GateX.EncClockDiv cycles – a trivial delay in virtually all systems.

If both the A and B channels change state at the decode circuitry (post-filter) in the same GateX.EncClockDiv cycle, an unrecoverable error to the counter value will result. The ASIC hardware notes this problem by setting and latching the GateX.Chan[j].CountErr bit. The problem can also be detected by capturing the count value each revolution on the index pulse and seeing whether the correct number of

counts have elapsed.

 

 

The GateX.EncClockDiv frequency must be at least four times higher than the maximum encoder cycle (line) frequency input, regardless of the quadrature decoding method used (with the most common times-4 decode, the GateX.EncClockDiv frequency must be at least as high as the count rate). In actual use, due to imperfections in the input signals, a 20 – 25% safety margin should be used.

 

If very high encoder count rates are required, the GateX.EncClockDiv frequency may have to be raised; if better filtering is required to prevent count errors, the GateX.EncClockDiv frequency may have to be lowered.