Timestamp edge count

Hi. I am very, very new to Labview. In fact, I am working on my first program so my question is probably really simple, and I bet I overlooked the question when reviewing previous posts. Here it goes. I am using LabVIEW 8.2 and I have some tipping buckets which collect data through an analog edge count. I would like to timestamp and record the data only as it occurs. I have figured out how to continuosly save the data without a timestamp, but this is problematic because this will create an extremely large file due to the time requirments. I will post a screen shot of my code. Thanks!

Hi,
I'd like you to also expand on how you're collecting your data. What do you mean by "analog edge count"? I don't know what kind of signal you're measuring. Is it an analog signal, and if so, what are these 'edges'? Most of the time, counting edges means counting digital edges, so 0 to 5V rising edges or 5 to 0V falling edges.
At any rate, I'd like to explain a little bit about how a DAQmx task works, and I'm assuming you're continuously measuring analog signals with an analog input task. When you start an acquisition, the board will use the sample rate you specify to grab samples from the analog inputs. If you specify a continuous acquisition, it will continue to grab samples until you end the operation. Regardless of whether or not the signal value changes, the board will grab samples at the same rate. If you only care about when the signal's value changes, then you'll need to read your data and only record it to file when it does change. In that case, Ravens Fan is correct, and you'll need to do some simple post-processing to save the data of interest to you.
Joe Friedchicken
NI VirtualBench Application Software
Get with your fellow hardware users :: [ NI's VirtualBench User Group ]
Get with your fellow OS users :: [ NI's Linux User Group ] [ NI's OS X User Group ]
Get with your fellow developers :: [ NI's DAQmx Base User Group ] [ NI's DDK User Group ]
Senior Software Engineer :: Multifunction Instruments Applications Group
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)

Similar Messages

DAQmx non-cumulative buffered edge counting (like the PMT TTL problem) with PCI6221 in C program environment

I have a PCI-6221. I am programming in C/C++ and DAQmx. My application is much like the previous thread counting the number of asynchronous TTL pulses from a PMT in some user specified time interval. The time interval is typically around 1 msec and the signal rates are around 1-10 kHz. So I expect to count 0 to 10 pulses per timebin. In traditional DAQ this was called Non-cumulative buffered edge counting.
To get a clock at about 1kHz, I first create an "analogue in" task that samples at 1kHz. The only thing I use this task for is to route its sample clock to the gate of the counter. This defines my time interval as 1 msec.
I then create the counter task. I am using count edges. So I think counter0 gate = PFI9 and source = PFI8.
DAQmxCreateCICountEdgesChan(*taskHandle,chan,"",edge,initialCount,countDirection);
DAQmxCfgSampClkTiming(*taskHandle,clockSource,rate,DAQmx_Val_Rising,DAQmx_Val_ContSamps,samplesPerChan);
where clockSource="/Dev1/ai/SampleClock"
I apply my signal to PFI8.
After starting the task, I read an array of values with
DAQmxReadCounterU32(taskHandle,samplesToRead,10.0,data,samplesToRead,read,NULL);
I expect the array data to have values ranging from 0-10 for PMT input with an average rate of about 10 kHz. The trouble is that the array data does not seem to make sense. I get constantly increasing values. For very low input frequency, it just increments by one per array member.
More troublesome, when I hold PFI8 at ground, so that I expect zero pulses to be counted at the source for each edge at the gate that occur 1 per msec, I get a timeout error. I really must be able to count zero events per bin.
Am I doing something obviously wrong?

