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

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

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 event counting. Why can't I explicitly sequence generating the Sample Clock Pulse and reading the counters?

At irregular occasions I need to grab counts from several counters, and buffering the counts must be done simultaneously for all counters. I'm modeling my approach after zone.ni.com/devzone/cda/tut/p/id/5404 which someone kindly pointed out in an earlier thread. However, that example only uses one counter, and you can't test the synchronization with only one counter, so I am using two counters configured the same way, and they're wired to a single benchtop signal generator (for example at 300 kHz).
What I want to do, I can test in a loop with a somewhat random wait in it. I want to drive a hardware digital output line high for a few ms and then low again. The hardware line is physically connected to terminals for my timing vi's Sample Clock Source and so will cause them to buffer their counts for later reading. After I pulse this line, when I know new good buffered counts await me, I want to read both my counters. If their bufferings are simultaneous, then each counter will have counted the same number of additional counts since the last loop iteration, which I can check by subtracting the last value sitting in a shift register and then subtracting the two "additional counts" values and displaying this difference as "Diff". It should always be 0, or occasionally +1 followed immediately by -1, or else the reverse, because buffering and a count could happen practically at the same moment.
When I do this using a flat sequence to control the relative timing of these steps, so the read happens after the pulse, the counters often time out and everything dies. The lengths of time before, during, and after the pulse, and the timeout value for the read vi, and the size of the buffer and various other things, don't seem to change this, even if I make things so long I could do the counting myself holding a clipboard as my buffer. I've attached AfterPulse.vi to illustrate this. If I get 3 or 10 or so iterations before it dies, I observe Diff = 0; at least that much is good.
When I use two flat sequences running in parallel inside my test loop, one to control the pulse timing, and the other to read the counters and do things with their results, it seems to work. In fact, Diff is always 0 or very occasionally the +/- 1 sequence. But in this case there is nothing controlling the relative timing such that the counters only get read after the pulse fires, though the results seem to show that this is true. I think the reads should be indeterminate with respect to the pulses, which would be unreliable. I don't know why it's working and can't expect it to work in other environments, can I? Moreover, if I set some of the pulse timing numbers to 1 or 2 or 5 ms, timeouts start happening again, too. So I think I have a workaround that I don't understand, shouldn't work, and shouldn't be trusted. See SeparateSequence.vi for this one.
I also tried other versions of the well-defined, single sequence vi, moving the counter reads to different sequence frames so that they occur with the Sample Clock Source's rising edge, or while it is high, or with the falling edge, and they also often time out. I'll post these if anyone likes but can't post now due to the attachment limit.
Here's an odd, unexpected observation: I have to sequence the reads of the counters to occur before I use the results I read, or else many of the cycles of this combine a new count from one counter with the one-back count from the other counter, and Diff takes on values like the number of counts in a loop. I though the dataflow principle would dictate that current values would get used, but apparently not so. Sequencing the calculations to happen after the reads fixes this. Any idea why?
So, why am I not succeeding in taking proper control of the sequence of these events?
Thanks!!!
Attachments:
AfterPulse.vi ‏51 KB
InSeparateSequence.vi ‏49 KB

