Multiple counter input using NI 6602

I am using NI-DAQmx to write a VI that will read 10 pwm measurements using 10 counters on 2 NI 6602 PCI interfaces. It is my understanding that I must create a task for each respective counter. I have attempted to implement a for loop to accomplish this, as shown in attached VI draft. As it stands the VI will not write any data to file. I suspect there are multiple errors in the VI. I would ask if anyone could take a look at the attached VI and perhaps provide some insight?
Saul LaCoursiere
Attachments:
MelexisMODdraft2.vi ‏41 KB

Hi Saul,
It looks like you had a subVI "Create Header" which needs to be included to run, so I deleted all of the report related code. The Counter portion ran fine. If you can't get the report generation portion to work, you may want to simplify your code (for example start with a single counter task) and build up from there.
Please repost if you have further questions.
Thanks,
Luke
Applications Engineer
National Instruments

Similar Messages

Counter input using PFI0

Hi everyone,
I am trying to make frequency measurement using PFI0 or PFI1 in the cDAQ-9188 and DAQmx
is it possible to do so ???
can i have guide for that ?
thanks

Hi Tareq-
You have specified your frequency input pin and its sample clock to be the same signal. The -200284 error is a timeout, associated with the fact that you do not have multiple periods of your input signal for each sample clock cycle (since they are the same signal).
Are you actually trying to acquire a so-called buffered frequency measurement (buffering away measurement values on each tick of an external clock)? My guess is that you just want to read a single frequency value per loop iteration judging by your use of the single sample DAQmx Read instance. In that case, you can remove the DAQmx Timing VI from your task creation for the frequency measurement task.
Edit: I should also mention that if you *do* plan to use an external clock, you should make sure that its rate and your 'samples to read' value of the DAQmx Read VI match in such a way that a read of that many samples can actually occur within the allotted DAQmx Read timeout. You should probably also use a multi-sample instance of DAQmx Read in that case, too.
Tom W
National Instruments

Usb 6009 multiple analog inputs

I am currently attempting to sample two different analog inputs at different sampling rates using a USB 6009. I keep getting the 'resource reserved' error and am wondering if this is not possible using this DAQ. Questions:
1. Does creating two analog input channels on the device cause this error?
2. Is it possible to sample at different rates on channels created in the same task? (i am trying to 'slow down' the second analog input to display switch points to a customer)
3. Running multiple analog inputs using independent timing would be better achieved by switching to a higher end DAQ? If so which would you recommend?
I have attached my vi. Thank you in advance for your help.
I surf therefore I am....
Attachments:
demo_nolvl.vi ‏27 KB

The DAQ boards only have 1 timing clock for the analog inputs/outputs. So you can only have 1 sample rate on a given card. I would recommend just sampling at the highest of the desired rates in a single task.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Route multiple 6602 counter inputs to one counter output...

Hi!
I´d like to route 4 different ttl signals, that are read by 4 different counter inputs to one single output channel (e.g. the output of one of the counters used) using pulse train generation with a divider of 4. Note that only one of the four inputs is active at the same time, to prevent overlay.
How can I do that with Traditional-DAQ?
Setup would look like this on the SCB-68
TTL1 ----o in0 (ct0)----o out0 TTL(1..4)/4 [Hz]
|
TTL2 ----o in1 -- (output of ct2 is redirected ro ct1)
|
TTL3 ----o in2 --
|
TTL4 ----o in3 (ct3)--
May it be better to just output each counter input signal at it´s own output and connect these outputs to one free I/O-pin hardwired?
Best regards
Zorniki

In the end I configured a counter for Pulse Train generation and opted to change the duty cycle and frequency via 'DAQmxWriteCtrFreqScalar" (i.e. Pulse Width Modulation)
I registered a callback for the 'DAQmx_Val_CounterOutputEvent' and then changed the dutycycle and frequency in that callback.
Unfortunately, I kept getting "The pulse generation with previous property settings must complete a
full cycle before the property can be updated." error messages and, opon further reading, managed to find a doc where National Instruments suggest adding a 'Wait(period)' before executing the 'DAQmxWriteCtrFreqScalar' call.
The problem with this solution is that it one has to wait a minimum of 2 Periods before the Pulse Train can be modified which is not acceptable for our work.
So is there an alternative solution which allows us to change the Pulse Train after only 1 Period ? Is there an event we can trap which allows us alter the Pulse Train after every period ? I'm sure PWM must be possible on Daq cards (PCI-6602 or PCI-6281 or PCI-6259)?
Cheers, Shaun.

