Jump to content
OMRON Forums

Fast Motor Count error


jsinoir

Recommended Posts

Hello,

We have a problem with one of our setup, we try to use a coder with a 5 nm resolution and we want to go at 100 mm/s

the channel EncCtrl is configured in *4 quadrature CW

 

The motor DAC is on IC 2 whereas the coder is on IC 4.

the HardwareClockCtrl of the IC 4 is set to 2256 to be able to benefit from the 39MHz SCLK. (the HardwareClockCtrl of the IC 2 is also set to 2256 although I suspect this is not necessary)

 

in principle 100mm/s = 100nm/us =20 cnts/ us = 20MHz < 39 MHz

so we should be able to reach these speeds.

 

but what we see in practice is that the CountError flag is raised somewhere around 65 mm/s which is equivalent to an input frequency of 13 MHz

and we indeed see that the repetability of our movments suffers (steps are indeed lost) when the speed goes higher than 60 mm /s

 

Am I missing a parameter ?

our coder is capable to generate reliable quadrature signals at 250 mm/s . the

signals coming out of it look OK, not noisy, apparently free of any forbidden transitions .

 

Have a good day,

 

cheers,

Jeremy Sinoir

Link to comment
Share on other sites

  • Replies 4
  • Created
  • Last Reply

Top Posters In This Topic

 

in principle 100mm/s = 100nm/us =20 cnts/ us = 20MHz < 39 MHz

so we should be able to reach these speeds.

 

 

 

You have explained your difficulty precisely.

If not familiar with the 'Nyquist criteria' check the attached link: https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem

This is a basic concept of digital signal processing that is universally accepted in applications ranging from A-D conversion to serial communications, including quad encoder interfaces.

 

In general, to digitally sample a signal, the absolute minimum is 2x the fundamental frequency of the sampled signal. I generally prefer 4x for reliability.

You are losing your signal integrity at ~fundamental=60% of the sample freq., which roughly agrees with Mr Nyquist's predictions not to exceed 50%.

I would say you should not depend on being successful above 50mm/s, and that would be sketchy. Classic clash of speed vs resolution.

[Clarification: your system is near the Nyquist limit, my comments are biased by my preference for a safety margin by using 4x margin]

 

At 20mhz you'll need to be sure you have proper termination, very good cable, minimized length, & proper impedance matching to maximize performance.

Link to comment
Share on other sites

Hello,

thank you for your answer, we thought of that, but we discarded that explanation given that the frequency of our A and B lines is 4 times lower than the frequency of the coder steps. That means that the analogic sinal we try to convert with our digital circuitry is not 20 MHz but 5MHz which is way below Nyquist criteria. Am I wrong to assume that ?

Thank you very much for your help.

have a good day,

cheers,

Jeremy Sinoir

Link to comment
Share on other sites

The "count error" flag is set if ever both the A and B inputs change in a single SCLK sample cycle. With your setting of ~40 MHz SCLK, the sample cycle is ~25 nsec long.

 

So a perfect quadrature encoder could go almost to 10 MHz signal frequency (almost 40 MHz count frequency) without causing errors.

 

With standard (non-interpolating) encoders, we generally recommend a limit of 80% of the frequency of a "perfect" encoder.

 

However, often encoders with their own interpolating electronics (which I suspect you have) occasionally will put out edges much closer than this, as the internal tracking loop electronics try to adjust. I think this is what you are seeing. So you can be limited much more with these encoders.

 

(The proper interpretation of Nyquist in this context is that you must always sample again. before the quadrature signal gets halfway around the cycle.)

 

Our newer DSPGATE3 IC can use SCLK frequencies of up to 100 MHz.

Link to comment
Share on other sites

Hello,

Thank you very much for your clarification Curt, we will replace the coder by a pulse generator to try to validate that.

Your comment about DSPGATE3 is also very interesting.

That would be a great alternative, an other alternative we considered would be to use a Serial encoder ,

but both these solution are unfortunately impossible for us because we are restricted to our CPCI rack format, which does not accept yet the DSPGATE3 cards ...

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...