Kevin, thanks for all the work.
>Have you run with the little execution highlighting lightbulb on? -Yes. In versions of this where there is no enforced timing between the counter and the digital line, and there's a delay inserted before the digital line, it works. There are nearly simultaneous starts on two tracks. Execution proceeds directly along the task wire to the counter. Meanwhile, the execution along the task wire to the digital high gets delayed. Then, when the digital high fires, the counter completes its task, and execution proceeds downstream from the counter. Note, I do have to set the timeout on the counter longer, because the vi runs so slowly when it's painting its progress along the wires. If there is any timing relationship enforced between the counter and the digital transition, it doesn't work. It appears to me that to read a counter, you have to ask it for a result, then drive the line high, and then receive the result, and execution inside the counter has to be ongoing during the rising line edge.
>from what I remember, there isn't much to it. There really aren't many candidate places for trouble. A pulse is generated with DIO, then a single sample is read from each counter. -Yup, you got it. This should be trivial.
>A timeout means either that the pulse isn't generated or that the counter tasks don't receive it. - Or it could mean that the counter task must be in the middle of executing when the rising edge of the pulse arrives. Certainly the highlighted execution indicates that. Making a broken vi run by cutting the error wires that sequence the counter read relative to the pulse also seems to support that.
>Have you verified that the digital pulse happens using a scope? -Verified in some versions by running another loop watching a digital input, and lighting an indicator, or recording how many times the line goes high, etc. Also, in your vi, with highlighting, if I delete the error wire from the last digital output to the first counter to allow parallel execution, I see the counter execution start before the rising edge, and complete when the line high vi executes. Also, if I use separate loops to drive the line high and to read the counter, it works (see TwoLoops.vi or see the screenshot of the block diagram attached below so you don't need a LV box). I could go sign out a scope, but think it's obvious the line is pulsing given that all these things work.
>Wait! I think that's it! If I recall correctly, you're generating the digital pulse on port0/line0... On a 6259, the lines of port 0 are only for correlated DIO and do not map to PFI. -But I'm not using internal connections, I actually physically wired P0L1 (pin 66) to PFI0 (pin 73). It was port0/line1, by the way. And when running some of these vi's, I also physically jumper this connection to port0/line2 as an analog input to watch it. And, again, the pulse does cause the counter to operate, so it clearly connects - it just doesn't operate the way I think it is described operating.
For what it's worth, there's another mystery. Some of the docs seem to say that the pulse has to be applied to the counter gate terminal, rather than to the line associated with the sample clock source on the timing vi. I have tried combinations of counter gate and or sample clock source and concluded it seems like the sample clock source is the terminal that matters, and it's what I'm using lately, but for example the document I cited, "Buffered Event Counting", from last September, says "It uses both the source and gate of a counter for its operation. The active edges on the gate of a counter is used to latch the current count register value in a hardware register which is then transferred via Direct Memory Access...". I may go a round of trying those combinations with the latest vi's we've discussed.
Attachments:
NestedSequences.png ‏26 KB

M-Series Buffered Event Counting with DMA -- gating problem

Hi --
I am implementing DMA-based buffered event counting on a PCIe-6259 board. I use G0_Out as the gate for G1, which counts events on a PFI pin. So by setting the speed of G0, I get an event count (either cumulative or non-cumulative) on a periodic basis, which is directly DMA'd to my buffer, and synchronized with other i/o operations.
This is working well right now, except for one problem, which is that the I only get data if there is at least one source edge between gates. i.e. if there are no edges, nothing gets pumped to the dma buffer.
I am guessing that a stale data error is somehow choking off the DMA transfer from the counter. Is that possible?
Is there some magic that I need to do to avoid this, because for this application, especially if I am counting cumulatively, I don't care about a missing edge, but I do care if the dma transfers get out of phase with the rest of my timing.
Thanks in advance for any help!
--spg
Here is a snippet of the code that sets up the event counting on G1, partly based on gpctex6.cpp:
const int sDMASelect[] = {1,2,4,8,3,5};
// source: pfi, or -1 for 20Khz clock
void eventTimerSetup(tMSeries *board, tTIO *tio, int dmaChannel, bool cumulative, int source)
   int sourceSelect = (source==-1) ? 0 : (source+1);
   //MSeries.CTR.Source
   tio->G1_Input_Select.setG1_Source_Select(sourceSelect); // (pfi+1) or 20Khz=0
   tio->G1_Input_Select.setG1_Source_Polarity(0); //rising=0
   tio->G1_Input_Select.setG1_OR_Gate(0);
   tio->G1_Input_Select.flush();
   //MSeries.CTR.Gate
   tio->G1_Input_Select.setG1_Gate_Select(20); //the G_OUT signal from other clock=20
   tio->G1_Input_Select.setG1_Output_Polarity(0); //active high=0
   tio->G1_Input_Select.flush();
   //MSeries.CTR.IncrementRegisters
   tio->G1_AutoIncrement.writeRegister(0);
   //MSeries.CTR.InitialCountRegisters
   tio->G1_Mode.writeG1_Load_Source_Select(tTIO::tG1_Mode::kG1_Load_Source_SelectLoad_A);
   tio->G1_Load_A.writeRegister(0);
   tio->G1_Command.writeG1_Load(1);
   tio->G1_Load_B.writeRegister(0);
   tio->G1_Load_A.writeRegister(0);
   tio->G1_Command.setG1_Bank_Switch_Enable(tTIO::tG1_Command::kG1_Bank_Switch_EnableBank_X);
   tio->G1_Command.setG1_Bank_Switch_Mode(tTIO::tG1_Command::kG1_Bank_Switch_ModeGate);
   tio->G1_Command.flush();
   //MSeries.CTR.ApplicationRegisters
   tio->G1_Input_Select.setG1_Gate_Select_Load_Source(0);
   tio->G1_Mode.setG1_Reload_Source_Switching(tTIO::tG1_Mode::kG1_Reload_Source_SwitchingAlternate);
   tio->G1_Mode.setG1_Loading_On_Gate(cumulative ? tTIO::tG1_Mode::kG1_Loading_On_GateNo_Reload : tTIO::tG1_Mode::kG1_Loading_On_GateReload_On_Stop_Gate);
   tio->G1_Mode.setG1_Loading_On_TC(tTIO::tG1_Mode::kG1_Loading_On_TCRollover_On_TC);
   tio->G1_Mode.setG1_Gating_Mode (tTIO::tG1_Mode::kG1_Gating_ModeEdge_Gating_Active_High);
   tio->G1_Mode.setG1_Gate_On_Both_Edges (tTIO::tG1_Mode::kG1_Gate_On_Both_EdgesBoth_Edges_Disabled);
   tio->G1_Mode.setG1_Trigger_Mode_For_Edge_Gate(tTIO::tG1_Mode::kG1_Trigger_Mode_For_Edge_GateGate_Does_Not_Stop);
   tio->G1_Mode.setG1_Stop_Mode(tTIO::tG1_Mode::kG1_Stop_ModeStop_On_Gate);
   tio->G1_Mode.setG1_Counting_Once(tTIO::tG1_Mode::kG1_Counting_OnceNo_HW_Disarm);
   tio->G1_Second_Gate.setG1_Second_Gate_Gating_Mode(0);
   tio->G1_Input_Select.flush();
   tio->G1_Mode.flush();
   tio->G1_Second_Gate.flush();
   //MSeries.CTR.UpDown.Registers
   tio->G1_Command.writeG1_Up_Down(tTIO::tG1_Command::kG1_Up_DownSoftware_Up); //kG1_Up_DownSoftware_Down
   //MSeries.CTR.OutputRegisters
   tio->G1_Mode.writeG1_Output_Mode(tTIO::tG1_Mode::kG1_Output_ModePulse);
   tio->G1_Input_Select.writeG1_Output_Polarity(0);
   //MSeries.CTR.BufferEnable
   board->G1_DMA_Config.writeG1_DMA_Reset(1);
   board->G1_DMA_Config.setG1_DMA_Write(0);
   board->G1_DMA_Config.setG1_DMA_Int_Enable(0);
   board->G1_DMA_Config.setG1_DMA_Enable(1);
   board->G1_DMA_Config.flush();
   tio->G1_Counting_Mode.setG1_Encoder_Counting_Mode(0);
   tio->G1_Counting_Mode.setG1_Alternate_Synchronization(0);
   tio->G1_Counting_Mode.flush();
   //MSeries.CTR.EnableOutput
   //board->Analog_Trigger_Etc.setGPFO_1_Output_Enable(tMSeries::tAnalog_Trigger_Etc::kGPFO_1_Output_EnableOutput);
   //board->Analog_Trigger_Etc.setGPFO_1_Output_Select(tMSeries::tAnalog_Trigger_Etc::kGPFO_1_Output_SelectG_OUT);
   //board->Analog_Trigger_Etc.flush();
   //MSeries.CTR.StartTriggerRegisters
   tio->G1_MSeries_Counting_Mode.writeG1_MSeries_HW_Arm_Enable(0);
   board->G0_G1_Select.writeG1_DMA_Select(sDMASelect[dmaChannel]);
   tio->G1_Command.writeG1_Arm(1); // arm it
Scott Gillespie
http://www.appliedbrain.com
scott gillespie
applied brain, inc.
Solved!
Go to Solution.

Okay, I have it working now. In addition to your suggested changes, I had to remove the following line:
tio->G1_MSeries_Counting_Mode.writeG1_MSeries_HW_Arm_Enable(0);
It appears that writing something to MSeries_Counting_Mode causes that register to supersede the Counting_Mode register. Is that right?
So code that now works for me is listed below.
thanks Tom!
-spg
void eventCounterSetup(tMSeries *board, tTIO *tio, int dmaChannel, bool cumulative, int source) // pfi, or -1 for 20Khz clock
int sourceSelect = (source==-1) ? 0 : (source+1);
//MSeries.CTR.Source
tio->G1_Input_Select.setG1_Source_Select(sourceSelect); // (pfi+1) or 20Khz=0
tio->G1_Input_Select.setG1_Source_Polarity(0); //rising=0
tio->G1_Input_Select.setG1_OR_Gate(0);
tio->G1_Input_Select.flush();
//MSeries.CTR.Gate
tio->G1_Input_Select.setG1_Gate_Select(20); //the G_OUT signal from other clock=20
tio->G1_Input_Select.setG1_Output_Polarity(0); //active high=0
tio->G1_Input_Select.flush();
//MSeries.CTR.IncrementRegisters
tio->G1_AutoIncrement.writeRegister(0);
//MSeries.CTR.InitialCountRegisters
tio->G1_Mode.writeG1_Load_Source_Select(tTIO::tG1_Mode::kG1_Load_Source_SelectLoad_A);
tio->G1_Load_A.writeRegister(0);
tio->G1_Command.writeG1_Load(1);
tio->G1_Load_B.writeRegister(0);
tio->G1_Load_A.writeRegister(0);
tio->G1_Command.setG1_Bank_Switch_Enable(tTIO::tG1_Command::kG1_Bank_Switch_EnableBank_X);
tio->G1_Command.setG1_Bank_Switch_Mode(tTIO::tG1_Command::kG1_Bank_Switch_ModeGate);
tio->G1_Command.flush();
//MSeries.CTR.ApplicationRegisters
tio->G1_Input_Select.setG1_Gate_Select_Load_Source(0);
tio->G1_Mode.setG1_Reload_Source_Switching(tTIO::tG1_Mode::kG1_Reload_Source_SwitchingAlternate);
tio->G1_Mode.setG1_Loading_On_Gate(cumulative ? tTIO::tG1_Mode::kG1_Loading_On_GateNo_Reload : tTIO::tG1_Mode::kG1_Loading_On_GateReload_On_Stop_Gate);
tio->G1_Mode.setG1_Loading_On_TC(tTIO::tG1_Mode::kG1_Loading_On_TCRollover_On_TC);
tio->G1_Mode.setG1_Gating_Mode (tTIO::tG1_Mode::kG1_Gating_ModeEdge_Gating_Active_High);
tio->G1_Mode.setG1_Gate_On_Both_Edges (tTIO::tG1_Mode::kG1_Gate_On_Both_EdgesBoth_Edges_Disabled);
tio->G1_Mode.setG1_Trigger_Mode_For_Edge_Gate(tTIO::tG1_Mode::kG1_Trigger_Mode_For_Edge_GateGate_Does_Not_Stop);
tio->G1_Mode.setG1_Stop_Mode(tTIO::tG1_Mode::kG1_Stop_ModeStop_On_Gate);
tio->G1_Mode.setG1_Counting_Once(tTIO::tG1_Mode::kG1_Counting_OnceNo_HW_Disarm);
tio->G1_Second_Gate.setG1_Second_Gate_Gating_Mode(0);
tio->G1_Input_Select.flush();
tio->G1_Mode.flush();
tio->G1_Second_Gate.flush();
//MSeries.CTR.UpDown.Registers
tio->G1_Command.writeG1_Up_Down(tTIO::tG1_Command::kG1_Up_DownSoftware_Up); //kG1_Up_DownSoftware_Down
//MSeries.CTR.OutputRegisters
tio->G1_Mode.writeG1_Output_Mode(tTIO::tG1_Mode::kG1_Output_ModePulse);
tio->G1_Input_Select.writeG1_Output_Polarity(0);
//MSeries.CTR.BufferEnable
board->G1_DMA_Config.writeG1_DMA_Reset(1);
board->G1_DMA_Config.setG1_DMA_Write(0);
board->G1_DMA_Config.setG1_DMA_Int_Enable(0);
board->G1_DMA_Config.setG1_DMA_Enable(1);
board->G1_DMA_Config.flush();
// from Tom:
// The "magic" you need is referred to as synchronous counting mode (or Duplicate Count Prevention in NI-DAQmx).
// Try setting G1_Encoder_Counting_Mode to 6 (synchronous source mode) and G1_Alternate_Synchronization to 1 (enabled).
tio->G1_Counting_Mode.setG1_Encoder_Counting_Mode(6); // 0
tio->G1_Counting_Mode.setG1_Alternate_Synchronization(1); // 0
tio->G1_Counting_Mode.flush();
board->G0_G1_Select.writeG1_DMA_Select(sDMASelect[dmaChannel]);
tio->G1_Command.writeG1_Arm(1); // arm it
scott gillespie
applied brain, inc.

I want to read 0 count in buffered event counting mode

Hi, I am using the NI6602 board with DAQmx ANSI C. My aplication uses six counters in buffered event counting mode, 0 events is a valid value for me, but when the gate signal arrives the 0 value isn't written to the buffer. Instead the function DAQmxCreateLinScale() returns a timeout error. How can I solve it?
Thanks.

alegrecd,
I'm afraid I don't know the syntax for doing this from C with explicit DAQmx calls. But I think you need to look into turning ON the property called "duplicate count prevention." The name isn't the most descriptive of the actual behavior.
Normally the property is OFF. In such case, the counter expects the Source signal (which increments the internal count register) to be faster than the Gate (or "sampling clock") signal. If no Source edges are seen between successive Gate edges, the count value is NOT put into the data acq buffer.
If you turn the property ON, then the count values WILL be written to the buffer, even if no source edges have occurred between successive Gate edges.
-Kevin P.

Retriggerable buffered event counting

I have been programming with Labview for the last 3 years, but know i have a problem:
Anybody know if is possible to do a retriggerable buffered event counting?
Thanks for your time.

Jofre,
Mark's suggestion is definitely a simpler and cleaner solution. I've done a pretty similar thing in the past with a 6602 and traditional NI-DAQ. I'd just add two more thoughts to go with his method:
1. You'll want to configure both the counters to be started by the same digital trigger signal so that their time information is synchronized, i.e., they both have the same "0" time.
2. You may need to watch for counter rollover, which occurs in less than a minute at 80 MHz. Not a real big deal, just a little thing to watch for when processing the data.
It could get a little trickier if your trigger signal is relatively rare (once or twice a minute or less). In such cases, you stand the risk of not knowing whether the counter rolled over between triggers or how many times. To help this problem, you could use a slower timebase (probably the 100 kHz) as a source for timestamping the triggers. There are other possibilties requiring the use of additional counters.
Other comments:
- Heed Mark's tip about group # if using Counter Config under traditional NI-DAQ.
- If you aren't heavily committed to traditional NI-DAQ, I'd suggest doing this with DAQmx. I admit that I struggled a while when making the switch but half of the effort was unlearning old ways. I've been using only DAQmx for all new development and I'd venture that for about 80-90% of the functions and features, I prefer it.
- (for academic interest only). It actually *is* possible to use the Z-index reload feature when configuring a counter for position/encoder measurement with a "two-pulse" encoder. You would simply hardwire one of the two inputs to digital ground, and configure the Z-index reload phase to "A LOW B LOW." There would still be two problems for the app in question here.
1. In encoder mode, the up pulse and down pulse must be signals wired to the counter's default SOURCE and AUX/UPDN pins respectively. You would need to somehow bring the internal 80 MHz timebase clock out to your terminal block pins. (I *think* but am not 100% sure that this can be done, but possibly only with DAQmx). Also, the reset signal must likewise be hardwired to the counter's default GATE pin.
2. The Z-index reload pulse seems to operate in a level-sensitive mode rather than edge-sensitive. As I recall from testing, if the trigger pulse remains in a HIGH state during several encoder pulses, the count keeps resetting after each one. One the other hand if it pulses briefly within the time that the A input is HIGH, no reset will occur. (Many industrial measurement encoders are designed to meet these Z-index requirements right out of the box.)
The more I think about it, the more I REALLY REALLY think there should be a setting that lets you reset a counter to a specific reload value on an EDGE of a software-defined GATE/TRIGGER signal.
Anyway, good luck with things.
-Kevin P.

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)

