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

Similar Messages

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

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

UMB COC zero balance at the end of period

Hi All
When material ledger is active, is always desired to have zero balance in PRD accounts, since it´s a P&L account, as far as I know; same is valid to UMB and COC accounts? Is necessary to have zero balance at the end of period for these ones?
Tks a lot

Hi,
It is better to have zero balance for GL accounts of UMB.
Regards
Sudhakar Reddy

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

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

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

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

Analog period Measurement

Hello,
I need to measure the frequency of the sinuoidal signal that is acquired using LabVIEW FPGA. I tried to use the block Analog Period Measurement.
The value that i have used are: threshold level 0, hysteresis 0.5.
However, no matter what the frequency, the period is always zero.
I also tried different threshold and hysteresis values, but it was in vain.
I would be grateful if you could be of any help.
Regards, Keshav
Solved!
Go to Solution.

Hi keshasvew,
This function has a valid output signal that only becomes true once per period, so it's likely that you're actually getting a good result, but never seeing it. You will need to add a bit of code on the output that uses the output valid signal to latch the latest valid measurement result. You should also monitor the timeout output, as that will generally stay true if you're not getting any results at all.

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.

Buffered semi period measurement: discard EVERY first value?

Hello,
I perform the buffered semi period measurement. The data aquisition last very long (maybe over one day...).
I arm the counter and then I execute the "read buffer.vi" in an while loop to read the data continuously into a circular buffer.
In the 6602-manual I read the first value ist always bogus.
My question is:
Will I have to discard always the first value when the while-loop restarts? Or will I have to discard only the first value after the first iteration of the while-loop.
Regards Peter

Peter,
You will only need to discard the first value from the first iteration of the While Loop (Counter Read Buffer.vi). Unless you implement a start trigger, the counter could begin counting in the middle of a pulse. Since the counter does not stop and start counting during each iteration of the While Loop, only the very first value buffered is bogus (great choice of words).
Good luck with your application.
Spencer S.

External sample clock with pulse width measurement

Dear all,
I am using a NI 6220 board (programming with ANSI C) and would like to perform a "single pulse-width measurement" using an external gate signal and an external signal as source.
Using the "DAQmxCreateCIPulseWidthChan" command the program and card works only partly as intended. Namely, the external gate did work, but the card uses the internal 80 MHz time base signal instead of the external source connected to the default source pin (PFI 8).
I tried to route another PFI pin to the default source pin using the "DAQmxConnectTerms" command but this did not help either.
Obviously, I am missing something...
Best, Uli
Solved!
Go to Solution.

Hi Uli,
I posted to your thread here.
Best Regards,
John Passiak

NI6602 pulse width measurement: Do I have to use an external sample clock?

Hi
In the .NET 4 example 'MeasPulseWidthBuf_SmplClk_Cont' it is stated in the comments that:
An external sample clock must be used.
Counters do not have an internal sample clock available. You can use
the Gen Dig Pulse Train-Continuous example to generate a pulse train on
another counter and connect it to the Sample Clock Source you are using
in this example.
I have an application running without specifying an external clock. The applications is running, but I'm not sure I can trust the recorded data. Here is the channel creation code:
   task.CIChannels.CreatePulseWidthChannel(readTaskCounter,
   "ReadPulswidthTask", 25e-9, 20e-6,
   CIPulseWidthStartingEdge.Rising,
CIPulseWidthUnits.Seconds);
task.CIChannels.All.DataTransferMechanism = CIDataTransferMechanism.Dma;
   task.Stream.Timeout = callbackTimeoutInMilliSeconds;
task.Stream.Buffer.InputBufferSize = 50000;
   task.SynchronizeCallbacks = true;
   task.Timing.ConfigureImplicit(SampleQuantityMode.ContinuousSamples);
   task.Control(TaskAction.Verify);
Note that I'm not specifying any external clock.
1) Which clock is the daq using? -It is obviously using some clock since I can collect data via this task.
2) Do I need to change the configuration to use an external clock to achieve reliable readings - as mentioned in the 'MeasPulseWidthBuf_SmplClk_Cont' example?
/mola
Solved!
Go to Solution.

Hi mola,
That specific example is for sample-clocked pulse width measurements. This type of measurement is only supported on newer hardware such as X Series boards and will not run on the 6602.
Your application that you linked uses Implicit timing, meaning that the signal itself serves as the sample clock. That is, at the end of each pulse width that you measure, the sample is deterministically latched in. So, you end up with a buffered array of every pulse width that is seen by the counter.
Best Regards,
John Passiak

Is zero backlog impossible in continous pulse period measurement?

Similar Messages

Maybe you are looking for