PXI 6229 pulse period measurement

Hi there,
I try to make pulse period measurement using PXI 6229 counter, I have 0.5Vcc according to DMM and 1.05V peak2peak based on scope. Then, I connected 0.5Vcc (incoming pulses) into SCB68 pin 3 and GND pin 55. I used the DAQ assistant to perform measurement n the setting for Signal Input range is min= 1ms and max = 23ms, those values I got it from scope i.e pulse period. I set it to the Rising and Acquisition Mode to 1 sample(on demand). But, I can’t get the measured values and I have no ideal why?
Please help
Walter.

Hi Walter,
the counter input of the PXI-6229 accepts standard TTL digital signals. You can find its specifications on page 7 of this document.
I will repeat the relevant parts here:
Input high voltage: Min: 2.2 V; Max: 5.25 V
Input low voltage: Min: 0 V; Max: 0.8 V
If I'm correct, your signal does not meet these specifications, so in this case you will have to connect the signal to an analog input and measure the pulse width as if it was an analog signal.
Please check this page for an example.
Daniel

Similar Messages

PXI-6624 Pulse Frequency measurement

Hi. I'm working with a PXI-6624 and am interested in doing pulse frequency measurements to get both frequency and duty cycle on its inputs using DAQmx.
Whenever I go to create the virtual channel however, I get error -200431:
"Selected physical channel does not support the measurement type required by the virtual channel you are creating."
"Requested Value: Pulse Frequency"
"You Can Select: Frequency, Period, Pulse Width, Semi Period, Two Edge Seperation, Position:..."
Is this card really not capable of doing these pulse frequency measurements?
Solved!
Go to Solution.

Yes, the "Pulse" (not to be confused with "Pulse Width") measurement was introduced with NI's STC3 devices including X Series and CompactDAQ.
Pulse Measurement:
However, you should still be able to measure frequency and duty cycle on your card with a semi-period measurement:
Semi-Period Measurement:
Images are from the X Series User Manual.
The difference between the two modes comes down to how the data is stored and buffered on the card--with the semi-period method the hardware doesn't distinguish between high and low samples and puts everything into a single buffer. However, if you start the counter off the appropriate edge (see below property node), then you would know in software the order of high and low samples and can pretty easily calculate frequency and duty cycle from this.
Best Regards,
John Passiak

Is zero backlog impossible in continous pulse period measurement?

I use two counters in PCI-6052E as two TTL input channels. Continous buffered Pulse periods are measured but a couple of data in the buffers are not read however I change measurement condition like time limit, count to read and buffer size. Is it impossible to make backlog value is zero all the time? Typical count rate is 20000/s and my work can not be done with even one backlog for minutes.

Hi Ulchang,
It is next to impossible to achieve zero backlog with a count rate in the kHz range. The principle is that data is transferred from the board (counter registers and FIFO) to an intermediate PC buffer. LabVIEW or your programming environment cannot poll this PC buffer quick enough to achieve zero backlog. Zero backlog would imply you are reading 1 sample at a time quicker than samples are being supplied to the PC buffer by the hardware. Even if you put the samples to read at a time to 1 and your loop has no delays and is running as fast as possible you will probably still have backlog.
If you application reads a block of data from the PC buffer, whatever is left is backlog. Thus, even if on each loop iteration you specify that your read oper
ation read the last backlog, from the last iteration to this iteration more data would have been transferred to the PC buffer form the hardware.
One way to minimize the effect is by reading a very large block of data into your application program. This means that each time your program loops, you will wait until enough data is in the PC buffer before your read completes. If this happens on each loop interation you will in theory have zero backlog but you will be less efficient with your processor since it will be busy waiting for enough data to be present on the PC buffer.
The most efficient and dynamic system is if you read a block of data from the PC memory the first time and also read the backlog. On the next iteration simply read the number of samples equivalent to the last backlog and record the next backlog for your next read. Therefore in this scenario, if you run your loop as fast as it can go, you should be minimizing the scan backlog while making the most efficient
use of the processor since it never has to wait for data to be ready.
Anyway, hope that helps. Have a good day.
Ron
Applications Engineering
National Instruments

Pulse/Period measurement to control VI

