Measure frequency with Flexmotion

[John L]

I'm stuck with what I thought was a simple task... I've got a spare Flexmotion 6C and I would like to use it to, amongst other things, measure a simple frequency (TTL square wave). In the manual it's said that encoder inputs may be used for such tasks if not used in an axis configuration. I tried hook it up to the inputs but only get strange read back. Any help would be most welcome because I am lost!

[Yusuf C]

Hello,

Can you describe the readings you're getting in more detail and how you are reading them?

Best regards,

Yusuf C.
Applications Engineering
National Instruments

[John L]

I got it to work, at least partially. I configured a servo axis in MAX which had the encoder mapped to it as primary feedback. Then I connected my pulse-source to encoder A and B (single ended). By calling "read velocity in rpm" I do get a reading which varies with the pulse frequency. However, the reading fluctuates extremely much. By increasing the number of pulses/rev in MAX and increasing the frequency I could get the "noise" down. But to get this I had to set the number of pulses/rev to 1000 and input a frequency of 100kHz. In the real application I really can't do this since my source gives a frequency from approximately 5-300Hz. I must have missed something but I can't figure out what. Any ideas?

Regards,
John

[Buechsenschuetz]

Just an idea... Usually incremental encoder inputs will only detect an rpm value if there is a proper phase sequence between phase A and phase B of the encoder. A has to preceed B (or vice-versa) to count pulses from an incremental encoder. Maybe the FlexMotion board is somewhat puzzled when A and B arrive simultaneously.

We had a similar problem and tried to count pulses with the FlexMotion board. One of our guys just connected the pulse source to encoder input A of one axis via the UMI box and left the other input floating (it will be in the high state then, I assume). The board counted the pulses properly.

But both methods - the one you tried and our method - do NOT comply with the definition of incremental encoder pulses used on the
FlexMotion boards, so probably there will be problems when counting single-phase pulses with these methods. Maybe delaying the pulses by 1/4 phase and feeding them to encoder input B, too, might help - but for this you will need a phase shift filter (in case your pulses do not have constant frequency).

[John L]

Thanks for your input . I think I'm beginning to understand the problem. It is really ok to send in simple pulses to, say, encoder A. They will be counted correctly either one reads the velocity of a configured axis or just checks the number of counts directly from MAX or a .vi. What I believe to be the problem is the very high speed of the reference frequency. The time between each counter reading is so short that one needs high resolution encoders and thus high frequencies. The flexmotion board does not offer a "gate" input so one can control this at will and this means that one have to use the standard (and too high res) encoder.

I did make my own "correct" encoder signals by wiring some digital outputs to the encoder input. Ok, they were
software controlled but ok in shape and phase. The encoder counted these correctly but again failed to measure their frequency in the same way as before.

I am very tempted to draw the conclusion that it is not possible to measure such slow frequencies with the Flexmotion... The choice I have is to buy a "high-end" encoder for "low end" purposes or just use a microchip to measure the frequency and send it to the PC by RS232. I'm leaning towards the latter if no one can tell me I'm wrong!

Would it be possible to use the index input instead?

Best regards
/John

[Buechsenschuetz]

I see... our application was somewhat different from yours. We just needed to count pulses, NOT to determine a pulse frequency.

Some of the drives we are controlling with the 7344 can be run at rather low rpm values. Our software gurus (I am rather a hardware guy) have a test program which indicates rpm, and I remember that the rpm values indicated with low rotation speeds have a lot of 'noise' while higher figures are more consistent. We are using encoders with 2000 lines resolution, and at 600rpm nominal speed the values indicated vary between roughly 595 and 605 - at low rpm values accuracy is much worse. But of course the step rate omitted by the 7344 (and the drive motion) is stable when we check it with a frequency co
unter. So it really seems as if it is not easily possible to measure frequencies (or precise rpm values) with the 7344.

I don't think you can use the index pulse input to measure frequencies. This is one of the few motion control inputs which can not be read directly, AFAIK the only access you have to proper index detection is via a register indicating successful completion of the 'find index' routine - but it does not mirror the index pulse directly. AFAIK you can read the status of the other motion control inputs (limit switches) directly.

A workaround might be to use a frequency-to-voltage converter and use an analog input of the 7344. But AFAIK the sampling rate of these inputs is fixed and cannot be set by the user. I think the solution you suggest (using an external processor, such as an 8051 which has timer/counter registers and a RS232 port) might be easier and more precise.