Counter Output as Sample Clock of Digital Signals

I have a situation where I need to use a hardware counter as sample clock of digital output signals.
How do you specify the "Counter Internal Output" signal as a sample clock of digital output?
I want to do something like this:
// Create counter task
  CNiDAQmxTask m_Task(_T("ATask"));
  m_Task.COChannels.CreatePulseChannelTicks(_T("Dev1/ctr0"), "", _T("20MHzTimebase"), DAQmxCOPulseIdleStateLow, 0, 10, 10);
  m_Task.Triggers.StartTrigger.ConfigureDigitalEdgeTrigger("PFI0", DAQmxDigitalEdgeStartTriggerEdgeRising);
// Create digital output task
  CNiDAQmxTask m_Task2(_T("ATask2"));
  m_Task2.DOChannels.CreateChannel("Dev1/port0/line0", "", DAQmxOneChannelForAllLines);
  m_Task2.Timing.ConfigureSampleClock("XXXXXX", 0, DAQmxSampleClockActiveEdgeRising, DAQmxSampleQuantityModeFiniteSamples, 400);
How do I specificy "counter 0 Internal Output signal" instead of "XXXXXX" above, i.e. the sample clock of the digital output signal. Can't find the name of the signal anywhere in the documentation and help files. I have a 6259 DAQ board.
/pek

Thank you for your answers, but I can't get it to work.
When I use "ai/SampleClock" as sample clock everything works correct. When I try to use a counter as sample clock the task completes imediately, before any digital signals has been sent/measured. The task even completes before I have started the trigger, which is very confusing. No error appears.
I think that something is wrong about how I setup the counter. I use the code below:
// Create counter task
CNiDAQmxTask m_Task(_T("ATask"));
m_Task.COChannels.CreatePulseChannelTicks(_T("Dev1/ctr0"), "", _T("20MHzTimebase"), DAQmxCOPulseIdleStateLow, 0, 100, 100);
m_Task.Triggers.StartTrigger.ConfigureDigitalEdgeTrigger("PFI0", DAQmxDigitalEdgeStartTriggerEdgeRising);
// Create digital output task
// The code below works with "ai/SampleClock" as sample clock
CNiDAQmxTask m_Task3(_T("ATask3"));
m_Task3.DOChannels.CreateChannel("Dev1/port0/line0", "", DAQmxOneChannelForAllLines);
m_Task3.Timing.ConfigureSampleClock("Dev1/Ctr0InternalOutput" /*"ai/SampleClock"*/, 0, DAQmxSampleClockActiveEdgeRising, DAQmxSampleQuantityModeFiniteSamples, 400);
// Create samples
CNiUInt32Vector ui_data;
for(int i = 0; i < 200; i++)
for(unsigned int j = 0; j < 2; j++)
ui_data.Append(j);
// Create digital writer
CNiDAQmxDigitalSingleChannelWriter m_writer3(m_Task3.Stream);
m_writer3.WriteMultiSamplePortAsync(true, ui_data);
// Wait until task completes
m_Task3.WaitUntilDone(-1);

Similar Messages

Sample Clock from Numerical Position Output of Digital Encoder

Hey everyone,
I'm trying to sample a voltage (pressure inside an engine) with my NI USB-6212 against a rotary encoder position (crankshaft angle). For some brief background, I'm using a producer/consumer structure and my rotary encoder has proprietary VIs from the manufacture to interface. It's from US Digital and it's an HD25A. It makes the most sense to use my rotary encoder as a sample clock so I wind up with a sampled point of pressure data for each crankshaft angle. This makes it far easier to average pressure traces together and work with the data.
I've found quite a few threads on this (links at the end of my post) but they all rely on having a pulse output from the digital encoder which is then wired into a counter input on their board. I don't have a pulse output, my encoder is outputting a numeric value between 0 and my chosen resolution (currently 3600, so 0 to 3599).
My question is how can I take this changing numerical output and make a sample clock pulse for each time the value changes? Does this need to be turned into a task to use as a sample clock? I'm essentially using the data acquistion program from the example program Cont Acq&Graph Voltage-Ext Clk.vi.
Thanks in advance for any help you can lend me and my apologies if I missed a prior thread on this topic. My search-fu wasn't able to turn anything up.
Some relevant links I found, though I couldn't quite make enough sense of them to get the fog to lift:
http://forums.ni.com/t5/Counter-Timer/How-to-reset-a-counter-on-external-signal-in-LabView/td-p/1521...
https://decibel.ni.com/content/docs/DOC-12106
http://ni.lithium.com/t5/Multifunction-DAQ/Rotary-encoder-data-acquired-simultaneously-with-analog-i...