Hi
I am enquiring regarding controlling a vi iterations with an external trigger. Let me summarise my VI first.
I have a for loop using single point aquisition i need to run for a specific number of iterations depending on the time base between my external trigger (this is approx. 1-3 seconds). This is located in a while loop containing a number of other data manipulation including limit testing etc. The reason i am using single point rather than buffered is that i need to display the data in RT and (from my knowledge) i can't get the buffered aquisition to do this, or even waveform AI to do it either.
I have used the measure period VI in labview to obtain a time in either s or ms within the while l
oop and passed this to my for loop to iterate x times.
The problem is (which actually makes sense!) when the while loop runs it must recieve two pulses from the external trigger before it can pass a number to the for loop. The result of this is that i lose sequences (a sequence is the data occuring between the pulses).
The VI does exactly what i want BUT the timing is all wrong.
What i need the VI to do is capture the time between ALL the pulse sequences, so that when the VI reiterates, the number of times the for loop must iterate is already in place. I have tried buffered pulse measurement but can't seem to get it to work as i think it should.
Any ideas? It is kinda difficult to explain this exactly in writing but any solutions appreciated.
R

Ross,
There are definitely different ways of doing this. The way you have done this in your VI will work; however, there are drawbacks. First, each time you call the AI single point VI, it performs a configuration, which takes time, so you're doing this 4 times every loop. This slows down your readings.
A better way is to scan all four channels at once, and then read them all at once, saving the time to configure every loop. Even better than that is to run a buffered acquisition, and read the most current data out of the buffer.
Therefore, I would propose taking a look at an example in the LabVIEW directories for a Continuous Scan example. It will show you what VIs you need to set up the acquisition. Then, there will be a while loop w
hich reads the data. What you'll need to do is look at the inputs of the AI Read VI. There's an input to tell it where to get the data. If you set it to "Relative to the end of the buffer", and tell it to get 1 point, you'll get the most up-to-date point for all 4 channels. Then you can combine the channels to get your plot, just as you are now, and you can look to see if your trigger happens.
Second, when the trigger does occur, you can do an AI Read outside of that loop and read the ENTIRE buffer, to get ALL of the points. These will be at whatever scan rate you set up, but they will be nice and evenly spaced, not determined by the loop time. So, in this manner, you can still get real-time updates of what's happening, but your scan rate can be higher than the loop time, and you'll still get all the data. Got it?
If you need an example to demonstrate how to do this, I'd be glad to show you.
Mark

PXI-6229 single pulse

Hi,
I am using the PXI-6229. I would like to output a single digital pulse for a specific amount of time. How would I do this?
Thanks

Hi,
There is an example program called Gen Dig Pulse.vi. You can find it in the NI Example finder. Open LabVIEW and go to Help. Select Find Examples. In the Browse tab select Hardware Input and Output>>DAQmx>>Generating Digital Pulses>>Gen Dig Pulse.vi.
I hope this helps.
Regards,
Ima
Applications Engineer
National Instruments
LabVIEW Introduction Course - Six Hours
Getting Started with NI-DAQmx

PXI-6229 counter output

Hi,
I was using the DAQMx test panel for PXI-6229 module with my PXI-6229 card. I couldn't find an option of routing the counter pulse generation output to different PFIs. It is locked at PFI12 for ctr0 and PFI13 to ctr1. Is there some way by which I can route to other PFIs in the test panel or do I have to write code for it.
I want to route ctr0 output to PFI10 and route PFI12 as a counter input to measure frequency.
Please let me know
Thanks
Shiladitya

Shiladitya,
The Test panels are designed for functional testing only, and do not necessarily expose all capabilities of the device. In order to route these signals to custom PFI lines, you would need to write code. In LabVIEW, this would be done using a DAQmx Channel Property Node. Simply wire the intended terminal to the CO.Pulse.Term property.
Hope this helps,
Ryan Verret
Product Marketing Engineer
Signal Generators
National Instruments

Triggered finite acquisition and period measurement

Hello,
My problem is this: I'm not sure on how Labview accesses devices and how setting up multiple tasks affects loop iteration speed.
The vi I have attached uses a rotary encoder to generate a pulse triggering the acquisition. I have noticed that trying to also perform a period measurement on this pulse causes the iteration time to double. For that reason I have included the case structure so the program reads once every 50 iterations.
I am using the PCI 6250 (dev2) and PCI 6220 (dev1) which are connected by an RTSI cable. The 6220 and 6250 are connected to CB-68LP and TBX-68T terminal blocks respectively. The latter of which causes some problems due to incompatibility.
Any help on either te reasons for the slower iteration time and how to solve it would be most appreciated.
Thank you
Ingram
Solved!
Go to Solution.
Attachments:
new.vi ‏64 KB