PCI-6602 - What to do with unused counter inputs?

I've got an application where I need to track the position on two quadrature encoders. I've developed my application with VB6 however, I've been using a sample LabView program called "Meas-Ang-Pos-Buff.vi" for testing purposes. (I got the example off the NI discussion board). I'm seeing some very odd results that I can't explain.
For testing purposes, I've got one encoder tied to multiple channels on my 6602. I have the same 'A' signal and the same 'B' signal (from the one encoder) jumpered to multiple encoder channels. I'm using a onboard pulse generator to generate the latch pulse (connected to the Index/Z of each counter) to ensure there is no skew in my count values. I'm using an external servo to turn the encoder at a rate equal to my application speed.
The unexplanable results I'm seeing are below:
If I'm monitoring counters 0, 1 and 2, I see the following.
1) If I have counters 0,1,2 and 3 inputs connected to the same 'A' & 'B' from my encoder, the counts on all 4 channels (0,1,2,3) track perfectly.
2) If I disconnect counter 3 and only have counters 0,1, and 2 connected to the encoder, then counter 0 and 2 track perfectly, but counter 1 looses pulses (only when traveling in one direction, the other direction seems to be fine)
3) If I connect counter 3 to ground and have counters 0,1, and 2 connected to the encoder, I get the same result - bad.
4) If I connect EVERY counter input (2,3,4,5,6) to ground and only monitor counters 0 and 1, I still get bad results.
In summary, I ONLY am able to see the same number of counts while monitoring 3 channels IF 7 of the 8 counters are connected together (the 8th being my latch).
This happened to me in the past on a previous setup that did the same thing, but I was able to fix it by moving from counter 1 to counter 4. At that time, I chalked it up to a bad counter 1, but I think there is a bigger issue since it is happening again.
Please any advice would be appreciated.

Thanks for the response. This one has really got me confused and any help is greatly appreciated.
To answer your questions, no I have not modified the sample program and I'm using NI DAQ v8.5.
I've decided to break the problem down to see if I could find a pattern, but no such luck. Here is the testing that I've done.
I'm making the following connections while using the sample program I mentioned earlier:
Counter 0...............PFI_39 (term 02) - Channel_A(0).................PFI_37 (term 40) - Channel_B(0)
Counter 1...............PFI_35 (term 07) - Channel_A(1).................PFI_33 (term 06) - Channel_B(1)
Counter 2...............PFI_31 (term 34) - Channel_A(2).................PFI_29 (term 66) - Channel_B(2)
Counter 3...............PFI_27 (term 31) - Channel_A(3).................PFI_25 (term 63) - Channel_B(3)
Note: I connect the "Z" channel for gating purposes in my VB application, but this isn't required in the LabView sample program since the gating appears to be done internally.
My testing results:
1. If I jumper my one encoder to channels 0,1,2, & 3 at the same time, everything works great. Each channel reports the same number of counts regardless of whether I'm turning the encoder in the positive or negative direction.
2. If I disconnect channel 3 and only have 0,1 & 2 connected, then 0 & 2 track perfectly, but channel 1 looses counts in the negative direction.
3. If I only connect channels 0 & 1, then channel 0 counts perfectly in both the pos and neg direction, but channel 1 looses counts in the negative direction.
4. If I connect any channel by itself (0,1,2 or 3), each one counts perfectly.
5. If I connect channels 0 & 4, everything seems to be fine.
Like I said in my previous e-mail, if this hadn't already happened to me in a previous application, then I would chalk it up to a bad board. If I didn't get good results on each individual channel then I would chalk it up to a bad encoder pulse train. However, it definitely seems to have something to do with connecting multiple counters at the same time in a Motion Encoder Application. I have read the 6602 User Manual backwards and forwards looking for a nugget of explanation, but have found none. There was a section entitled "Counter Input Selections" on page 4-12 (table 4-2) that might offer some explanation, but neither me or my colleagues could understand what was being described. Any help deciphering that would be appreciated.
As of now, I'm going to proceed with my application, using channels 0 &4 (just as I've done in the past), however I don't feel comfortable not having an explanation for the 6602's behavior. Any insight would be greatly appreciated.