I don't think there is anyway you are going to make this work like you think you can. The US digital encoders I have worked with and their VI's were based on reading the current encoder count through a serial port connection. To do what you want, you are going to need to read the encoder every time the count changes. At 216 kHz, a serial connection is not going to be able to do that. Even if it could, you would essentially still have some latency between when the count changed and when the VI would be able to request a reading and get a response that showed the count had changed.
You need to use an encoder that has a digital pulse output that you could use as a sample clock on a data acquisition card.

How to output a digital signal on negative slope of the clock?

Hi
I need to output a finite length of the digital pulse which will start on demand at the negative slope of the imported (or exported) clock.
I am trying to get the clock exported or imported, but in no case I can trigger outputting the signal on the negative slope.
What is the trick?
thanks
Pawel
Solved!
Go to Solution.

Which device are you using to generate your digital signal. What is the clock source? Can you attach your vi? Normally, there is a DAQ function to configure the trigger where you choose the trigger source and the trigger slope (rising or falling), which would be falling for a negative slope.
- tbob
Inventor of the WORM Global

How to input/output a digital signal and acquire an analog signal at the same time?

Dasylab, version: 8.0.04
Acquirement Card: PCI1002L
When I use DasyLab to acquire the analog signals is no problem without digital inputs and outputs,
and when I use DasyLab to input or output a digital signal is no problem also, but when I do that at the
same time, DasyLab tell me the rate is too high and stop.
so, I searched the manual book1 (user guide) for that, it showed me :
To internally equalize measurement time and system time in the analog input, digital input and counter
hardware modules, use the following settings:
   Synchronization: PC Clock
   Sampling rate: <= 5Hz
   Block size: =1
the problem is, if I set the Sampling rate to 5Hz, the speed of the acquirement datas is not enough for my
application.
so, how to improve it? who can give me a example programm for me. thanks!
by the way, I come from China, my English isn't good, I'm sorry.
Allen, China.

Hi,
Have things changed over the years?
I need to syncronise a digital output (Modul NI9474) and an analoge input (AI-Modul NI9203) module. I need to measure time intervals from a flank in signal A to a flank in signal B. I would like accuracies of the order of 1 ms. Currently, the signals are not synchronised, with errors of the order of 2 times the block length (block size x sample rate), sometimes much higher. The best I got so far was a block size of around 20 with a sample rate of 1 kHz.
If I use the master and slave settings on the RTSL settings, my program doesn't run properly.
If I use digital signals for input and output, I can syncronise them with RTSL settings and everything is good, but I can't always do that.
Also, if I do anything in the GUI (such as scrollowing something or going to another window), my output gets screwed up properly.
1. What can be done to synchronise AI with DO?
2. Is there something that can be done to avoid messing up the output when something happens in the user interface? (I know that I am messing up the outputs as they make some valves switch and that is loud).
Thanks in advance!

Buffered event counting. Why can't I explicitly sequence generating the Sample Clock Pulse and reading the counters?