Hi Ingram,
Thank you for your forum post and for including your VI. On reviewing your code I am aware of the following:
Acquiring 3 Analogue Voltages using a PCI-6220 (Temperature and Torque readings)
Acquiring 1 Analogue Voltage on the PCI-6250 which represents "Percentage Metallic Content", this task starts when a Trigger is recieved on PFI9
Acquiring 1 Counter Input on the PCI-6220 which represents the RPM of a motor
You are also logging test data to a ASCII text file, this data is only logged when the user presses the stop button on the Front Panel.
As the Counter and Analogue input tasks are seperate from one another it would be worth placing them in their own loops, I think with a bit of rearranging we should also be able to avoid the scenario where you have a while loop embedded inside another while loop. The initialisation of the DAQ tasks should only really be performed once, outside any loops. Another issue dependant on how long the application is executed is the dynamic arrays that are being created, these could become really large slowing down the application the longer it is run for.
An architecture I would recommend for your application is "Producer/Consumer" outlined in the community example available here.
The producer loop will be acquiring data and runs really fast (High Priority), the consumer loop logs data to file (Low Priority), data is shared between the loops using a Queue structure, no other wires should be shared between the 2 loops as these might cause a data dependancy.
Do you require all 3 input tasks to be perfectly syncronized with one another?
Many Thanks
Jamie S.
Applications Engineer
National Instruments

-10920 error when executing buffered period measurements on a PCI 6602 timer.

I frequently encounter the -10920 NI-DAQ error when I run the C code for single buffered data period measurement .
The error message is "One or more data points may have been lost during buffered period measurements due to speed limitations of the system". I am unable to resolve this error. I have a Win2K environment and am using VC++ to compile and execute the code. Please help.

When doing buffered period measurements, the rate at which you can transfer data from the counter is system dependant. To try to get around this there are two things you can try. The first is to set the 'number of counts to read at a time' to a greater number. This way, the 6602 board will use less calls across the PCI bus. If possible, try to limit the number of pulses coming in on the gate that you are using to latch the counts, though in many applications this is not possible.
Make sure that you minimize the PCI bus activity on your computer. This includes, video activity and any network activity along with anything else that is connected to the PCI bus.
Brian

DAQmx period measurement- buffer is cut when frequency is too high

Hello,
I'm using the DAQmx period measurement in order to measure a low frequency pulses. Even though the average frequency is low I still sometime get two pulses that arrive within a short time . When that happens I get an error message and the buffer is cut. I'm wondering if there is any way to ignore one of the pulses (in the case that the pulse arrives at a time that is too short for the program to read) and for the measurement to keep running until the buffer is full??
Thank you ,
Shafran

Hi all, thanks for your help.
I'll give more details:
1. I'm using PCI-6602
2. The error code number I'm getting is: 200141       Possible reason(s):
                                                                                     Data was overwritten before it could be read by the system.
3. I'm measuring photon emission from biological samples where each photon is converted to a pulse of a 35.2 ns width. I can control the concentration of the sample and therefore the average frequency of the pulses. I have started with an average intensity of 100 kHz and I went down to 10kHz. My final goal is to run the period measurement program in loops where I decide the buffer size so each loop will take approximately 10 seconds. The problem is that even if one out of all the buffers is cut all my calculations after that are wrong. A filter sounds like the perfect solution for my problem (I need to find out more about that option).
4. I have checked the limitations of the program and I know that it can't measure pulses that arrive at a higher frequency than a few MHz, therefore I assume that even at an average frequency of 10kHz I still get some pulses that arrive within a frequency of a few MHz.
Thanks again for all your help. I hope I didn't bore you with to many details...
Shafran

Wiring hardware for pulse width measurement

I am in difficulty.even with so simple pulse width measurement.
I am using labview 7.1, DAQmx, MAX, PCI - 6220.
I cannot find help document as to how to measure PW measurement and I find no connection diagram in MAX for using pulse width measurement.
I connect to PFI 9 (Gate) to 5V via switch. What about timebase counter as source? Ok I wanted to use internal clock from PCI-6220. But I cannot get to measure PW.
I want to MAX to measure. Once it is ok, then I will build a simple vi to understand its working better.
Pls help.