How do I setup multiple users to use one source but manage playlists separately? For example, play counts are specific to each user.

How do I setup multiple users to use one source but manage playlists separately? For example, play counts are specific to each user.

Hi,
Thank you for posting in Windows Server Forum.
Here adding to the words of “Tim”, a forwarder is a DNS server on a network used to forward DNS queries for external DNS names to DNS servers outside of that network. You can also forward queries according to specific domain names using conditional forwarders.
A DNS server on a network is designated as a forwarder by having the other DNS servers in the network forward the queries they cannot resolve locally to that DNS server. You can refer information regarding forwarders and how to configure from beneath link.
Understanding forwarders
http://technet.microsoft.com/en-us/library/cc782142(v=ws.10).aspx
Configure a DNS Server to Use Forwarders
http://technet.microsoft.com/en-us/library/cc754941.aspx
Hope it helps!
Regards.

Synchronizing two counter frequency inputs with multiple analog inputs

Hello all,
I'm fairly new to LabVIEW and I'm trying to collect data from multiple sources with synchronized timing on the acquisition but I'm having trouble figuring it out. My problem is that I've got two counter frequency inputs, one optical tachometer reading one pulse per revolution, and a max machinery flow meter with a k factor of 12000. I can't seem to figure out how to sync the timing with my multiple analog inputs. I've been attempting to get the tachometer to sync with the analog inputs first by following the example linked here. (https://decibel.ni.com/content/docs/DOC-10785) So far each time I run it I either get a timeout error on the DAQmx read or a "Multiple sample clock pulses were detected" error (see attached image). It seems if I slow the sampling rate way down to say 10 hz and ensure that the tachometer signal is over 800-1000 RPM (13-17 Hz) before starting the VI then the program will run without errors until the RPM drops below that threshold then the "Multiple sample clock pulses" error occurs. The code is attached below.
Does anyone know of a more effective way of syncing counter frequency inputs with analog inputs? I'd like to have a VI that can show 0 RPM (and eventually 0 flow as well, but I think I need to figure out the timing of one counter before I add another as it seems I can't have two counters in the same task). Any help on this would be greatly appreciated.
LabVIEW version 13.0
cDAQ-9178 Chassis with NI 9401 for the two counter inputs and NI 9205 for the analog inputs.
Thanks!
Richard
Solved!
Go to Solution.
Attachments:
SimpleDAQ.vi ‏44 KB
LV_Error.JPG ‏31 KB

Maybe third times the charm?
So I've finally got a good handle on why the VI is having problems at low RPM though I'm somewhat embarassed how long it took me to do that
Because I have the counter time synced to my Analog input task if it doesn't see at least two pulses between the two clock pulses set by the analog input task I get the -201314 "Multiple sample clock pulses" error. This seems fine at first as it just sets a minimum RPM that I can measure and it's well below the area I'm interested in so no problems there. I tried a simple error handler that would clear the error when it happend assuming the loop would keep iterating until the RPM went above that minimum at which point I would get a signal again. This is not the case, the read function just continues to spit out the -201314 error even after the RPM is back in the readable range. So then I tried adding two case structures so that when the error occured it would stop the task, clear the error, and then start the task again on the next loop iteration (Code Attached). This also doesn't work as the error shows up again on the stop task and then AGAIN on the start task on the next loop iteration. It seems this error is not actually being cleared and once it happens it stays with the task regardless of what the error cluster is carrying.
Anyone have any ideas? The only solution I can think of is to just clear all tasks and recreate them each loop iteration until the RPM is readable again but that strikes me as a horribly clunky solution.
Richard
Attachments:
SimpleDAQ_1_Start Stop.vi ‏48 KB

Counter using PCI-6602 for multi output

