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.

Similar Messages

Meas buffered semi-period continuous.vi with DAQPad-6020E

Hi,
Does anybody know if it's possible to use the meas buffered semi-period continuous.vi with the DAQPad-6020E? Or, if it's not, what workarounds might be possible?
LabVIEW responds with Error 200220 (Measurements: Device identifier is invalid). I know the hardware is definitely good because I can run other VI's with it.
Thanks,
Dave

Dave,
Are you able to make any kind of counter examples run on your device? There are two counters on your board, are you using any of the counters for something else while running this example? Do you also get the same error in Measurement and Automation Explorer (Start >> Programs >> National Instruments >> Measurement and Automation Explorer). You can create a new task and select Acquire Signals >> Counter Input >> Semi Period. Please let me know if you get the same error in this environment as well.
Also, what is your operating system and what is the DAQmx driver version that you are using?
Thank you and best regards,
Raajit L
National Instruments

2 channels on semi period measurements M series 6221

Can I perform measurements of semi period on 2 seperate channels with my M series 6221?

Hello rawpaw,
The NI-6221 has two general-purpose counter/timers, which means that you should be able to perform a semi-period measurement with each one (for a total of two semi-period measurements).
For more information on performing these measurements, please refer to the "Counters" chapter of the M Series User Manual. Hope this helps,
Daniel S.
National Instruments

NI PCI-6602: semi-period measurement stops unexpectedly or returns wrong values

Hi,
Using an NI PCI-6602 card we try to measure the semi-periods of a digital signal.
In "continuous sampling mode", 10 samples are collected in the buffer and then are read
out.
Up to 6 counters on this card are sampling the same signal in our testing configuration.
Here we found these issues:
1. Failure
In principle, the measurement runs correctly, but one or more counters sporadically may
suffer a complete failure. I.e. these counters don't provide samples anymore.
Only after stopping and restarting the assigned task, a failed counter works again.
Apparently, a counter failure is most likely to happen when
    - the sampled signal "changes", i.e. when the pulse width of the signal changes,
    - or when the computer load is high, e.g. when opening a window of another application.
Every counter occasionally failed, but the issue was found very often at counter 1 of
the PCI-6602 card, if we used counters 0 through 5 in parallel.
Using another PCI-6602 card, the failures happened preferably on counters labeled "near"
number 5.
2. Wrong values
Occasionally the "interpretation" of the sampled values changes, i.e. the length of the
"high level" period is returned, where the "low level" period length should be given, and
vice versa.
This is our task configuration:
Configuration done with MAX:
Signal input range:    2 usec - 2 sec
Custom Scaling:        None
Sample mode:        continuous
Buffer size:        10 Samples
In addition these calls are made:
ret = DAQmxSetDigEdgeArmStartTrigSrc( task->mHandle, <use the same terminal as is used for
the signal to be measured>);
ret = DAQmxSetArmStartTrigType( task->mHandle, DAQmx_Val_DigEdge);
ret = DAQmxSetDigEdgeArmStartTrigEdge( task->mHandle, DAQmx_Val_Rising);
ret = DAQmxSetCISemiPeriodStartingEdge( task->mHandle, <the channel>, DAQmx_Val_Falling);
Best regards
Manfred

Hi Manfred7,
did you already test this behaviour with a simple example from us?
Just go through the example database and try the examples there.
These examples should work.
If it works, there is a problem with your programm.
If it won't work, please tell me more about your software:
- Version
- DAQmx Version ,...
best regards
Dippi

-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

Multi counter PCI 6602 daqmx semi period measurement

Hi All, Currently I am working on 20 PWM input channels. I have some problem on my labview code. Would some one give some advice on my vi? I crated labview code for 2 channels for now. I am doing semi period measurement. I want to measure the frequency and duty cycle of the PWM signals. But when I run it, it has error. Please give some advice where I did wrong on my vi. thanks Johnny
Solved!
Go to Solution.
Attachments:
Multi PWM Reading.vi ‏118 KB
erorr message.doc ‏91 KB