Hello,
LabVIEW has examples that are located in the Example Finder under the Help menu inside of LabVIEW. The examples specific to pulse width measurement are organized and located under the Browse tab of the Example Finder under the folders <Hardware Input & Output> <DAQmx> <Counter Measurements> <Period & Pulse Width>. The Example Finder has an information section that has information on the Description, Instructions for Running, Block Diagram Steps, and I/O Connections Overview. The last section will help with the connections. The input for the example titled Meas Pulse Width – Buffered –Cont.vi will be the gate of the counter specified in the “Counter(s)” control on the front panel … such as Dev1/Ctr0. So on your device the 6220, counter 0 gate is PFI 9 as you mentioned.
I understand that you are interested in getting started with the Test Panel in MAX first. The Test Panels are limited to Pulse Train Generation for counter output and Count Edges for counter input. Please use the Count Edges if you are interested in testing the device with a counter input task. However, the Count Edges will just be counting edges of the signal specified in “Edge Source”.
I also understand you are interested in using the internal clock from the 6220. The example I previously suggested uses a DAQmx Timing.vi to configure the duration of the task … for example finite or continuous. The Timing is set to implicit, since the signal wired into the gate of the counter is in fact controlling the timing. The source of the counter task for pulse width is the internal timebase when using DAQmx Timing (Implicit).
“Create a Counter Input channel to Pulse Width. It is important to set the Maximum and Minimum Values of your unknown pulse width as accurately as possible so the best internal timebase can be chosen to minimize measurement error. The default values specify a range that can be measured by the counter using the 20MhzTimebase.” - from the description of the Block Diagram notes on the example. I also link helpful KnowledgeBase below.
AE KB 2X6CMDDS: What Does Implicit Mean in the DAQmx Timing VI?
http://digital.ni.com/public.nsf/allkb/2B6477E3A9B7C07386256D1F0066FBDD?OpenDocument
Samantha
National Instruments
Applications Engineer

Triggered single pulse width measurement

I am trying to measure the width of a single pulse, but would like to use the pulse itself as the trigger for a counter input pulse width read using a PXI-6608. I would like to do this since the pulse can come at any time (much longer than any practical timeout) and I would like to avoid having to place a DAQmx read in a while loop waiting for the pulse to appear. Also, while the pulse is high, I would like to produce front panel feedback (light a boolean indicator). I seem to be able to achieve that by using a digital input line, but again requires a DAQmx read in a while loop. I haven't had much experience with triggers and my attempts so far appear to seem like triggers are not compatible with counter input pulse width measurement. Is it possible to set up a trigger for a pulse width measurement?