Hi guys,
currently I tried to control a linearmotor using PCI-6052E and PCI-6602.
The questions is, how to use PCI-6602 to be a counter which will be converted to several output (multioutput):
(1) converted to position >> 1count = ...[mm] --> position measurement
(2) converted to voltage >> 1count = ...[mV] or [V] --> voltage measurement
(3) converted to current >> 1count = ...[mA] or [A] --> current measurement
(4) converted to velocity >> 1count = ...[mm/s] --> velocity measurement
(5) converted to acceleration >> 1count = ...[mm/s^2] --> acceleration measurement
(6) converted to force >> 1count = ...[N] or [kg.mm/s^2] --> force/load measurement
(7) converted to frequency >> 1count=...[Hz] --> frequency measurement
(i) Please assist me how to connect the driver's encoder (Ch. A A/ B B/ Z Z/) with PCI-6602, so I can get all informations above (7 measurements). What/which port of PCI-6602 connect to where from the driver.
(ii) Please assist me how to connect the feedback signal to the PC. What/which port of PCI-6602 connect to PC.
(iii) How to test those 7 measurements above using Measuremant and Automation Explorer (MAX) ver.4.4.1?
Thank you for your kindly help and assistance.
Best wishes,
hendro

Dear Jochen,
(1) Principally, I'd like to use PCI-6602 to be a motion encoder also be a counter (Is it possible? Due to the manual, it is possible). I expect to have all information, such as position, time, velocity, etc. from that motion encoder (or at least the position and time). It is also expected of using PCI-6602 to do all measurements that I mentioned before . My meaning is, after having a signal from the counter, that 'count' will be converted to desire units under other programs. So, in this case, PCI-6602 is only used to get the 'count'.
Simplified, the voltage command will send to the system (linear motor) through PCI-6052E (-10V to 10V). The actual position or other actual information will be catched (read) by using PCI-6602 (as a motion encoder, also as a counter). Then, this actual position will be used as a feedback, that will be compared to desired position.
Is that also possible to use PCI-6602 be a motion controller + a counter + a frequency measurement in a same time parallely?
I don't decide yet (I don't know) which acquisition rate will be needed/required, higher is better.
(2) I'd like to apply an adaptive robust controller (yes, it is a closed loop system) under matlab with their feature called Real-Time-Workshop instead of using LV.
(3) Power drive for the linear system will be driven by AC servo drive.
Thanks for your help before,
Warmly regards,
hendro

First time scheduling using IP30 for Multiple Counter plan

Hi,
I created a multiple counter plan with Cycle set as 6months/ 300 Operations.
I intend to start the job early and updated the Planned Counter date as 1st Sep 2014.I maintained Lead Float as 10 days.
When I run IP10, call is generated successfully. But when I execute IP30, no call is generated.
We have not activated enhanced functionality of Multiple Counter plans.
I checked all the parameters and everything seemd to be fine. In IP30, I checked the check boxes - Rescheduling & Immediate start of all.
In the field, Interval for Call Objects, I ran with blank value, 30 days value. But in both the cases, call is not generated.
I want to generate calls using IP30 only as there are lot of multiple counter plans. Can anybody suggest a solution to this issue?

Hello
As you intended to use cycle set functionality please activate enhanced functionality of Multiple Counter plans
Br
Rakesh

Counting photomultplier TTLs per ms using the 6602

Hello all,
I have a question that seems related to Paul's (falkpl) (Or that he may know the answer to =)
http://forums.ni.com/ni/board/message?board.id=40&message.id=1883
I am trying to use the 6602 to make a histogram of continuous events in bins of 1ms.
As the subject of the post indicates, the events are TTL pulses from a photomultiplier tube. (variable frequency)
A key requirement would be to not miss any TTLs in between counts.
I've seen the timer examples and have picked up a lot from reading related posts like Pauls.
I am wondering if anyone knows the most accurate/precise way to implement this counting "setup"?
- Do I need an external gate to set the counter or is there a way I can use the 6602 to set 1ms counting bins?
- How do I ensure that the 1ms counting bins are as contigous as possible?
- I will probably need to change the timebase of counting so that it is not to fast (i.e. not counting noise) but is fast enough to satisfy the Nyquist criteria for these pulses. I am assuming this is easy.
I'm not sure if I need to use an internal or external gate to specify the beginnings and ends of the 1ms bins I'm counting with. I can also envision that I might instruct a counter to count for 1ms repeatedly, taking time only to read the counter value before starting again? I also realize that this is a frequency analysis of sorts, but I want to make sure I don't miss any pulses in between counts.
Somehow, I get the feeling this is a trivial question, as I would expect that this type of "frequency analysis" is used quite frequently.
Any ideas?
Thanks in advance,
Max

