Problems reading a differential encoder cRIO 9014

[Luis_R.]

Hello,

I have a cRIO 9014, I am using a 6 channel differential input module NI 9411 to read data from a differential encoder, the thing is that I am transmitting the data via wireless, basically what I am doing is this:

   Encoder  ---->  Wireless  ---->   NI9411  ---->   cRIO 9014

The thing is that I am sending the encoder information at a sampling rate of 500 us, very fast I suppose, but when I read the data in the cRIO I noticed that if the speed was fast LabView did not detect the changes in position and that created a shift in the signal, with time that shift became big enough to make it noticeable.  I put the input filter of the digital input module NI9411 at 256us and the velocity timebase at 32768us, that seemed to fix the problem but then I noticed that I still had a shift after some time.

I can not increase the sampling rate in the wireless connection and my encoder does not have an index signal. The data transmission is right. Also I have the NI9411 in quadrature mode.

I was wondering if someone has had this kind of problem and/or if someone can help me.

Thanks.

--Luis  

[speleato]

Hello Luis,

How many counts per revolution is your encoder?  How fast is it turning when the position starts to drift?

It looks like you are missing edges and I suspect it is due to how quickly your wireless transmitter updates.  The 9211 is a 500 ns module and can easily handle a 500 us update rate when in quadrature mode.

Is it possible for you to test this without the transmitter to see if position still drifts?

Thanks,

Sebastian

[Luis_R.]

Hello,

Sebastian,

The encoder has 360 cycles per revolution and 1440 pulses per revolution.

By missing edges means that when I change direction I do not detect it until I update?

Yes, without the transmitter everything is fine.

Thanks.

--Luis

[speleato]

Hello Luis,

Essentially the signal from the encoder is two square waves that are 90 degrees out of phase.  That means that there are 4 states the encoder signal can be in.

A high, B high

A low, B high

a high, B low

A low, B low

The sequence and timing of these state transitions is what is used to determine the speed and direction of the encoder.  The problem comes if you aren't sampling fast enough to catch all of the transitions.  That's what I meant by missing edges.

With a 360 line encoder and a 2 kHz sampling rate I can see how higher rotatation rates could be a problem.  How fast is the shaft you're measuring rotating?

It makes sense then that things work without the transmitter because the module on its own samples in the Mhz range.

You said you cannot increase the transmitter sampling rate so we'll have to find other solutions.  To solve this you could consider using an encoder with fewer pulses per revolution.  You could get a similar effect by using the same encoder but using some gear reduction to get it turn slower.  There are other options as well, if you could tell me a bit more about your application maybe we can work something out.

I'm assuming that in the deployed product wireless communcation is absolutely necessary?

Thanks,

Sebastian

[Luis_R.]

Hello Sebastian,

The wireless communication is absolutely necessary so I can not omit it, the application is some kind of helicopter, I am using the encoder to read the angles pitch, roll, yaw.

Now, if my math are correct, at 2KHz and 360 cycles per second, assuming each cycle has 2 states, high and low, the max speed I can read is 2.7778 RPS, but my system is not that fast all the time, so I was wondering if there is a way to fix the shift in the signal if the system is above this speed.

Thanks.

--Luis

[speleato]

Hello Luis,

I can see how a cable is out of the question for you 🙂

Unfortunately if an edge is missed because you weren't sampling fast enough it is gone and no recovery is possible.  If you had the index we could think about using that but there is no gurantee you'd catch the index signal either and there could be cases where the direction has changed.

Are you able to use an absolute encoder or a potentiometer to read these signals?  In that case the sampling rate only has to be as fast as you want the position to update and 2kHz is more than likely plenty for that.

You can also think about putting a small computer on board the helicopter to process these signals and then transmit the actual position instead of the raw encoder signals.  Single Board RIO may be a good choice for this.

Sebastian

Message Edited by speleato on 04-24-2009 02:56 PM

[Luis_R.]

Hello,

Sebastian, I've looking for possible solutions and I think I will have to change to absolute encoders. Now, I only have the NI9411 input modlue and the cRIO9014, with the absolute encoder I will read the actual position and send it via wireless:

                          Encoder -->  Transmitter  --> Wireless --> Reciever  --> NI9411

I think I will have to reconstruct the quadrature signal, equivalent to the position on the reciever. Is there a better option to input this signal?

Thanks.

--Luis.

[speleato]

Luis,

I don't think it makes sense to reconstruct an equivalent quadrature signal.  You'd still have to send all the data from the absolute encoder to the ground, so at that point you may as well read it directly.

There are a couple of different interfaces to absolute encoders.  The ones I have seen are some variety of serial or a parallel digital interface with one line corresponding to one bit of resolution.   

So for a 12 bit encoder (4096 discrete readings per revolution) you need to send 12 digital signals to get the full resolution.  I don't know what the capabilities of your current transmitter are, but you will probably need a module with a higher channel count than the 9411 as I'm assuming you need relatively high resolution, possibly more than 12 bits.  You can use a slower module for this, the 32 channel, 7 us 9403 is still many times faster than your transmitter. 

If the channel count is getting too high and if it is ok to read your encoders less frequently you could implement some sort of multiplexer where you would send a signal to indicate the encoder you wish to read and some circuitry on board the helicopter connects the desired encoder.  Something to think about at least.

There are also many wireless serial products on the market if you want to go that route.  I've seen a few absolute encoders that are designed to work on a sort of serial network so you can read them all with a single serial port.  That, or you can add serial ports using the NI-9870.

I suggest you research absolute encoders a bit and see if there is a way you can integrate them in to your existing design without too much pain.

Thinking about your problem a bit though, I'm guessing that you have some sort of computer / auto-pilot on board the helicopter already to take care of actually flying it.  Presumably that computer is also already tracking the yaw, pitch, and roll angles, possibly even by reading the same encoders.  Would it be at all possible to send the data from the onboard computer (assuming it exists of course :)) to the cRIO on the ground.  Perhaps there is a serial interface that can be used here?

Let me know what you think,

Sebastian

[Luis_R.]

Hello,

Sebastian, thanks, there is no computer on board the helicopter, is a home-made helicopter and it is just for testing, it does not fly but it is able to move in pitch, roll and yaw. I will change the encoders but first I need to do some tests, the issue is the data transmision, the 9403 seems a good option, but looking in your post I found that there is a serial link posibility. I was researching this and made some tests and I can actually read the data via serial port in LabView. I am new using serial port and LabView but I think this one will work. 

Thanks.

--Luis

[Fernandes]

HI,

Could you recommend a differential encoder to work with UMI-7774?

Thanks