Hello kayotik,
I think the best thing to do here is to use separate while loops. You can put most of your code in a main while loop, and then put your DAQmx read in a separate while loop. Both loops can run in parallel (just don't wire any outputs of one while loop to the other while loop, because then one will become dependant on the other). In order to pass data between the two loops, you will need to use a local variable. The DAQmx read can write to a local variable, and the main loop can read from that local variable.
You will also need to stop both loops with a single stop button. This article shows how (and also demonstrates the use of local variables to pass data between independent while loops):
http://digital.ni.com/public.nsf/allkb/267704CDE91156D186256F6D00711AAE
Colden

Doing Data acq. and buffered period measurement using counters simultaneously, gives an buffer overflow error

Iam doing Data acquisition using NI-PXI 4472 and buffered period Measurement using NI-PXI 6602 simultaneously,my program gives an buffer overflow error

murali_vml,
There are two common buffer overflow and overwrite errors.
Overflow error -10845 occurs when the NI-DAQ driver cannot read data from the DAQ device's FIFO buffer fast enough to keep up with the acquired data as it flows to the buffer (i.e., the FIFO buffer overflows before all the original data can be read from it). This is usually due to limitations of your computer system, most commonly the result of slow processor speeds (< 200 MHz) in conjunction with PCMCIA DAQ boards, which have small FIFO buffers (e.g., the DAQCard-500). Sometimes using a DAQCard with a larger FIFO can solve the problem, but a better solution is to lower the acquisition rate or move to a faster system. Another cause of the -10845 error could be due to an interrupt-driven
acquisition. For example, PCMCIA bus does not support Direct Memory Access (DMA). If the system is tied up processing another interrupt (like performing a screen refresh or responding to a mouse movement) when it is time to move data from the board, then that data may get overwritten.
Overwrite error -10846 occurs when the data in the software buffer that you created for an analog input operation gets overwritten by new data before you can retrieve the existing data from the buffer. This problem can be solved by adjusting the parameters of your data acquisition, such as the lowering the scan rate, increasing the buffer size, and/or increasing the number of scans to read from the buffer on each buffer read. Additionally, performing less processing in the loop can help avoid the -10846 error.
See the NI-DAQ Function Reference Manual for a listing of all NI-DAQ error codes.
Have a great day.

60 HZ Hum on Analog Input PXI-6229

Ther is a 600mV common mode noise hum being introduced somewhere on the circuit below. It is causing the PXI-6229 to read inaacurate measurements. Is there a way to configure the device to reject common mode noise? Or any other suggestions?

Is the metal box connected to both the power system (safety) ground and the signal ground? This could be the source of the ground loop. Are the computer, PXI chasis, and the metal box power all connected to the same branch circuit and ground?
Try drawing a diagram showing every ground connection in the system. Do not just use a ground symbol but actaully make it a wiring diagram which shows where every wire, chassis, box, conduit, or anything else grounded is connected. This can sometimes be useful in discovering ground loops. I found one which included a wire attached to the mounting bolt for a toroidal transformer. It resulted in several amperes flowing through the housing of a very sensitive magnetic instrument!
As has been mentioned CMRR only applies to differential inputs. The circuit you posted is single ended so I think it is unlikely that a differential connection would help.
Lynn

Period measurement timebase apparently lower

I'm performing buffered low frequency period measurement using 1 counter, with an NI 6624. I am using the maximum timebase, which is 20MHz. The gate signal has a frequency of about 25kHz.
The expected period "resolution" due to quantization should be 1/timebase, in this case 1/20MHz=5E-8s.
The problem is that I am getting an effective "resolution" of 5E-7s, or an apparent timebase of 2MHz. What could be wrong?
I've checked digital filtering (DAQmx Channel Properties) on the source and gate signals, and are both enabled with the timebase of 20MHz.
Any comments apreciated.

Hello Daniel,
I agree that you should have a period measurement resolution of 50ns. This means that if you have a perfect 25kHz input signal, you should count 800 pulses of the 20MHz timebase within the 40us window. If you count 799 or 801 pulses, you will get 1/(39.95us) = 25.031289kHz or 1/(40.05us) = 24.968789kHz.
However, the thing to keep in mind is that you must have very accurate 25kHz source in order to determine if this is the case. Using the calculations from above, you would need a signal source with an accuracy of at least +/-0.1249% at 25kHz.
You may want to verify that your signal is at least this accurate before determining if something is wrong with your board or configuration.
Regards,
Bill B
Applications Engineer
National Instrume
nts

When exactly do pulse width measurements start?

I am using a PCI-6601 to measure pulse width and period of a PWM signal in LabView (DAQmx).
I use ctr0 for the period and ctr1 for the pulse width. The period is measured between falling edges. As I am interested in the high pulses, the pulse width measurement is configured to start with a rising edge.
I do a buffered measurement with continuous samples.
I use a common start trigger (ArmStart) for both tasks.
Everything works just fine, but one thing puzzles me:
My start trigger can occur at any phase of the PWM signal, so I expected the first measurements to be invalid. This is true for the period measurement, but the pulse width is always correct. It doesn't matter in what phase my trigger occurs, the first reading of the pulse width is always correct.
Can someone tell me why?

This is speculation, but it's probably just that NI decided to follow slightly different rules for pulse width measurement than for some of the other counter measurements.
I've done triggered period and semi-period measurements before, but don't know that I've done triggered pulse width or frequency measurements.
For the two former cases, I know that the counter will start counting time immediately after the trigger edge. The first measurement represents the time from the trigger to the first active edge period (or semi-period) edge. It is often meaningless as you anticipated. For pulse widths, I suppose NI simply decided that the trigger will arm the counter but you also need the pulse's leading edge before you start counting to measure pulse width. So the first measurement is a true measure of pulse width and is never meaningless.
If this is true, then it may be tricky to sync / correlate the data in simultaneous measurements. For your particular app, you could get away with performing a single semi-period measurement and then calculating the periods and pulse widths. In other apps, it could get more difficult.
-Kevin P.

PXI 6229 pulse period measurement

Similar Messages

Maybe you are looking for