Max 90,
Sean's suggestion about buffered edge counting should work well and will be particularly handy if you want to know "at a glance" the cumulative total # of TTL pulses that have come in. You can find the pulses per 1 msec bin by doing a simple finite difference. Everything will be hw-timed, and you won't miss any pulses between bins.
Another possibility is to do buffered period measurement with the DAQmx units set to "Ticks." This would directly store the # of pulses during each 1 msec bin time.
Either way, you'll probably need to set the "Duplicate Count Prevention" property (buried down deep in the DAQmx Channel property node). I think the right setting is "True", but you can always try both True and False to see which works properly. One setting will actually store 0 values during 1 msec bins with no incoming TTL pulses, the other setting will simply ignore such intervals and only store a value during the intervals where there are 1+ pulses.
Finally a comment about your mention of "Nyquist criteria" in your original post. For most counter tasks, you wouldn't generally consider Nyquist criteria the way you would in an analog task. Consider your app: your 1 msec bins are the same as sampling at 1 kHz. However, it's apparent that you expect several TTL pulses to occur within some of those 1 msec bin times. So your signal can come in as fast as (perhaps) 5 kHz or more. If you automatically think of Nyquist, you might too quickly decide to sample at >10 kHz, which is both unnecessary and actually unhelpful for your app.
-Kevin P.

Strange counter reading on NI 6602 using triggered acquisition

I'm using the 6602 connected to a Pulse generator going at about 100Hz. This goes to PFI 35.
An APD (photon counter) is connected to PFI 39.
I want synchronous acquisition at PFI39, after the falling edge of the pulse on PFI 35. I also count PFI 35 to see the falling edge.
This needs to happen at a rate of 100kHz. Note that I've coded all of this and it's working and it is synchronous but there is one problem.
Every 100th acquisition or so I get a strange spike. This spike can happen at any point and even at low counts so it does not seem to be an overflow problem.
It can also happen at low acquisition rates so there has to be something wrong with my code.
I have attached the normal response and the strange response. The waveform graph shows the output of the acuisition at PFI39 (photon counter).
Any ideas what could be causing this?
I also attach the VI. Sorry it is a bit messy.
Note that the problem is not specific to looping, it can happen at the first iteration.
It seems to happen more often if the acuisition duration is low (say 10kHz sampling, 10 samples, rather than 10kHz sampling nad 10ksamples).
Attachments:
counterVI_triggered_single_shot_sampling_version2.vi ‏77 KB
normal_response.jpg ‏456 KB
problem_response.jpg ‏454 KB

Hello
I guess you could do that!
I would like to see if I could come up with a better solution but I am struggling to understand your code. I see that you are acquiring on 2 channels synchronously, both triggered by you 100Hz source. However, I do not understand how you are detecting the falling edge and using this as a trigger?
This aside, from your code, it seems that you are effectively doing a finite acquisition because you stop the tasks immediately after you read the first set of samples. You will probably avoid the buffer overflow by changing the task type to 'finite samples'. The program will then effectively be performing repeated finite acquisitions.
I hope this helps.
Nick C.
Cardiff University

Can a NIDAQmx task contain two counter inputs?

Hi I am using PXI-6602 to measure angular position with three digital enoders. Currently I am creating three different task each with one ctr input and then synchronizing them together. Is it possible to create just one task having all three ctr inputs such that there is no need of synchronization etc.
Vicku.

Hi vicku,
I understand that you cannot have multiple counters in one task; in order to use multiple counters, you must create a separate task for each counter. Are you having problems trying to synchronize these tasks? If so, please post back the details so we can try to help.
Ana P
National Instruments
Applications Engineer

Counter input problem

hi, i'm using a counter input to count the falling edges of a digital pulse. I need to convert this into a time based measurement (period/frequency), but am having a litle trouble doing this. If any one can help? i'd prefer it if it were as simple as possible, i.e. no fancy programming as I'm new to LabVIEW and would like to fully understand what i'm looking at!
Many thanks in advance!
tom

