Re : count direction in buffered mode

[koala]

Hello,

I’m trying to read the position of a 5000 points quadrature encoder (Hengstler RI58-O/05000 AS.41RB). I use the NI PCI 6036E, traditional NI-DAQ (because I work on a complex application, written with traditional NI-DAQ), and LabVIEW 7.0.

A-signal rising edges are counted with counter 0, and /A rising edges (= A falling edges) with counter 1. The two results are added to obtain the X2 mode. The count direction is detected by connecting B and /B on the Up/Down pins (P0.6 and P0.7). My first tests, with simple events counting, were OK.

I had to change to buffered events counting in order to synchronise with AI acquisitions, using "AI scan start". However, the count direction is no more detected: whatever the direction the encoder is turned, the counter is decremented. How to detect direction with buffered counting?

I join the VI I wrote. “14783_Démarre compteurs.vi” starts the counters, and is called at the beginning of the application. “14783_Lit compteurs.vi” is used to read the counters, and is called after AI acquisitions. “14783_Arrêt compteurs.vi” stops the counters, and is called when the application is stopped.

Regards,

Maxime Champod

Message Edité par koala le 07-16-2008 07:08 AM

[koala]

I just achieved to test separately my buffered counting functions, which was not trivial. It appears that the direction is correct. Thus, the problem is linked with the rest of the application.
The other acquisition is performed by "AI Waveform Scan (scaled array)". Does anyone knows if the count direction problem can be caused by such simultaneous acquisition ?

[Kevin_Price]

Can't look at your code from here, but have a few possible educated-guess thoughts.

First, clever idea to use both the (A,B) and (/A,/B ) pairs!  I don't think I've seen that before.  It even appears to help with the dithering that can occur during vibration across one of the transitions, though I'm not sure I've analyzed that completely.

Anyway, here's my guess.  Your technique depends on summing the count value from 2 independent tasks.  In simple event counting mode, you read them in quick succession.  Though your reads are not truly sync'ed in time, they are close enough that you don't observe any obvious miscount errors.  Also, any such miscounts wouldn't tend to accumulate.

As you switch to buffered counting, I'm guessing your code somehow doesn't carefully maintain sync on the samples you read from the tasks to produce your X2 sum.  If the encoder is in motion when the app starts, you could get an initial offset error in your sum result.  The way you read samples from their buffers could also lead to errors in your sums. 

Your specific symptom -- counts always decrementing, but only in buffered mode -- is puzzling though.  I wouldn't expect that kind of symptom.  The buffered tasks don't generally act differently than unbuffered tasks.  The only other thought is wondering if some other part of your code does things with the DIO.  The B and /B signals must be wired into digital lines if I remember correctly.  Isn't it either DIO 5 and 6 or else 6 and 7?  Are you doing any DIO? 

-Kevin P.

[koala]

I firstly thought that no DIO were used, because of the plans of the test bench, but the real wiring does not match. In MAX, there is only one DIO NI-DAQ virtual channel, and it uses DIO 0. I don't think DIO6 and DIO7 were used because they were not wired.

The use of /A and /B was not intended to reduce dithering. I think this effectively could be used for that (by taking the smallest value?), but the reason was I had some problems with falling edges.

Maybe my problem comes from the (tricky?) way I route "AI scan start". During the configuration of the AI, I route this signal to PFI7, and in the counter configuration, I use PFI7 as the gate, for the two counters (PFI7 is not wired by its connector). I don't know if there is a better way to do that.

Message Edité par koala le 07-16-2008 10:41 AM

[Kevin_Price]

I don't expect that your "AI Scan Start" routing would be a culprit, unless it's an indirect issue related to a conflict between PFI7 and the DIO port programming.  To test it, you could try routing via RTSI instead.  That was one of my common tricks under traditional DAQ -- one task would route a timing signal up to RTSI, another task would use it for its own task.  Even when routing timing signals between tasks on the same board, it was handy to avoid the need to hard-wire to a screw terminal.  I found that RTSI provided more options than the PFI pins.

Don't know if the DIO is really the problem, but I think that's what you should track down.  I recall that under traditional NI-DAQ, many of the easy IO examples would configure the DIO port for either all input or all output.  If DIO 0 is configured to be used as output, and the config code took the easy way out and set up the whole *port* for output, then your directions pins DIO6 and DIO7 won't respond to your /A and /B inputs any more. 

Come to think of it, some of the older DAQ boards *require* DIO ports to be either all-in or else all-out.  You should check this out for your board.

Finally, you've probably done this, but be sure that you test the simple event counting and buffered event counting methods with *everything else* the same.  Since I'm suspicious of an interaction with DIO programming, be sure any such stuff is operating the same way as you change the counting method.

-Kevin P.

[koala]

You were right : DIO 0 was the source of the problem. It is set to false with "Write to Digital Line.vi". This VI seems to configure the entire port for output. When I change line directions with "DIO Port Config.vi", the counter direction is OK : my problem is solved.
Thanks for your helpful answers.

Maxime Champod