My pc sound level is very low on playback from dvd and most websites even though its at 100 percent

the playback level on dvd and most video streams is very low.(youtube seems ok)This is my second pavillion g7 w/ windows 7 .The first had a defective fan but the sound level was ok and there was a graphic eq section for sound control with other output options.I've yet to find that area on this pc in the month I,ve had it even though their identical computers.I,m at a loss for the cause of the problem.Headphones work fine but are annoying.

i use professional studio monitors to monitor the audio
the issue , is if i turn up the audio it will clip on premieres main output. so i cant turn it up any more.
the specific moment i took the screenshot the audio volume was at -18db, but even if it was up at 0db it would not even reach half volume on my computers main output
this is the case regardless of the nature of the audio, be it stock music, dialogue, or sound effects maybe there is a hidden master output that im unaware of

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

Doing Buffered Event count by using Count Buffered Edges.vi, what is the max buffer size allowed?

I'm currently using Count Buffered Edges.vi to do Buffered Event count with the following settings,
Source : Internal timebase, 100Khz, 10usec for each count
gate : use the function generator to send in a 50Hz signal(for testing purpose only). Period of 0.02sec
the max internal buffer size that i can allocate is only about 100~300. Whenever i change both the internal buffer size and counts to read to a higher value, this vi don't seem to function well. I need to have a buffer size of at least 2000.
1. is it possible to have a buffer size of 2000? what is the problem causing the wrong counter value?
2. also note that the size of max internal buffer varies w
ith the frequency of signal sent to the gate, why is this so? eg: buffer size get smaller as frequency decrease.
3. i'll get funny response and counter value when both the internal buffer size and counts to read are not set to the same. Why is this so? is it a must to set both value the same?
thks and best regards
lyn