At irregular occasions I need to grab counts from several counters, and buffering the counts must be done simultaneously for all counters. I'm modeling my approach after zone.ni.com/devzone/cda/tut/p/id/5404 which someone kindly pointed out in an earlier thread. However, that example only uses one counter, and you can't test the synchronization with only one counter, so I am using two counters configured the same way, and they're wired to a single benchtop signal generator (for example at 300 kHz).
What I want to do, I can test in a loop with a somewhat random wait in it. I want to drive a hardware digital output line high for a few ms and then low again. The hardware line is physically connected to terminals for my timing vi's Sample Clock Source and so will cause them to buffer their counts for later reading. After I pulse this line, when I know new good buffered counts await me, I want to read both my counters. If their bufferings are simultaneous, then each counter will have counted the same number of additional counts since the last loop iteration, which I can check by subtracting the last value sitting in a shift register and then subtracting the two "additional counts" values and displaying this difference as "Diff". It should always be 0, or occasionally +1 followed immediately by -1, or else the reverse, because buffering and a count could happen practically at the same moment.
When I do this using a flat sequence to control the relative timing of these steps, so the read happens after the pulse, the counters often time out and everything dies. The lengths of time before, during, and after the pulse, and the timeout value for the read vi, and the size of the buffer and various other things, don't seem to change this, even if I make things so long I could do the counting myself holding a clipboard as my buffer. I've attached AfterPulse.vi to illustrate this. If I get 3 or 10 or so iterations before it dies, I observe Diff = 0; at least that much is good.
When I use two flat sequences running in parallel inside my test loop, one to control the pulse timing, and the other to read the counters and do things with their results, it seems to work. In fact, Diff is always 0 or very occasionally the +/- 1 sequence. But in this case there is nothing controlling the relative timing such that the counters only get read after the pulse fires, though the results seem to show that this is true. I think the reads should be indeterminate with respect to the pulses, which would be unreliable. I don't know why it's working and can't expect it to work in other environments, can I? Moreover, if I set some of the pulse timing numbers to 1 or 2 or 5 ms, timeouts start happening again, too. So I think I have a workaround that I don't understand, shouldn't work, and shouldn't be trusted. See SeparateSequence.vi for this one.
I also tried other versions of the well-defined, single sequence vi, moving the counter reads to different sequence frames so that they occur with the Sample Clock Source's rising edge, or while it is high, or with the falling edge, and they also often time out. I'll post these if anyone likes but can't post now due to the attachment limit.
Here's an odd, unexpected observation: I have to sequence the reads of the counters to occur before I use the results I read, or else many of the cycles of this combine a new count from one counter with the one-back count from the other counter, and Diff takes on values like the number of counts in a loop. I though the dataflow principle would dictate that current values would get used, but apparently not so. Sequencing the calculations to happen after the reads fixes this. Any idea why?
So, why am I not succeeding in taking proper control of the sequence of these events?
Thanks!!!
Attachments:
AfterPulse.vi ‏51 KB
InSeparateSequence.vi ‏49 KB