Hi marconi,
This error that you are getting is a buffer overflow error and is likely due to the value that you used as an input to "number of samples" on the DAQmx Read VI. You had it set to 4 but depending on how fast the PWM that you are reading is, you may be acquiring values to the onboard buffer much faster than you are retrieving them with the DAQmx Read VI. Then when you call the DAQmx Read VI, which reads relative to a read pointer the data that you are expecting to read from the buffer has already been overwritten. One way to get around this is to increase the number of samples to read each time you call the DAQmx Read VI. I tried out your VI and got it to work with a slight modification to the start trigger (using PFI0 instead of the 20MHz timebase) and added a loop condition to stop from getting a buffer underflow error as well. Take a look and see if this helps out. Also, why are you triggering off the 20MHz timebase? is there a particular reason? This is essentially like using no start trigger since you should get the first rising edge of that almost immediately after the DAQmx Start VI is called. I am just curious, since using this start trigger did not actually work for me (though I didn't look into why).
Chris W
Attachments:
Multi PWM Reading.vi ‏51 KB

How to synchronize two PCI-6602 via RTSI for semi-period counting of four signals?

Hello,
I try to measure 4 PWM signals. For that, I created 4 tasks (newest DAQmx), each with semi-period measuring one signal.
I want to use DMA so I have two 6602 for each two signals.
The task aquire a finite number of samples.
This works fine when starting the tasks subsequently.
Now I want to start the tasks via a trigger on the RTSI bus.
But I have no idea how to get this done.
I use the MX drivers for the first time an find it very difficult to get through the help files.
I looked at many examples but did not find a solution.
Most of the time my experiments end with an error message saying that the property is not applicable to this task, or s.th.similar.
Ans sometimes, when there seems to be a trigger defined, the task will not wait for the trigger and time out.
Is the anybody who can help me out of this?
Maybe a little sample program?
I program in CVI.
Many Thanks
Michael.

This topic is discussed here:
http://forums.ni.com/ni/board/message?board.id=250&message.id=13383&requireLogin=False
Hope this helps!

CI Semi Period, Error -200141

I try to measure the semi-period of the signal in attach with a CI semi period counter in Labview 7.0.
I am using the example VI Meas Buffered Semi-period Continuous with a acquisition card PCI-MIO-16E-4.
I can measure the semi-period of a signal of 50KHz with a duty cycle of 25% but when I try to measure the signal in attach, signal that the frequency is lower, I obtain this message.
Error -200141 occurred at DAQmx Read (Counter 1D DBL 1Chan NSamp).vi
Possible reason(s):
Data was overwritten before it could be read by the system.
If using interrupt data transfer, try using DMA. Otherwise, divide input signal before measuring.
What can I do ??
Marc Ducommun
University of applied sciences
Switzerland
Attachments:
Signal_Capteur_modified.bmp ‏38 KB

Marc
Do you get this error when measuring the lower frequency signal? Or do you only get this error when switching from one signal to another?
How are you switching from one signal to another?
Switching from one signal to another usually causes high frequency noise which can cause this problem.
For example, if your program is running fine with a 50kHz signal, and then you flip a switch to measure a lower frequency signal, the switch could introduce high frequency which could overflow the counter.
Russell G.
Applications Engineering
National Instruments

Samples Not Acquired on NI 660x or NI 6624 Devices When using pulse width, semi-period or two-edge separation buffered measurements with the NI 660x and NI 6624 on counters 0 and 1, some samples may not be acquired under certain circumstances.

In the DAQmx 9.4 Readme the following is stated:
Samples Not Acquired on NI 660x or NI 6624 Devices When using pulse width, semi-period or two-edge separation buffered measurements with the NI 660x and NI 6624 on counters 0 and 1, some samples may not be acquired under certain circumstances.
Could anyone elaborate on this? I am particularly interested in knowing under what circumstances this problem arises for the 6602 PCI devices.
How should I understand 'NI 660x and NI 6624 on counters 0 and 1'. Is it only a problem on counter 0 and 1 for the 660x or does this only apply for the 6624 devices.
/mola

Are there any NI Product Support Engineers out there who has an answer to this question and who are willing to share it with me?

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.

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

CI Semi Period Digital Filter

Hello!
I'm having difficulty configuring my counter inputs. Pretty new to Counter/Timer setups as well.
LabVIEW 8.5 and MAX 4.5.
The signals I am sampling are 200 Hz, PWM ranging from 5% to 95%, cycling back and forth.
I'm using 7 counters in a PCI-6602. The code I'm including is an example from my setup.
We are requiring the use of the Rising Digital Edge, and I'd like to include CI.PulseWidth.DigFltr.Enable to enable debouncing.
All inputs are connected to the Gate terminals on each counter.
Is my programming for the Risin edge correct? I am seeing the falling edge come through first on several occasions.
And for the debouncing programming, I always get error -200452. None of my searches revealed anything applicable.
I have also tried setting my Min value on the Semi Period configure to 0.0002 instead of 1e-7 with same results.
This is a hot project, so thank you for your time in advance!
Attachments:
Counter PWM Setup 0.vi ‏17 KB

Hi Oley,
It looks like there's two questions here:
1. Programming for the Rising Edge:
I'm assuming that you want to start the task on the rising edge of your input signal. It looks like you have set the 6602 to arm off of the rising edge of your 20 MHz timebase (which is independent of the input signal). Rather than setting the Arm Start Trigger, you can use a DAQmx Channel Property Node to set the starting edge (see below).
2. Error -200452 (Specified property is not supported by the device or is not applicable to the task.)
The property node that you have configured to enable the filter needs to be specific to the type of task that you are running (in your case, CI.SemiPeriod). You have selected CI.PulseWidth which is a different task type. The filtering is usable with a SemiPeriod task by simply changing the property node accordingly.
The property node that you configure should look like this:
This will both enable the filtering and tell the device to begin measuring on the first rising edge. Make sure that all the properties begin with CI.SemiPeriod--it can be easy to overlook at times since many of the different task types have identical properties available.
I hope this helps out, let me know if you have any questions or run into any issues implementing the above.
Best Regards,
John Passiak

Buffered freq/pulse measurement that can tolerate oversampling

I would like to synchronize a buffered freq or pulse measurement to a continuous AI task using the shared ai scan clock.
The problem is that there maybe times were there are slow to no pulses to measure and the DAQmx driver will throw an error
indicating that multiple samples clocks were received before any pulse measurements could be made. What I would like is to have
the sample clock default to a measurement of 0 and this value would be placed into the task buffer so that it will always be sync'd
to the other tasks.

Duplicate count prevention is a pretty interesting (and probably poorly named) property. With duplicate count prevention disabled, the sample is latched in on the rising edge of the source. If the gate is faster than the source, you could miss the samples that you might expect to read 0 (i.e. imlpicitly-timed buffered period measurement).
This isn't exactly what's happening on the X Series (Duplicate Count Prevention is always "True" for frequency measurements on X Series). The problem is that there is no sample available in the counter FIFO on the edge of the sample clock. I believe the error is thrown by the hardware and there isn't much that NI could change in the driver to correct for it, but I'll investigate a bit more just in case.
In the meantime, you might have to resort to counting edges of your external signal sampled from the AI Sample Clock. If your external signal is high frequency, this would be suitable, but I think it's probably more likely that your external signal is relatively slow so doing this would introduce a very large error. I'll think about this some more and post back if I think of a workaround.
Best Regards,
John Passiak

Semie addivie measure and strange behavour

Hi,
For the first time , I 'm facing a strange behavior with a semi additive measure.
In EXCEL when I' m crossing it with a product dimension (Declared as Regular type ... no time type),
the behavour is like we are crossing with a time dimension.
No SUM on the column , but the last non empty value whenever appear.
Product Type - Product code Cummulative Power
A 16 <-- Problem we don't see No 31
AA1 15
AA1 16
Total SUM 16 !! no 31
Does anyone have an idea about this problem ?
Thank you very much
Christophe
<input id="gt-speech-in" lang="fr" size="1" speech="speech" style="float:left;width:15px;padding:5px 6px;margin:0px;outline:none;border-style:none;background-color:rgba(255,
255, 255, 0);" tabindex="-1" type="text" x-webkit-grammar="builtin:translate" x-webkit-speech="x-webkit-speech" />
whenever

Hi Christophe,
your question is not clear to me. From what I understand your facing problem with measure 'Cummulative
Power' which uses aggregation function 'Last NonEmpty'.
Don't know whether this will help. In our case 'Last
NonEmpty' function would be calculating 'Cummulative Power' against 'Product' dimension attributes,
while the measure value being the value of highest member or last member of time\date dimension. (remember semi additive measures always requires time dimension)
For example consider the following table.
Product
Date
Cummulative Power
A
20140101
10
B
20140101
15
A
20140102
13
B
20140102
17
A
20140103
16
B
20140103
11
Here if 'Last NonEmpty' function is used with Cummulative Power then against each Product we would get the following results in cube.
Product
Last NomEmpty(Cummulative Power)
A
16
B
11
i.e. the above values are corresponding to the last member of time dimension (20140103) .
Saurabh Kamath

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

Buffered semi period measurement: discard EVERY first value?

Similar Messages

Maybe you are looking for