Hi,
I have tried the same example, and used a 100Hz signal on the gate. I increased the buffer size to 2000 and I did not get any errors. The buffer size does not get smaller when increasing the frequency of the gate signal; simply, the number of counts gets smaller when the gate frequency becomes larger. The buffer size must be able to contain the number of counts you want to read, otherwise, the VI might not function correctly.
Regards,
RamziH.

New project: Every clip -- even the very first clip -- needs to be rendered. Why? I have no effects applied.

I just started a new project. Every clip -- even the very first with NO effects - has to be rendered. Why? I have used this exact same clip in other videos and had no problem. I tried other simple (no effects) clips and they all do the same thing. Could it be something in my initial project settings?This is for a funeral and I do NOT have time to wait till Sunday when Adobe Chat Help opens up again. PLEASE HELP!

So, perhaps I'm missing something. Yes, dragging a clip to "new item" corrects the problem for that clip only, but trying to add another other clips to that same sequence results in new clips still needing to be rendered. Dragging additional clips to "new item" simply opens a new sequence which I don't need. I need all the corrected clips on the same sequence.
1) How can I get corrected clips on the same timeline?
2) How can I keep this from happening on future projects? I did not change anything from previous projects. I simply opened a new project & named it. I'm not sure where things went so wrong.
I know this sounds tacky, but I have gained about 2 days to complete this project since they have decided to cremate rather than bury. Still need answers quickly though. THANK YOU!

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