Kevin, thanks for all the work.
>Have you run with the little execution highlighting lightbulb on? -Yes. In versions of this where there is no enforced timing between the counter and the digital line, and there's a delay inserted before the digital line, it works. There are nearly simultaneous starts on two tracks. Execution proceeds directly along the task wire to the counter. Meanwhile, the execution along the task wire to the digital high gets delayed. Then, when the digital high fires, the counter completes its task, and execution proceeds downstream from the counter. Note, I do have to set the timeout on the counter longer, because the vi runs so slowly when it's painting its progress along the wires. If there is any timing relationship enforced between the counter and the digital transition, it doesn't work. It appears to me that to read a counter, you have to ask it for a result, then drive the line high, and then receive the result, and execution inside the counter has to be ongoing during the rising line edge.
>from what I remember, there isn't much to it. There really aren't many candidate places for trouble. A pulse is generated with DIO, then a single sample is read from each counter. -Yup, you got it. This should be trivial.
>A timeout means either that the pulse isn't generated or that the counter tasks don't receive it. - Or it could mean that the counter task must be in the middle of executing when the rising edge of the pulse arrives. Certainly the highlighted execution indicates that. Making a broken vi run by cutting the error wires that sequence the counter read relative to the pulse also seems to support that.
>Have you verified that the digital pulse happens using a scope? -Verified in some versions by running another loop watching a digital input, and lighting an indicator, or recording how many times the line goes high, etc. Also, in your vi, with highlighting, if I delete the error wire from the last digital output to the first counter to allow parallel execution, I see the counter execution start before the rising edge, and complete when the line high vi executes. Also, if I use separate loops to drive the line high and to read the counter, it works (see TwoLoops.vi or see the screenshot of the block diagram attached below so you don't need a LV box). I could go sign out a scope, but think it's obvious the line is pulsing given that all these things work.
>Wait! I think that's it! If I recall correctly, you're generating the digital pulse on port0/line0... On a 6259, the lines of port 0 are only for correlated DIO and do not map to PFI. -But I'm not using internal connections, I actually physically wired P0L1 (pin 66) to PFI0 (pin 73). It was port0/line1, by the way. And when running some of these vi's, I also physically jumper this connection to port0/line2 as an analog input to watch it. And, again, the pulse does cause the counter to operate, so it clearly connects - it just doesn't operate the way I think it is described operating.
For what it's worth, there's another mystery. Some of the docs seem to say that the pulse has to be applied to the counter gate terminal, rather than to the line associated with the sample clock source on the timing vi. I have tried combinations of counter gate and or sample clock source and concluded it seems like the sample clock source is the terminal that matters, and it's what I'm using lately, but for example the document I cited, "Buffered Event Counting", from last September, says "It uses both the source and gate of a counter for its operation. The active edges on the gate of a counter is used to latch the current count register value in a hardware register which is then transferred via Direct Memory Access...". I may go a round of trying those combinations with the latest vi's we've discussed.
Attachments:
NestedSequences.png ‏26 KB

Using a Counter to error-check External Sample Clock

Hi all,
I am newish to labview and am working on a data acquisition project. I've managed to get the basics under control, but here's my situation and question...
-- I am using the S-6123 card to capture and record data on two or more AI channels. I am using a rotary encoder to generate a pulsetrain that I am using via PFI0 as the sample clock for recording the AI data.
-- This rotary encoder gives 720 pulses per revolution and an index pulse once per revolution.
-- In my data acquisition, I am pulling 1440 samples at a time with the DAQmx "read" function.
I have been experimenting with counters and can get the RPM out of the pulse trains well enough, however I was wondering...
Is there some way to use the 2 counters on the card (and signal routing of the two pulse trains) to double-check that the 1440 samples I take correspond to two exact revolutions, and that I'm not getting ahead of or behind the rotation of the encoder due to missing clock pulses or reading false pulses. I have a couple of ideas on how to attempt to do it, but to me they don't seem very reliable or efficient, so I thought I'd put it to the experts to point out of there is a more obvious way of doing it.
I have attached a pdf of the specifications of the encoder family, the pulses that will be output are on the right hand side of page 2.
With many thanks in advance,
Peter
Message Edited by mumech on 07-22-2008 01:05 AM
Attachments:
REncoder Specs.pdf ‏312 KB

Thanks very much for your reply. I had come across the use of counters with angular encoders but hadn't quite thought of the concept in this way.
I will have to experiment a bit over the next day or to see what this is capable of, the examples seem quite comprehensive, however I'm not sure if I will run into issues due to the fact that I am using the rotary encoder as the sample clock for my analogue data.
Would I indeed be able to compare these values (ideally check the position of the encoder after each set of data acquisition) without a "third party" sample clock common to both? (which isn't appropriate for this application)
If I was only running at low speeds, I might be able to implement this by simply checking the position of the encoder after each read of the data. However, at higher speeds there might be synchronization issues due to the buffering of the analogue data. So when getting the measurement from the encoder counter chances are the analogue data was acquired at an earlier time.
I know I haven't worded this very well, but how might I synchronise this error checking method?

Using AI Sample Clock to Trigger Counter Samples

My basic question is: Is the ai\SampleClock signal only active while an analog input task is running?
The details are:
I have an X-series PCIe-6321 multifunction DAQ card. It is controlling a SCXI chassis and has a SCXI-1180 and SCXI-1302 so I can control analog inputs of the chassis as well as access the 4 counter on the card. My application requires that I use all 4 counters to measure a frequency input signal and synchronize the samples to the analog input signals. I have created 5 tasks, 1 for the AI and 1 for each counter.
I am using LabVIEW 8.6.1 with the latest NI-DAQ drivers on and 64-bit Vista OS
1. Are there any driver or hardware restrictions that would cause this solution not to work?
2. Can I use the ai\SampleClock as in input sample clock for each of the frequency tasks? If I do this will the sampling start be syncronized? I.e. if I start each of the frequency tasks first, will they wait until the AI task is started before they start sampling?
3. If that doesn't work, do I need to route the sample clock from the AI task to a PFI line (PFI1) and then use that as input to the frequency task sample clock?
I usually do option 3 when synchronizing two cards in PXI chassis and only use the software task start in stead of of synchronizing on a digital start, since the sample clock will control the samples anyway. I need to know if the same behaviour works with the scenario above.
Thanks,
Bob
Prolucid Technolgies Inc.
Solved!
Go to Solution.

Hi Bob,
I can confirm that the ai/SampleClock will only be active while the AI task is running. As far as the other questions go:
1. You'd have to provide more information about what you looking to do exactly, but there is no problem with routing the sample clock of the Analog Input task to be used with the Counters. I would read through the section of the X Series User Manual that discusses sample-clocked frequency measurements (starting on page 7-16) for some more information about what is actually going on during this configuration to make sure it suits your requirements.
The frequency of the signal to be measured should be at least twice as fast as the sample clock of your AI task.
2. You can indeed route the signal to all four tasks at the same time (you can refer to the Device Routes page in MAX to double-check routing restrictions). The sampling will be synchronized provided the four counters are started before the AI task, but the counters will be armed at different times unless you configure an Arm Start Trigger (see page 7-45 of the X Series User Manual). I would consider using the ai/StartTrigger if you wish to do this.
The effect of not arming the counters at the same time would be a different number of periods to average on each counter for the very first sample (assuming averaging is enabled). This might not be a big concern but I just wanted to point it out.
3. The routes are available internal to the board so external routing isn't necessary, you can just specify to use the AI Sample clock for the clock of each counter and the routes will be made for you. If you prefer to export the signal on a PFI line and route it back in on a different PFI line this option is also available to you but shouldn't be necessary.
I hope this helps you get started. I'd make sure to take a look at chapter 7 of the X Series User Manual if you get a chance since it describes how all of the counter configurations work in more detail. If you have any related questions don't hesitate to post back.
Best Regards,
John
Message Edited by John P on 12-01-2009 07:52 PM
John Passiak

PCI-6229 Digital I/O sample clock problem

Hi,
I am using PCI-6229. I need to use digital output channel to generate 20KHz 30%duty cycle pulses.
The datasheet shows DO sample clock frequency can be 1M Hz. But in may application, only 100KHzTimebase can work to generate. But acctually I need at least 200K Hz.
Attached is the Vi I made. Can anyone help me with this problem?
Thanks
Solved!
Go to Solution.
Attachments:
Digital pulse_DO Channel.vi ‏26 KB

Hello All,
I tried to modify the VI posted in this thread in order to aquire a digital signal with the PCI-6229. Sinc the frequency of the signal is below 1k i tried to devide the signal of ctr0 respectively of freqout by 8 or 16 since 6.25k or 12.5k sampling frequency would be more than enough for my purpose. By the way, when I am using the 100k timebase for the timing of the task the programm is working. Since i try to monitor up to 20 channels, the amount of data genereated is too much. Therefore I tried to use the modified VI.
Sometimes, the VI works, but almost always, the DAQmx - Read VI doesn´t terminate.
Has anybody an idea what i did wrong?
Thank you for your assistance.
Sincerely,
Mirko
Attachments:
Digital pulse_DI Channel-1_mod.vi ‏32 KB

Implicit counter and sample clock together

Hi,
I am using Labview with a NI DAQPad-6015 to measure temperatures (4 thermocouple channels) and control via a duty cycle (at constant pulse frequency).
The VI I built contains a sample clock for setting measurement rate and an implicit timer to drive the "pulse frequency counter output".
In this way, the measurement rate is slowed by the implicit timer (I guess, as the measurement VI alone runs with the properly timing).
How to overcome this matter?
Thanks in advance
Gianluca

here is the VI I built for acquisition and control.
The bottom loop acquires and sends signals, while the top loop averages measurements and write all into a file.
Freq_duty_cycle.vi allows me to change on the fly both frequency and duty cycle of pulse.
HBridge.vi is the control for a H bridge I drive to invert current direction to a load.
Attachments:
HBridge.vi ‏12 KB
temp_acq_4channels_peltier_control_Hbridge.vi ‏71 KB
Freq_duty_cycle.vi ‏14 KB

NI PCIe-6351 Count Edges Channel error on fast TTL - Multiple Sample Clock pulses were detected

Hello,
I am trying to use a PCIe-6351 to record the arrival times of a fast TTL pulse stream (generated by an Excilitas/Elmer Perkin APD). The TTL pulses are 2.5 volt amplitude, 20 ns duration, with a gauranteed dead time of 50 ns between pulses. I am trying to use the the Count Edges function, with the 100MhzTimebase as the input terminal and the input to counter 0 (PFI8) as the sample clock. After a few seconds of acquiring data at 100 Mhz, the application throws the following error (-201314):
"Multiple Sample Clock pulses were detected within one period of the input signal"
I had thought that because there is 50 ns dead time between pulses, multiple pulses would never arrive within a single clock cycle of the 100 Mhz timebase. Is there any way this might not be the case? Alternatively, is it possible that the counter is triggering on some jitter around the edges of the pulses? If so, is there any way to filter such high frequencies without losing the 20 ns pulses?
I have read through the forums for similar problems with photon detectors, but have not been able to resolve this issue. Thank you for the help.
Matthew Bakalar

It sounds like the input signal is being detected as multiple edges.
The PFI filtering feature on the X Series card likely isn't going to be suitable for you. The minimum setting is actually exactly 20 ns, which should in theory guarantee a 20 ns pulse passing through. However, if the signal is high for anything less than that there wouldn't be a guarantee (depending on the phase of the timebase relative to the rising edge of the signal)--considering rise times and that there is evidently a glitch in the signal itself, it probably isn't actually a continuous 20 ns high time by the time the DAQ card sees it.
What you should do instead:
Configure a second counter as a retriggerable counter output (single pulse).
Use your external signal as the start trigger for this counter output task.
Set the initial delay, high time, and low time for the counter output task all to 20 ns (the minimum).
Use the internal output of the counter output task as the sample clock source for the original edge count task.
The counter output will be triggered when it sees the external signal, wait 10-20 ns, then generate a 20 ns pulse. If there is a glitch on the trigger line during this 30-40 ns that the output is generating, it will be ignored. The counter output will be re-armed in time for the next pulse given the minimum dead time of 50 ns between pulses.
Best Regards,
John Passiak

Generate counter output based on a digital trigger

I am trying to output a train of pulse based on a digital trigger (GO bit). When the GO bit goes high, I want to output a pulse train after an initial delay (ie: 2 seconds). When the GO bit goes low, I want to stop this pulse train. When the GO bit goes high again, I want to start the same pulse train with the same initial delay.
The output pulse train has 2 frequencies so I am using 2 counters that generate the same pulse but one of them is delayed by a certain amount. Then I combine the output from both counters into one output using simple BNC T connector. Since I am using 2 counters (max # of counters available to me), I can't create a finite pulse train.
If I use a pause trigger, the only problem is that the second time the GO bit goes high, the initial delay is not used (each channel or counter has a different delay).
So far the only way I can think of is by software timing the counter (by counting the time since the task has started) and stopping the task once certain amount of time has passed. Then I wait for a second trigger which should start the pulse train again with the initial delay.
Is there a better way to do this?

One more thing:
Is there any way to use a digital trigger that is based on two different digital signals ANDed together? I basically want to output the pulses when 2 digital inputs are binary 1 at the same time.

"External sample clock" and "Rate" for digital input acquisition

Dear all,
I want to acquire digital input (21 bits with external clock = 50 kHz) with a PCIe-6343 NI board. Using the DAQ assistant under Labview, I selected the advanced timing with the sample clock time parametrized as External. However, it is also possible to select the Rate of the acquisition. In my case, i want to get the data at the rising edge of the external clock signal, so at a frequency of 50 kHz. How can I do that ? I just need to put a Rate of 50 kHz ?
thanks for your help.
Cedric

Cedric,
dddsdsds wrote:
[...]In my case, i want to get the data at the rising edge of the external clock signal, so at a frequency of 50 kHz. How can I do that ?[...]
You answered your question already. If you want to use an external clock, you have to configure the timing source of your task to be external. In order of proper buffer configuration, you should enter 50kHz as rate in addition to the external configuration, but this will not influence the speed of the acquisition (since it is "clocked" externally!)
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

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

Can buffered digital edge detection only be performed using an external sample clock?

I am working on an application where I need to measure the speed (rpm) of a motor as it starts up using the output of its built in hall effect sensor. The sensor should output 2 pulses per revolution of the motor. My plan is to count the pulses from when the counter (counter 1) is armed to when it is up to speed. Looking at the M series manual, the CVI (v8.5.1) help, and the examples it appears that this can only be done using an external sample clock. Is there a way to route an internal sample clock to the appropriate terminal on the counter so that I do not need to add additional hardware?
I am currently using a PCI-6289, but the final application will use a CDaq-9188 chassis (using one of the the built in 32-bit counters).
Thank you for your assistance.

Thank you for your input.
However, I did forget to mention one detail of the application. I need to buffer the edge counts so that I can graph the speed of the motor as it starts up. I need to be able to acquire the edge counts at reqular intervals so that I can determine how fast the motor was rotating at each point. So far I have not been able to find an example of doing this without and external sample clock. As I mentioned, in the final application I will be using the 32-bit counters on a CDAQ-9188 chassis. The only thing I can think of at this point is to generate a pulse out of the second counter and use that as the sample clock. Will this work?

Unable to use sample clock digital filter - PCI6602

I can't seem to get digital filtering of the sample clock to work on my PCI6602. I'm using DAQmx 7.4, with one of the counters configured for buffered-edge counting. Whenever I try to configure digital filtering on the sample clock (coming in on pfi10):
counterTask.Timing.SampleClockDigitalFilterEnable = true;
counterTask.Timing.SampleClockDigitalFilterMinimumPulseWidth = 0.000005;
I get the following error message when I start the task:
Additional information: Digital filtering is not available for the given terminal.
Device: Dev3
Property: NationalInstruments.DAQmx.Timing.SampleClockSource
Corresponding Value: /dev3/pfi10
Channel Name: phaseLockOscillator
Task Name: PhaseLock task
Status Code: -200772
I thought digital filtering was supported on all pfi inputs on the 6602 - so can anybody give me a hint as to what I'm doing wrong !?
Many thanks in advance,
Jony Hudson

I have the same problem with the PCI-6280., help me please!

Counter Output as Sample Clock of Digital Signals

Similar Messages

Maybe you are looking for