6602 as X4 encoder/external clock

[Kevin_Price]

Good news -- you probably don't need hardware-timed sampling or synchronization at all.  If you change your encoder tasks by removing the call to "DAQmx Timing.vi", then you can choose to perform software sampling with "DAQmx Read" in your main loop at any rate you like.  Try removing that call and see if you don't get better results.  The board's internal count registers will update at the 400 kHz rate you need, and your DAQmx Read calls will simply query an instantaneous snapshot of those count values.

I see that your linear encoder has pretty low speed limits.  If any part of the motion exceeds those limits, you might expect the sensor to fail to produce the right # of pulses.

I'm not sure I've got a good picture of what you're doing that gives you the negative slope and the impossible 2mm offset.  Does the LV program run continuously during all the take outs / put backs?

-Kevin P.

[josef_slg]

Hello Kevin,
It doesn't work better. I mean, I had the VI like this before, and I tested it again, but it doesn't work. Yes, the VI is running all the time. The bad thing is, it works perfectly with an independent hardware and software set, means with another DAQ card and software, both not NI.  But we hav eto use NI and LabView. Anyway, I attach test results of the repeatability test to show you what I mean. Also find attched the VI, I am using. Maybe I have a configuration wrong, or do I have  to configure the pic6602 card itself in Max or so ?

Thanks in advance again.

[Kevin_Price]

I had a chance to briefly look over your vi.  It's pretty self-explanatory, and I didn't spot anything of particular concern.  I did note the use of digital filtering for the input lines on the magnetic linear encoder task.  Odds are, that means you discovered that its signals weren't "clean" and you may find that tweaking the filtering parameters or adding some interface circuitry will still be needed.

I couldn't interpret the test data since I don't know your system and your test method / procedure.  But I can see that you have slight trends in data that you would ideally want to repeat exactly.

Are the optical encoders putting out single-ended TTL quadrature?  Or do they use a differential line driver output, or something like open-collector which requires a pull-up resistor at your end?

How does the other non-LabVIEW system operate?  How repeatable are its results?  Could it be averaging lots of readings instead of taking single samples?  That kind of thing would make the answers it produces much more stable...

-Kevin P.

[josef_slg]

Hey KEVIN,
ok, find attached the data sheet of the rotary encoder. It uses differential line drivers. The one we are using, do have the same  basic structure like the one on the data sheet, just with another resolution. The number of the encoder is: R137C03600Q5L05G18SP03MN.
It seems to be that I am loosing counts, when I turn my device in six degrees of freedom at the same time, so that the DAQ-card has to handle six encoders at the same time. ?!? Does this cause trobule  ? It shouldn't !
The independent system uses also a single reading at a time, so we can assume to 100%, that this system is correct. Their repeatability is about +/- 0.02 degrees/ mm's, which is correct!
Does it make a difference, that I am using an external power supply for my encoders. The PCI6602 can't supply enough voltage for the six encoders !?!  (just 4.2V, but need exactly 5V +/- 5%) And what about grounding issues resulting of that ???

Even in MAX, I do not get the corrrect readings, if I just do it with ticks. I am missing some.
Thanks again for your help.

[MickeyD]

Hi Josef,

The use of external power for your controllers is not going to be a problem at all.  If I understand correctly, then you can open a test panel in MAX and setting up the counter input for 1 channel you can then watch that channel miss ticks?  You have it configured just like the attached jpg shows, with the appropriate PFI line I assume. 

Looking at your output waveform Do you miss counts on all the channels.  You should be able to set that up in MAX and then see the count exactly duplicated.  I think we need to isolate down the problem, so I just want to verify that looking at the input from Channel A on your encoder only that you can not accurately get all the ticks in MAX?  If you can then it is a matter of how your counters are set up in the full application.  Let me know and we will continue to work on getting your application running.

Have a great day,

Michael D
Applications Engineering
National Instruments

Message Edited by MickeyD on 05-30-2007 07:19 AM

[Kevin_Price]

Sorry so late responding again -- I *thought* a response but mis-remembered that I had also *written* it.

I think that a very likely source of the problem is that you have several encoders generating somewhat independent differential line driver outputs while your counter board is looking for single-ended TTL.  I'll bet your other measurement system has a board that's capable of interfacing directly to the encoder's differential outputs.

I'm not an electronics wiz, but I've seen missed-count problems when multiple line driver outputs were tied together to a data acq board's common digital ground.  You'll want to put a differential line receiver between the encoder and the data acq board to convert to TTL.

Another quick troubleshooting idea: disconnect all but 1 of the encoders and see if you get the right # of counts from that 1.  It's pretty common that differential outputs *from a single device* can be connected directly to a counter board and produce correct measurements.  Not guaranteed, but chances of success are higher than when you have many devices.

-Kevin P.