Documaker : how to change text by count during overflow

Hi Experts,
Please help me...
I want to change a text in a section by overflow count.
Summary that I have set are as follows.
1. FormA (contains Subform1)
2. Subform1 (contains Subform2)
3. Subform2
Subform1 on FormA is setting the overflow with the trigger by the XML.
Search Mask (counter) : !/xxx/data/Repeats/Repeat
Subform2 on Subform1 is setting that always repeat 3 times.
Reference :
Documaker : How to set the overflow repeated 3 times always.
I created DAL scripts as follows.
1) To setgvm CTR.
---> Section_HEADER on Subform1 has a field that setting this script.
2) To return GVM(CTR).
---> Section_TEXT on Subform2 has a field that setting this script.
3) To increment GVM(CTR) by 1.
---> Section_TEXT on Subform2 has a field that setting this script.
This counter has been running without any problems.
I tried to set as follows.
4) To change text by GVM(CTR)-1.
if havegvm('ctr',1)
varctr = gvm('ctr',1)
if varctr-1 = 1
return("A")
else if varctr-1 = 2
return("B")
else
return("C")
end
else
return("")
end
---> I placed a field (call this "OUTPUT_TEXT") that is set this script in Section_TEXT on Subform2.
This setting is working.
BUT, I want to output the Double-byte characters at OUTPUT_TEXT field.
I can not input the Double-byte characters in DAL Script. (If I input, DMStudio was shut down...)
By placing 3 text areas in Section_TEXT, I thought of setting the trigger switch by count of overflow, but I could not set.
By count of overflow, is there any other ways to solve this problem?
Thanks,

Sorry, I resolved this...
I created 3 triggers and set it for 3 text area.
A trigger is as follows for *1* text area.
if havegvm('ctr',1)
varctr = gvm('ctr',1)
if varctr = *1*
return(1)
end
else
return(1)
end
return(0)
And, I moved the increasing count field to most right position in Section_TEXT.
+3) To increment GVM(CTR) by 1.+
---> Section_TEXT on Subform2 has a field that setting this script.
It is able to switch text areas by count.
Thanks,

Buffered edge count FIFO overflow even at very low rates

Similar Messages

Maybe you are looking for