Hello,
The behavior of non-cumulative event counting is equivalent to period measurement. Additionally, the timeouts when no edges occur on your event counting terminal are the result of duplicate count prevention. In DAQ 7.4, the default behavior of duplicate count behavior should take care of this for you, but if you cannot upgrade to DAQ 7.4, I'd do a search of the discussion forums for "duplicate count prevention". There are a number of previous posts about this attribute, including this one.
If you aren't using the second counter on your device, you should be able to use the Period Measurement 2 Counter High Frequency measurement method to get your desired values. The "Measurement Time" attribute in this case would be the "sample clock" (1 kHz in your example). Then just raed the data raw to get counts rather than scaled.
If you'd like to do it using the AI timing engine. Configure a 1 counter period measurement task, use "clockSource" as your input terminal and use your PMT TTL pulses as the "Counter Timebase Source". Then read the data raw, since the scaling will not be appropriate for your needs.
I hope this helps!
gus....

Error -200429 DAQmx read (counter u32 1ch 1samp).vi -append- Edge count in for loop

I am receiving error -200429 DAQmx read (counter u32 1ch 1 samp).vi <append>. This is occuring on the second loop of a for loop.
I have a sequence inside the for loop that is using four DAQmx assistant vi's for edge count at various times in the sequence. All four of these count fine the first time through but at the beginning of the second loop the first edge count receives this error and does not count.
Any ideas?

The code you have supplied is similar to the converted subvi but this code will give an empty task error on the DAQmx Create Channel vi.
Notice on the Daqmx create task vi that there is nothing wired to the "Task to copy" or the "Global virtual channels" connectors - I believe this is why the task is empty when sent to the Daqmx create channel vi.
The code we are currently using is a modification of a previous code used before a recent upgrade. It may be better in your/NI eyes to re-write this into a State machine but time constraints and resources do not allow that at this time - All other parts of the current program work except for the counter on the second iteration. Would rather not reinvent the wheel at this point.
If the task is being cleared was the issue then the other three should also not execute. The issue appears to be the "First Call"
I have attached a zip file of the complete program as it is now written to give you a better idea of the whole picture.
Attachments:
Test Machine current code.zip ‏657 KB

Invalid values for negative counts using DAQmxReadCounterF64 for edge counting

I am seeing this issue with using DAQmxReadCounterF64 with
simple edge counting. If the counter reads a negative count value, it
returns a number that looks like an unsigned 32-bit number rolled over
(~4294967295).
I am using DAQmx v8.9.5. PXI-6602 with Windows XP, programming in C++.
Is this a bug in the driver?

Hi Mroche,
You're correct that the number you are seeing is the rollover of an unsigned 32-bit integer. Newer DAQ products use a 32-bit count register (e.g. M Series, TIO, X Series). In this register, the value -1 is represented the same as 232-1.
I wouldn't call this a bug exactly. The value you are reading is what is in the count register, and I don't think it makes sense to necessarily assume that 4294967295 should be scaled to -1 for all cases. Making this assumption would result in undesired behavior for anybody trying to count to 231 or higher (at which point the count would roll over to -231).
Having said that... position measurements are treated differently starting in DAQmx 9.0 due to the behavior reported on another thread which was in fact deemed a bug (which I notice you have seen already). The driver casts the raw count to I32 before scaling it to a position.
Now, I'm not so sure it makes sense to treat the two measurement types differently, but I think the reasoning behind the decision was that negative values make sense when talking about position, but for counting edges not quite as much (what exactly is a negative number of edges?). In the count edges case, I think it makes the most sense for DAQmx to allow the user to handle rollovers himself. At the end of the day, all the driver can do is change where the rollover occurs (either at 0 = 232 or 231 = -231).
In your case, if you want to read (-) values on your count edges task, the easiest way to accomplish this is to read the data back as U32 (DAQmxReadCounterU32) then type cast it to I32. This will give the result that I think you are looking for.
If you have any suggestions to help improve usability, please feel free to post to the DAQ Idea Exchange. Some preliminary ideas to make this experience a little more intuitive might include a property node to set how the data is cast, or perhaps have the driver cast the data to I32 if the Count Direction is set to anything other than Count Up. Although, the 2nd idea has the potential to break existing applications so it might not be as viable of an option.
Best Regards,
John Passiak

Ctr0 Edge Counting Issue

