LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Rotary Encoder + ni usb 6009

Solved!
Go to solution

Hello all,

 

I'm a MSc Student and currently i need to interface correctly LabVIEW to an incremental encoder from RS through a DAQ NI USB 6009.

 

Firstly I have to say that I'm just a beginner with this kind of applications, however my goals is to get angles mesaurements. 

 

My encoder is connected at DAQ trough 4 wires: Vcc (5V), GND, AI0, AI1. Actually i prefer to don't change the wiring just because as you know about Covid spreading i'm working remotely and i can't use tools to do it, if i have would had to do.

 

Basically what I need is to convert voltage mesaurements to angles values.

 

If you need further information about the setup let me know.

 

Thank you. 

0 Kudos
Message 1 of 41
(5,445 Views)

We will need to know how many pluses per revolution for each phase (A,B). You will have to write code that finds the leading and trailing edges of the pluses. This will allow you to determine the direction of rotation. We will also need to understand how fast you are planning to rotate the encoder. This DAQ device may not be the right one for this instance if you are planing to rotate quickly.

 

 

Tim
GHSP
0 Kudos
Message 2 of 41
(5,438 Views)

Thank you for the quick reply.

 


@aeastet wrote:

We will need to know how many pluses per revolution for each phase (A,B). You will have to write code that finds the leading and trailing edges of the pluses. This will allow you to determine the direction of rotation.


https://uk.rs-online.com/web/p/rotary-encoders/7951081/

 

This is the encoder i'm curretly using. Where can I find the other informations? 

 


@aeastet wrote:

This DAQ device may not be the right one for this instance if you are planing to rotate quickly.


Honestly, I think i don't need so high spped, i mean, up to 20Hz let's say. But anyway it depens over what you mean with quickly.

0 Kudos
Message 3 of 41
(5,428 Views)

OK Here is the problem that you are going to have with what you have.

 

The encoder is 500ppr. You want to run it at 20Hz. Doing the math on this you will need 2 channels running at minimum 10Ks/s. I usually try to sample faster that the signal I am measuring so I do not miss anything. I usually use 10 times faster as my rule of thumb. Given this you would need a device that can measure both of these channels at 100Ks/s. At minimum I would do 4 times faster which would require 40Ks/s. The device you have will do 10Ks/s. This would mean that you may miss a pulse if running at 20Hz. If you are running faster than 20Hz you will start missing pluses and get in accurate data.

 

I would recommend that you do something different as the solution you have would be prone to error.

 

You could look for missing pulses but this make the code that much harder to program.

Tim
GHSP
0 Kudos
Message 4 of 41
(5,418 Views)

But, 20 Hz is the maximum.. 

Actually i think to reach up to 10 Hz, just because speed is not my prerogative. I need just to have something to validate my data (that i'm getting using IMU: inertial mesaurements unit). 

So for those i need high speed, but not for the validation.

And according to that, how can I do to convert voltage values in angle mesaurements using Vcc, GND, AI0 and AI1 pins?

Would be faboulus if you can share some code as example.

Thank you.

0 Kudos
Message 5 of 41
(5,411 Views)

I would not do it this way. I would use a DAQ card that has high speed counters. I would set it up as a quad encoder (digital) input. This way the DAQ card does all of the hard work of figuring out pulses, calibration and they are also very fast.

 

You need to start with looking for amplitude changes (i.e. 0VDC to 5VDC and 5VDC to 0VDC). Rotate the encoder once and see if you have 500 pulses. If you do you are getting close to what you need to do.

 

After you get this working for both phases of the encoder then you need to see which one is going up first and this will allow you to write something that will give you direction.

Tim
GHSP
0 Kudos
Message 6 of 41
(5,406 Views)

@valiora wrote:

Thank you for the quick reply.

 


@aeastet wrote:

We will need to know how many pluses per revolution for each phase (A,B). You will have to write code that finds the leading and trailing edges of the pluses. This will allow you to determine the direction of rotation.


https://uk.rs-online.com/web/p/rotary-encoders/7951081/

 

This is the encoder i'm curretly using. Where can I find the other informations? 

 


@aeastet wrote:

This DAQ device may not be the right one for this instance if you are planing to rotate quickly.


Honestly, I think i don't need so high spped, i mean, up to 20Hz let's say. But anyway it depens over what you mean with quickly.


Just to be very clear, you're wanting to rotate the motor at 20Hz, i.e. 120rpm? And measure this with your 500 Pulse/revolution encoder?

 

If so, you get 10kHz frequency pulses, and the descriptions given about measurement frequency will be true.

But I want to check that's really what you're trying to describe?


GCentral
0 Kudos
Message 7 of 41
(5,400 Views)

Yes, you got it right.
That's because I get some values from IMUs and i need to validate the result with encoder.
For istance: if i got 30° from IMU i need to check how much is the error in comparison with encoder as gold truth.

Thank you.

0 Kudos
Message 8 of 41
(5,380 Views)

Yes, I did double-check and I'm pretty sure of what i mentioned before. 
Thank you a lot, your support and help would be much appreciated. It would be really.

0 Kudos
Message 9 of 41
(5,318 Views)

Hi valiora,

 

Responding to your PM, here's the link I mentioned: Frequency Measurements: How-To Guide.

This is a basic introduction to some of the frequency measurement concepts - you can also find some more links at the bottom of that article.

 

As was already mentioned in this thread (and I referred to in my reply to your PM), this will be much easier if you can use counters.

Without counters, you'll be limited to writing the code yourself to handle counting edges and edge detection and so on, which adds quite a bit of code/work, and then you'll also have limited resolution on the measurement (especially because your incoming frequency will be a sizeable fraction of your maximum sampling frequency).

 

I've sometimes found this link (Making Accurate Frequency Measurements) helpful, but it can also be a bit confusing/misleading in my opinion. So I'll suggest you read it, but I don't know if you'll necessarily find it useful or not.


GCentral
0 Kudos
Message 10 of 41
(5,298 Views)