Hi
What version of LabVIEW are you using? If you're programming with version 7.0 or higher you can configure your counter for period or frequency measurements quite easily using the DAQ Assistant.
Just drop down the DAQ Assistant Express VI. The Wizard that opens will ask you to choose your input type. Choose Counter Input and it list options for Edge Counting, Frequency and Period Measurement. Choose the one you want then choose the counter with which to do the measurement. When you click Finish a configuration dialog box will open up for you to configure the Input Range, the Task Timing, etc. There will also be some further information in the help section along the right of the window. When you click OK the DAQ Assistant will build your code.
I've attached a Zip file with 2 labview programs to demonstrate this. (They're written in version 8). Connect DIO 0 to PFI 9 of your DAQ card (I'm using an M Series card. If you're using a different card let me know). Extract and run both files. The Digital Output VI generates an alternating high and low signal for each iteration of the loop. The Counter Frequency Measurement VI measures the frequency of this output. The frequency is determined my the Wait Until Next ms Multiple function so change the input to that to vary the frequency.
Let me know how you get on with that and if you require more info.
Good luck!
SarahB
NI | UK
Sarah
Applications Engineer | National Instruments | UK & Ireland
Attachments:
Frequency Measurements.zip ‏65 KB

Any ideas on how to use a 6602 to do frequency division?