I have a PXI-6602 and am writing a C++ class to control the card. I am experiencing an issue when using ctr0 for edge counting. My setup includes one PXI-6602 and a BNC-2121. I'm using the continuous pulse signal as the source signal to the counters. My software execute the following functions in order.
// Clear any old tasks
DAQmxClearTask( TaskHandle );
// Create new task
DAQmxCreateTask( "ctr0Task",
                          TaskHandle );
// Setup channel
DAQmxCreateCICountEdgeChan( TaskHandle,
                                            "\CTR1\ctr0"
                                           DAQmx_Val_Rising,
                                            0,
                                            DAQmx_Val_CountUp );
// Start Task
DAQmxStartTask( TaskHandle );
// Read counter value
DAQmxReadCounterU32( TaskHandle,
                                 DAQmx_Val_Auto,
                                 10,
                                 buffer,
                                 sampsRead,
                                 NULL );
I execute the above code and let the task run for approximately one second. I read one sample of zero (0) counts on ctr0. When I execute the same code for the other counters, I read around 464 counts, which I believe to be valid.
Why am I reading zero counts on ctr0?
I have tried the following:
1) Using the Test Panel, I setup ctr0 for edge counting and used PFI39 (ctr0Source) as the source signal and everything worked as expected. So I know the hardware is working. I also selected the 20MHzTimebase signal as the source and everything worked as expected.
2) I manually setup a task within NI-MAX and everything worked as expected.
3) Within my software, I routed the 20MHzTimebase signal to ctr0 source and received counts although the value was incorrect. No matter how long I let the task run, I would only read around 260 counts. When routing the 20MHzTimebase to one of the other counter's source, everything worked as expected.
4) I also routed PFI39 to the source of the other counters and everything worked as expected.
Is ctr0 special or reserved? Does it have a unique timing characteristic that I'm unaware of?
Thanks in advance for any help.
-Mroche

Hey
There should not be any issue. I have that board and used that in lv, but try the attached code and see if this works.
lab
Attachments:
Count Digital Events.zip ‏56 KB

Edge counting inaccurate

I'm getting inaccurate results from my USB-6210 edge counting check from MAX. I have a TTL source that generates four pulses that is connect to PFI0 through a simple RC filter (390 ohm and 0.02uF). I start the edge counting from the test panel in MAX choosing PFI0 as the edge source. When I trigger my four pulses I receive a much larger count (sometime up to 20 counts) from the MAX test panel. Only when I remove the RC filter do I receive an accurate count (4 pulses exactly). I need to use the RC to filter out some 45KHz noise generated by another piece of equipment in the lab. I know I can set up the USB-6210 to use a time-based filter but I thought a simple RC filter would be a quick solution.
I have tried this with a USB-6211 with the same results. Only the USB-6009 preformed as expected with accurate counts. The USB-6009 edge count is not affected by the RC filter.
Any thoughts?
Thanks,

goldenrad wrote:
... I'm assuming that the input should have a hysteresis mechanism ...
It doesn't . You should use the digital filter.
goldenrad wrote:
It is interesting that the filter works perfectly on the USB-6009.
It's probably a bandwidth issue, there's no hysteresis on the 6009 inputs either. The 6009 event counter can only count up to a 5 MHz signal according to its specificaitons. The 6210 however supports an "external base clock frequency" of up to 20 MHz.
Best Regards,
John Passiak

Edge counting with digitial pause trigger

Hi
I should write a program for edge counting with digital pause trigger in visual basic. I have found an example of using pause trigger in edge counting but it is written in C#.
Steps in the program followed is:
1) creating task
2) creating count edge channel objecy
3) configuring thr trigger ( where i have been strucked)
code in c # is:
taskname.triggers.pausetrigger.digitalleveltrigger ( source, level)
When i tried to look for trigger function and to configure it in Visual Basic, I have not found any trigger function to set/configure in the function library
Thanks

