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

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 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.

  • 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)

  • Edge counting buffer/arr​ay 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

  • Compliance Settings - compliance counts inaccurate (roughly double the number they should be)

    I'm deploying some fairly simple configuration baselines - most with a single CI in it; some remediate, some do not.
    In all cases, the Compliance count (as found on the Assets and Compliance/Compliance Settings/Configuration Baselines page in the SCCM console) is roughly double the number it should be.
    The same numbers can be found in the report: Compliance And Settings Management \ Summary Compliance by configuration baseline. In that report, however, you can drill into the individual baselines, which takes you to "List of assets by compliance state
    for a configuration baseline". I find that if I add up all of the assets from this report, the number is accurate.
    We have about 4000 people in one of these CI baseline deployments, and it's showing about 8000 are compliant. We don't even have anywhere near that many clients. In another one, we have about 150 users and it's showing 280 compliant. 
    It just seems that the summarization data is somehow inflated, and completely inaccurate. Anyone know how that is calculated, or have you seen this before?

    Following some leads on my own research...
    The summarization process lives in WMI, of course, like everything else. It's apparently in root\sms\site_[SiteCode]:SMS_SummaryTask, executing the method: RequestExecution.
    The "TaskCommand" on the SMS_SummaryTask shows that it's actually executing the stored procedure: spTaskDCMComplianceSummary.
    That stored procedure loops through all the configuration baselines, and executes the stored procedure spDCM_SummarizeBaseline for each of them.
    That stored procedure ends up running a query that looks like this:
    select SiteNumber, CI_ID, SummaryType, CountTargeted, CountCompliant, FailureCount, ActivatedCount, CountNoncompliant, EnforcedCount, Severity, LastSummaryTime from
    CI_ComplianceSummary where CI_ID=@bl_ciid 
    I set the @bl_ciid and ran that select query. I got results that look like this:
    SiteNumber CI_ID SummaryType CountTargeted CountCompliant FailureCount ActivatedCount CountNoncompliant EnforcedCount Severity LastSummaryTime
    1 16795052 1 0 153 2 0 0 4 3 2014-02-13 23:33:31.633
    1 16795052 2 0 141 2 0 0 4 3 2014-02-13 23:33:31.637
    The number for this configuration baseline in the summary page is 294. That just so happens to be these two things added together (153+141). 
    Does anyone know what these two things are? SummaryType = 1, SummaryType =2 ? It seems like the summarization process is adding them together, when it should not be.

  • 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 ǝɥʇ'

  • 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

  • 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....

  • Mail unread message counts inaccurate

    I just bought a new computer with Lion installed.  The unread message count in the dock and with the mailboxes in mail is wildely inaccurate.  My older computer is running Snow Lion and its count is completely accurate.  For instance Snow Leopard may say 12 unread messages and Lion will say 1. 

    Try rebuilding the mailbox. This can take awhile if you have a lot of mail.
    Rebuild mailbox
    Try reindexing the mailbox. This can take awhile if you have a lot of mail.
    Reindex messages

  • Why is the new email count inaccurate?

    Mail is not accurately reporting how many new emails are available.
    For example, I can read all of my new email, and it will still report that I have unread emails.  Also, if I do have unread emails, it won't display that is the case.  I notice the issue the most with gmail.  Why does mail seems to continue to have issues with gmail?

    Rebuild your Mailboxes and the count will probably be correct.  I have over 300 Mailboxes and had to Rebuild them all.  Once done, the problem went away and has not resurfaced during the last 2 months.

Maybe you are looking for