6220 card + encoder woes

[idbeu]

Hi, I'm not sure how much information to include in this post, so please ask for more should you require it.

I have a 6220 card and an encoder. Using the DAQ Assistant, I have been able to get the position of the encoder without any problems. The z-index is set to 2.07 and the encoder stays zeroed.

This works fine while I'm running the VI that calls the DAQ Assistant. I called this VI "Encoder Position". But when another VI calls Encoder Position to ask where it is, major problems occur. One VI seems to make Encoder Position reset to the z-index value as soon as Encoder Position is called. Another VI works with Encoder Position just fine.

Second problem:
So finally I gave up and disabled the z-index. Now things are much better. I write a program called Main to call DAQ that calls Encoder Position, and it works without the weird issues described above. The problem is, when I call DAQ from Main, over and over again, the encoder gets more and more off zero. But when I run DAQ over and over without calling it from Main, it stays zeroed! The only thing Main is doing is calling DAQ. I can't understand why it gets more and more off zero.

Sometimes the encoder jumps in value... as if it wasn't paying attention, and then suddenly realized where it was (except it's wrong). This behavior is not consistent, and I believe this is what creates the off zero. I find it interesting that it doesn't skip while DAQ is run manually, but does skip when DAQ is called from Main.

Any clue what is going on?

Thanks,
-James

[idbeu]

Wait! I'm finding that running the DAQ VI over and over causes the encoder to jump and become off zeroed also. It doesn't just happen when the DAQ VI is called from the Main VI.

Sorry for the mistake. I'm glad I can reduce some of the inconsistencies though.

[Otis]

Hi idbeu,

You mentioned that you were running into a lot of problems dealing with your quadrature encoder.  You also talked about a lot of different VIs such as a DAQ VI and a Main VI.  Unfortunately I am unsure of what all those VIs are doing.

What I recommend you doing is to take a look at some of the shipping examples that we have for encoders.  If you open up LabVIEW and go to Help > Find Examples it will open the NI Example Finder.  Once there go to the search tab and search for 'encoder'.  This should then populate a list and give you at least 4 different DAQmx examples on how to do encoder measurements. 

Try to see if these examples help to eliminate the problem.  If so, then try building your code up from the appropriate examples or try implementing the example code into your application.

Regards,

[idbeu]

Thanks for the response.

Unfortunately, that didn't work. I rewrote the Encoder Position vi the same way one of the examples was written, but I still got the same inconsistent jerky behavior.

I should probably mention that I'm using an Intel Celeron 700 mhz with 128 MB of ram and Windows 2000. This is not a speed demon. Could that be a cause of the encoder loosing counts? I thought everything was monitored from the 6220 card but maybe I'm mistaken?

If this is the problem, should I add more RAM or does it require a faster CPU?

[Laura F.]

Hello idbeu,

Generally an encoder measurement is accomplished using the counters.  How you set this up will determine if you are using software timing to do the measurements, in which case lost counts could be due to a slow PC.  Can you post your code so we can take a look at it?

Thanks!

Laura

[idbeu]

Sure, here are the two VI's I use to get encoder readings.

"encode setup" creates the task name
"encode value" takes the value of the encoder and translates it to a value between 0 and 2pi.

I use "encode setup" to generate the task early in my program (during initalization), and "encode value" whenever I need to know where the encoder is.

Thanks! I hope this helps.
-James

[idbeu]

...and here's the second file...

[idbeu]

Update:
I am almost certain the problem is the slow computer. When I run the program and move windows and open/close files and generally tax the computer, the encoder skips wildly. If I run it and leave it alone, it skips small amounts, if at all.

Since my VI's don't (?) have any kind of timing loops in them, I'm confused as to why the computer is not keeping count. It's important to note that the encoder skips FORWARD, not backward as it would if it was lagging. It's almost like it knows it lagged, and tried to make up for it by adding extra counts.

Taxing the computer's resources CLEARLY increases the frequency and severity of the encoder skip. Simply using a faster computer isn't much of a solution, since this software is going to replace multiple systems. I don't want to have to replace all the computers.

Since the NI DAQ cards have not been purchased for the other systems, maybe we could just buy a different card? If the 6220 relies on the computer's resources to keep track of encoder counts, is there a different board that is self-reliant (but still has all the major features of the 6220)?

Thanks!

[Laura F.]

Hello idbeu,

I looked at the VIs that you posted and you are experiencing these glitches in your measurements because your acquisition is completely software time.  Therefore, windows can interupt the process whenever it needs to causing your measurements to be incorrect.  I would suggest setting up a buffered measurement, so that the hardware takes care of the timing.  There are examples in the example finder that do this, but they require an external sample clock.  You can use a second counter to provide this clock, as is suggested in the documentation of the examples.  Particularly, I would look at Meas Angular Position - Buffered - Cont - Ext Clk.vi or Meas Angular Position - Buffered - Finite - Ext Clk.vi.  In the documentation it suggests using another example for the external reference signal.  Using this method, you will need both counters on your PCI-6220 to do the one measurement.   If you require more counters, you could look at the PCI-6602 which has 8 counters. 

Thanks,

Laura

[idbeu]

Another update:
I am using a digitalIO port on the card as well. If I stop using that port, the encoder keeps track of itself. Surely I can use both... Any ideas to why it looses track only when I use the IO ports at the same time?