Hi there,
Here is the code in text format. That's pretty much all you need. I took the example code called CntDigEvents.vbp and added the following code before the start task function call:
    DAQmxErrChk DAQmx.DAQmxSetPauseTrigType(taskHandle, DAQmx_Val_TriggerType6_DigLvl)
    DAQmxErrChk DAQmx.DAQmxSetDigLvlPauseTrigSrc(taskHandle, "PFI0")
    DAQmxErrChk DAQmx.DAQmxSetDigLvlPauseTrigWhen(taskHandle, DAQmx_Val_Level1_High)
As for the C# code I am not familiar with C# so I don't think I can be a great help on that one.
myTask.Triggers.PauseTrigger.ConfigureDigitalLevelTrigger(triggerSourceTextBox.Text, gateLevel) This function is the main call for the pause trigger and all it is doing is setting the properties. triggersource should be along the lines of "PFI0" or "Ctr0" and gate level defines whether the gate level is "high" or "low)
How is the VB code going?
AdamB
Applications Engineering Team Leader | National Instruments | UK & Ireland
Attachments:
VBcode.txt ‏4 KB

Buffered Edge Counting 20 MHz with duplicate count prevention

Dear all,
I went through the specs of several boards (M- series, S- and E- series, 6602 etc...). It seems that these boards can count edges with duplicate count prevention on at a maximum rate <= 20 MHz (i.e., 1/4 of 80 MHz) - but maybe I have misunderstood the docs.
Is there a NI board capable of buffered edge counting with a general purpose counter for random events going at rates from 0 Hz to > 20 MHz? Do I need to look for a reconfigurable board?
Thanks in advance.

Dear Elizabeth,
Thanks for the answer.
In my application, events arrive asynchronously (actually, randomly). During the duration of a gate (namely, 1 microsecond), one expects anything from 0 to many (i.e., possibly more than 20, up to 80) events. This requires duplicate count prevention.
I may have misunderstood the specs for M series boards, but the document:
Using Duplicate Count Prevention for Counter Tasks in NI-DAQmx
from the NI web site, for instance, states that:
"All the other timebase edges that occur while the external source input is high are ignored. If no source edges are detected between two gate edges, as shown in Figure 3, duplicate count prevention ensures that pulse measurements return zero because the external source must be logic high to allow the internal timebase to increment the count register. This reduces your maximum source frequency to quarter of the original maximum (80MHz) timebase for NI-STC II and NI-TIO boards. Therefore duplicate count prevention should only be used if the frequency of the Source signal is 20 MHz or less.
Duplicate count prevention should only be use in the following situations:
Counter measurements
The counter Source is using an external signal (such as PFI x)
The frequency of the external source is 20 MHz or less
What's your take on that?
Thanks for your time.

Edge counting buffer/array size problem (VC++)

Hello,
I accidentally posted this in the multifunction DAQ forum so forgive me for posting this again here.
I am attempting to do a buffered edge counting with PCI-6115 for the application I am trying to develop.
Ideally, I would initialize a buffer array, then use a sample clock to time and acquire counter values which would then be stored in a buffer.
After a certain number of samples, I would then use the
DAQmxReadCounterU32 function to extract the said data and perform some
calculations.
However, windows gives me an error when I try to initalize the size of the buffer array to be larger than 255001, I need 264000+.
Essentially, only this part of the code seems to execute:
int         error=0;
TaskHandle taskHandle=0;
TaskHandle taskHandleCtr=0;
uInt32      data[260000];
After trying to initialize the uInt32 array my program crashes saying there was an error with my exe with a popup asking me if i want to send an error report to Microsoft.
Would
this be a problem of windows not allowing me to allocated more than
255000 32 bit samples for that array? If so how do i put the array
onto the onboard memory?
Solved!
Go to Solution.