Uisng traditional DAQ.
The 6602 user manual says it can do frequency division but I can not find an shipping example for this operation.
In the end I want to be able to use the 6602 to handle the interface to a quadrature encoder.
I want the 6602 to generate a sample pulse I can use for other DAQ work.
I would like to get one pulse for both transitions of both the A and B signals, or otherwise stated;
A pulse when
A goes high
B goes high
A goes low
B goes low
I was thinking if I could configure a counter (or group) to operate as a frequency divider and use each of the encoders as a clock signal AND just do a divide by "1" I would have what I was after.
Big Picture (incase it makes a difference)
A quadrature encoder is coupled to a resolver I am testing. I need to corelate the angular displacement with the measurement from the resolver. While the shaft of the encoder and resolver are spinning, I want the encoder to clock the analog input samples.
Thank you for reading,
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Ben,
First the executive summary: Sorry, No Can Do.
You won't be able to generate a sampling clock pulse on the transition to each of the 4 quadrature states. Here's a thread I was involved in where a similar question was asked. If you need to correlate in exactly that manner, you may want to pick up a quadrature decoder chip such as the 7084. It'll generate a "pulse" whose width is controlled by selection of an RC time constant during circuit build. I put "pulse" in quotes because it isn't truly a TTL signal due to the long transition time. I would recommend that you plan on adding a Schmitt trigger to square it up, perhaps another to re-invert it back to original polarity.
However, all that being said, you may be better off using an internal sampling clock to drive analog and encoder position acquisition anyway. On many encoders I've used, the transitions are NOT perfect 1/4 divisions of the cycle. You can sometimes see this on the spec sheets where the A to B relative phase is given as, say, 90 +/- 15 degrees. There will also be a tolerance on the phasing of A's rising and falling edges, maybe 180 +/- 10 degrees (it's often a little tighter than the A to B phasing).
In practice, I've typically found that these deviations tend to be systematic rather than random. Of the company's 1000 similar encoders, the phase stays within the range 90 +/- 15. With my 1 instance, the phase may be 84 +/-3 around a full rev of the encoder. The point is that if you generate pulses with the quadrature transitions, the samples still won't *really* be equally-spaced in position. They'll just think they are.
I'd suggest at least considering high-speed sampling with an internal clock that's shared by both tasks. Then do a little bit of curve-fitting / interpolation to the data when you need to derive more precision.
Re: frequency division. You have to select a specific edge (either rising-only or falling-only) as the active edge. Your counter will then ignore the other type of edge. Also, you'll need to specify the # of edges each for the idle and pulse states. These must each be >= 2. So you can't divide by 1 - the best* you can do is to divide by 4. (*Technically, you could sort-of divide by 2 if you configure the counter to pulse rather than toggle its output. However you can't control the pulse width, and as I recall it's fixed at 50 nanoseconds.) Write back if you'd like to see an example.
-Kevin P.

Counter Output/Counter Input PXI Signals Behaving Erratically

Question for all your LabVIEW guru's out there,
I am running a frequency loopback test using the NI PXI 6229 MIO DAQ card. I am generating a "Counter Output" pulse train signal which feeds through my device under test and then back out of my device under test and back into the PXI 6229 for a "Counter Input" frequency measurement. Both the "Counter Output" and the "Counter Input" are assigned different PFI lines using DAQmx in LabVIEW.
I have 4 lines to test on my DUT. All four lines run this same frequency measurement but with different PFI lines on the PXI 6229. Each line is test independently.
This is my setup for the 4 lines:
Path 1: P2.0 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.1 (Counter Input - Frequency Measurement)
Path 2: P2.2 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.3 (Counter Input - Frequency Measurement)
Path 3: P2.4 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.5 (Counter Input - Frequency Measurement)
Path 4: P2.6 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.7 (Counter Input - Frequency Measurement)
where:
P2.0 = PFI8
P2.1 = PFI9
P2.2 = PFI10
P2.3 = PFI11
P2.4 = PFI12
P2.5 = PFI13
P2.6 = PFI14
P2.7 = PFI15
I have a LabVIEW VI which generates the "Counter Output" and reads the "Counter Input" frequency. I am seeing weird behavior from the PXI 6229 card. I can test "Path 1" and "Path 2" and the frequency I read is what I generated. No issue there. However, when I test "Path 3" and "Path 4" the frequency measurement is erratic. The readings are two different frequencies repeated over and over again and none of those frequencies are the expected frequency which was generated out of the "Counter Output." If I reset the card, and start by testing "Path 3" and "Path 4" the frequency readings are correct and the erratic behavior is gone. However, when I try to then test "Path 2" and "Path 1" now those lines have the erratic frequency issue. I can continue resetting the card and see same issue. The PFI lines that I test first will always pass.
To summarize:
Steps Taken:
1. Test Path 1 = SUCCESS
2. Test Path 2 = SUCCESS
3. Test Path 3 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
4. Test Path 4 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
5. Reset the PXI 6229 Card
6. Test Path 3 = SUCCESS
7. Test Path 4 = SUCCESS
8. Test Path 3 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
9. Test Path 4 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
I am wondering if Port 2 (P2.0-P2.7) on the 6229 card has certain dependecies and this is why I am seeing issues. I am trying to get around this issue so that I don't have to always reset the card.
Are P2.0-P2.3 (PFI8-PFI11) and P2.4-P2.7 (PFI12-PFI15) treated differently or require different setup? How do I resolve this issue?
Thanks so much!

I have a theory...
The DAQ card follows a policy called "lazy uncommit" wherein the terminal used for the output will continue to be connected to the counter even after the task has completed (until the terminal is needed for something else). So as you run more tests, the counter output will end up driving more lines. This behavior should be easy enough to confirm.
As the DAQ card drives more lines, I'd imagine this affects the actual signal. You could scope it to check, but it sounds like either the rise/fall times are becoming longer or some extra noise is being introduced on the line.
The readings are two different frequencies repeated over and over again and none of those frequencies are the expected frequency which was generated out of the "Counter Output."
This implies you are picking up an extra edge during transitions--this isn't too uncommon if the signal is noisy since there is no built-in hysteresis on the DAQ card. I would expect the measured frequencies to have periods that sum to either the full period or the semi-period of your actual signal (depending on how many duplicate edges are detected).
Suggestions are as follows:
To stop the DAQ card from driving multiple PFI lines, it would probably be easiest to just programmatically reset the device in between your tests (using DAQmx Reset Device). If you can't reset the device (e.g. because you are running some other task that can't be interrupted) then you can instead configure a dummy task that uses the PFI line in question as an input.
To stop the DAQ card from picking up multiple edges during transitions, you should configure a digital filter on the input terminals. If you reset the device it sounds like this might not be necessary... it's up to you if you want to configure this or not.
Best Regards,
John Passiak

Multiple counter input using NI 6602

Similar Messages

Maybe you are looking for