Sorry guys, it actually didn`t have anything to do with the DAQ board.
Apparently it was C++ that limits the size of the array I was calling, which was the traditional "int a[size]".
I used this instead to solve my problem:
    int* a = NULL;
    a = new int[10000000];
Problem solved.
Sorry for posting in the wrong forum, and thank you to everyone who's read this.
Howard

Buffered edge count FIFO overflow even at very low rates

Dear Forums,
I am trying to use a PXI-6608 to timestamp the sample clock of a PXI-4498 during analog input. Because the sample rate will be on the order of 20KHz, I want to use a pulse generation task on one counter to divide it down by a factor of 1000, then use that pulse as the gate and the 10MHz clock on the 6608 as the source in a buffered edge -- I expect about 20 edges per second, which should be very manageable to retrieve over DMA.
The result is that I get error -200279 ("attempting to read samples no longer available") immediately after the vi starts, before I have retrieved even one count.
This is my first stab at using DAQmx for counter/timer instead of the old DAQ drivers, so I'm sure I've done something wrong, but I can't figure out what.
I've attached the vi if that helps.
Thanks!
Cas
Solved!
Go to Solution.
Attachments:
simplified chassis test.vi ‏314 KB

It appears that you have your gate and source backwards. The sample clock should be ctr0internaloutput and the count edges terminal should be the 10 MHz clock. You are getting the buffer overflow error because the FIFO on the card is only 2 samples and at 10 MHz these are being rewritten was faster than a computer could possible pull them off the card.
Doug Farrell
Product Manager - Condition Monitoring
National Instruments
National Instruments Condition Monitoring

Encoder edge counter using analog input

I have using an 9215A USB (4AI).
2 AI are logging data in to a txt-file and the other 2AI will be used for counting the edges from a quadrature encoder (A and B pulse train).
Every edge falling or rising I will write a line in the txt-file also show a egde counter in the VI (total edges read).
I'm a beginner so I need some help to find out how to do.
BR
Johan

the 9215A do 20kSam/s , that not too much, so .... your encoder should change state 10k/s max.
first approach: continious read (with max speed) with two buffers, while one buffer is filled by the DAQ, analyse the data of the other. Three independend loops : first wait for and read buffer-> send data via queue to second analyse loop -> send data via second queue to third loop that does the file handling.
second approach: create a trigger so the second loop can be avoided. The DAQmx/Hardware does might not support the trigger on both edges on two channels, but additional hardware like LS7084 o. HCTL2022 can help you to create the trigger signal. These little bugs are designed for incremental encoders and create a pulse for every change in the A B lines
Greetings from Germany
Henrik
LV since v3.1
“ground” is a convenient fantasy
'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'

How do i develop code in LabVIEW 7.1 for configuring and performing gated edge counting using NI-DAQmx

Hi,
My application requires DAQ counter channel to count the rising edge of the input signal connected to the source pin of the counter. This counting has to take place only when there is a high pulse in gate pin of the same counter.This can be developed easily using traditional daq vis.
Please let me know how to develop code using DAQ mx.
Thanks,
Sudha

There is an example that demontrates how to do this in DAQmx called "Count Digital Events-Pause Trig.vi".
gus....

Accurate timestamping 6608 counter intervals with gps irig-b

We have a 6608 timer/counter that forms the basis of an astronomical photometer. We have TTL signals coming in on five channels, and have an IRIG-B gps clock. After much help from NI, we now have loops that have precisely timed durations (our "integration times"). The problem is our GPS time stamping. While we have a GPS timestamp for each of these "integration times", the actual times of these events (which, if the integration time was 1s should increment a second at a time) wander around by +/-0.75s. We just cannot figure out how to get this timestamp to reflect reality. The loops bang out the (correct) counts every second, but the clock cannot keep up (though it sometimes does for a few integrations in a row). We need someone to associate the exact start of an integration period with an exact clock time (we understand there are harware limitations at the ms level).
cheers,
tom harrison
Solved!
Go to Solution.

Hi, Tom Harrison.
There is a KnowledgeBase article that presents a solution to this exact issue: PXI-6608 Not Recognizing IRIG-B Signals For GPS Time
Things to check:
(1) Make sure your IRIG-B signal is the "DC Level" type.
(2) Make sure your IRIG-B signal is compatible with the PXI-6608.
(3) Make sure to attach the synchronization signal to the synchronization line of the real-time clock.
For more information on GPS-based synchronization with the 6008, read through this KnowledgeBase.
I hope you're having a great day!
Regards,
Sara Lewandroski
Applications Engineer | National Instruments
http://www.ni.com/support

Idoc to file with file name as ABCD timestamp and count

Hi,
Greetings!
I have an requirement like iDoc to File and the output file name should be ABCDYYMMDDXX (e.g ABCD14091701) in PI 7.1
where,
Default = ABCD
YY = year
MM = month
DD = date
XX = sequence no. on the same day; e.g. first batch on same day = 01, second batch on the dame day = 02
I tried checking many blogs but its not meeting this requirement.
Kindly please help me out in completing this interface.
Regards,
Vinoth

Hi Vinoth,
Below is the code. Use it in-conjunction with your dynamic config code.
String inputFile = "D:\\Receiver"; //This is your target receiver folder
String dateStr = DateFormat.getDateInstance().format(new Date());
dateStr = dateStr.substring(0, 2)+ dateStr.substring(3, 5)+ dateStr.substring(8,10);
final String fileNamePattern = "DEFAULT"+dateStr;
File file = new File(inputFile);
File[] listFiles = file.listFiles(new FilenameFilter() {
@Override
public boolean accept(File dir, String name) {
if(name.contains(fileNamePattern))
return true;
return false;
//System.out.println("Number of files in the directory "+inputFile+" : Next Counter"+ (listFiles.length+1));
int counter = listFiles.length+1;
String fileName = "";
if(counter < 10)
fileName = fileNamePattern+0+counter;
else
fileName = fileNamePattern+counter;
System.out.println("Name of the file will be:"+fileName);
Hope it helps!
Best Regards,
Anand Patil

NI 9402 edge counter works, no frequency though

Hi guys,
I've been searching these forums for about 20 hours now but I still can't seem to get this to work.
I have a NI cDAQ-9172 with a NI-9402 digital I/O module hooked up to an 360 count/rev optical encoder. The encoder produces square wave pulses equal to the input voltage. I am attempting to use the encoder as a speed sensor for my final year engineering design project. I can easily get pulse counts from the encoder into LabView (v8.5) using both DAQmx functions or the DAQ assistant. I'm pretty new to LabView but I believe I've done all I can with the program itself to make this work.
The problem I get is whenever I try to get a period or frequency output from the DAQ nothing happens. The data output stays at zero. I know the encoder is working because LabView can count the pulses. It's as if the module doesn't have any sample for time at all.
Note: When useing the "Measurements & Automation Explorer" and setting up a Task for frequency measurement, in the Timing Settings section I only have 3 options: 1 Sample (On Demand), N Samples, and Continuous Samples
Should there maybe be more?

Hi Evan,
The default gate terminals should actually be PFI1 (for ctr0) and PFI2 (for ctr1). However, these are just defaults and can be changed if you're using the DAQmx functions (but not the DAQ Assistant).
You don't actually use sample clock timing for frequency measurements (at least not on the 9172). What you could use is "Implicit Timing", meaning that the signal to be measured (which is connected to the gate) is also what is used to latch the sample in. However, in your case it might make more sense to start out using no timing at all--DAQmx Read will merely ask for data once it is called (if no signal is present it will timeout).
Here's a slightly modified version of your VI that should be a good starting point:
To avoid confusion, you can just specify any PFI line that you want for the Input Terminal (I usually do this with counters anyway). Implicit timing is an option that you can add in (before the task is started) but it didn't seem necessary based on what you have described so far.
Best Regards,
John Passiak
Attachments:
Meas Dig Frequency with Terminal.vi ‏25 KB

Timestamp edge count

Similar Messages

Maybe you are looking for