Duplicate count prevention encoder
Hy,
I am acquiring an analog input and a signal from an encoder so I have a xy graph with analog input vs rotation. I have noticed that in order not to have duplicates of the values of the rotation I have to reduce the sample rate(the same for the 2 signal as they are synchronised)as much as the speed I want to measure is low. The problem is that I have some duplicates the same and I don't know if it's normal that for each speed i have to change the sample rate. I tried to use douplicate count prevention but it doesn't work. I attache my vi.
Thank you guys in advance!
Attachments:
labview.vi 146 KB
Hi,
I suggest you to take a look to a cauple of example, merge theme properly and route the AI sample clock externally to the counter sample source pin.
A first example shows synchronized acquisition between a digital channel and an analog input channel, very similar to your application (but with a digital channel instead of a counter).
To find him:
1. In LabVIEW, navigate to 'Help'->'Find Examples' from the main menu.
2. In the 'Browse' tab, and browsing 'According to Task'
3. Navigate to 'Hardware Input and Output'->'DAQmx'->'Synchronization'->
'Multi-Function'
4. Find example 'Multi-Function-Synch AI-Read Dig Chan.vi'
A second example shows how to measure encoder position with an external clock.
To find him:
1. In LabVIEW, navigate to 'Help'->'Find Examples' from the main menu.
2. In the 'Search' tab type 'Encoder' within 'Enter keyword(s)'
3. Find example 'Meas Angular Position-buffered-Cont-Ext Clk.vi'
You could properly merge these VIs and export AI sample clock externally to the counter sample source pin.
To export the clock you can read this KB:
KB - How to Export the Internal Analog Input Sample Clock
http://digital.ni.com/public.nsf/allkb/3A7F1402B2A1CE7686256E93007E66C0?OpenDocument
I think that this solution should work.
L
Similar Messages
-
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. -
Each song on my iTunes has a duplicate. How do I delete all duplicates and prevent this from happening again in the future?
After I had updated to Itunes 11 (also on Windows 7), I had the same experience, but I suspect that it was because I accepted a proposal to set up an external media library in order to simplify security backups. An associated result was that I had lost all of my playlists!
What I did was to restore the entire library off my Ipod, using a very good program called PodToPC (a free download is available) selecting an option to replace all of the stuff in the Itunes library. I use the Ipod Classic simply because it has a large capacity to hold my collection of CD and Vinyls. No way was I going to modify duplicates of 10000 tracks in 750 playslists by hand! I did have a few residual problems with some of the playlist specs but, after a few hours of work all was restored.
I hope this is useful. -
Problem in finding the Duplicate as well as Non-Duplicate count
Hi,
I have a scenario where I have a table TABLEA which has 3 values
10 ABC
10 ABC
20 DEF
I want to pick up the duplicate count as wel as non duplicate count:
I have used the following query:
SELECT COUNT(*) FROM TABLEA A WHERE A.ROWID > ANY (
SELECT B.ROWID FROM TABLEA B WHERE
A.CODE=B.CODE)
But I am finding problem in getting the non-duplicate count .
Any help will be needful for me
Edited by: user598986 on Sep 23, 2009 11:32 PMuser598986 wrote:
Hi,
I have a scenario where I have a table TABLEA which has 3 values
10 ABC
10 ABC
20 DEF
I want to pick up the duplicate count as wel as non duplicate count:
I have used the following query:
SELECT COUNT(*) FROM TABLEA A WHERE A.ROWID > ANY (
SELECT B.ROWID FROM TABLEA B WHERE
A.CODE=B.CODE)
But I am finding problem in getting the non-duplicate count .
Any help will be needful for me
Edited by: user598986 on Sep 23, 2009 11:32 PMHi,
perhaps this query makes your job:
HR: XE > select * from test_;
NAME SALARY HIRE_DATE START_DAT END_DATE
15-SEP-09 15-SEP-09
15-SEP-09 01-DEC-09
john 27-AUG-09 16-SEP-09 16-SEP-10
28-FEB-09 20-SEP-09
Dave 2 17-JUN-08 16-SEP-09 02-JUL-11
1000 21-AUG-82 08-MAY-10
6 rows selected.
HR: XE > select count(hire_date), hire_date from test_
2 group by hire_date;
COUNT(HIRE_DATE) HIRE_DATE
1 27-AUG-09
1 21-AUG-82
2 15-SEP-09
1 28-FEB-09
1 17-JUN-08
HR: XE > select count(id), id from
2 (
3 select hire_date, 'simple' id from test_
4 minus
5 select test_.hire_date, 'simple' id
6 from test_
7 where test_.hire_date In (Select hire_date FROM test_ GROUP BY hire_date HAVING Count(*)>1 )
8 union all
9 select test_.hire_date, 'double' id
10 from test_
11 where test_.hire_date In (Select hire_date FROM test_ GROUP BY hire_date HAVING Count(*)>1 )
12 )
13 group by id;
COUNT(ID) ID
2 double
4 simple
HR: XE > Regards,
Ion -
Is there auto detect duplicates to prevent copying in iTunes 11?
This seemed to be a legacy issue. So I'm wondering if the latest iTunes resolved this problem.
It is fine to be able to detect and delete but the point is it shouldn't happen in the first place. So I'm hoping the new iTunes is able to detect the latest and keep only the latest copy. Avoiding duplicates should be built into the system.
Also, it could be smarter when it says 'Delect Exact Duplicates' that it does exactly just that ie list the duplicates copies, not include the original or latest copy. That way you can select all the 'duplicates' and delete at one go.
I hope someone from Apple gets to read this. Thanks.
P/S: btw, 'Detect Exact Duplicates' will only show up AFTER you search for it in Help. Otherwise, only 'Detect Duplicates' shows. I think its a glich.Apple don't read these forums for feedback, that should go to iTunes Feedback.
Not creating duplicates in the first place is mainly a matter of organized workflow. If, before you rip one of your CDs, you check to see if you already have the album, then you can avoid creating duplicates. In fact iTunes will generally notice if you try to import the same CD twice. If, however, you import files ripped with another package into your library, and then decide to rip the CD with iTunes it probably won't make the connection.
I've written recently in this post on why you might end up with duplicates and how you might remove them manually, though you probably already know. I've also written a Windows script to automate the removal of two classes of duplicates. As a Mac user you could take advantage of the efforts made by Doug Adams who has scripts for most organizing iTunes needs and some software for duplicates in particular.
tt2 -
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 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.... -
Counting photomultplier TTLs per ms using the 6602
Hello all,
I have a question that seems related to Paul's (falkpl) (Or that he may know the answer to =)
http://forums.ni.com/ni/board/message?board.id=40&message.id=1883
I am trying to use the 6602 to make a histogram of continuous events in bins of 1ms.
As the subject of the post indicates, the events are TTL pulses from a photomultiplier tube. (variable frequency)
A key requirement would be to not miss any TTLs in between counts.
I've seen the timer examples and have picked up a lot from reading related posts like Pauls.
I am wondering if anyone knows the most accurate/precise way to implement this counting "setup"?
- Do I need an external gate to set the counter or is there a way I can use the 6602 to set 1ms counting bins?
- How do I ensure that the 1ms counting bins are as contigous as possible?
- I will probably need to change the timebase of counting so that it is not to fast (i.e. not counting noise) but is fast enough to satisfy the Nyquist criteria for these pulses. I am assuming this is easy.
I'm not sure if I need to use an internal or external gate to specify the beginnings and ends of the 1ms bins I'm counting with. I can also envision that I might instruct a counter to count for 1ms repeatedly, taking time only to read the counter value before starting again? I also realize that this is a frequency analysis of sorts, but I want to make sure I don't miss any pulses in between counts.
Somehow, I get the feeling this is a trivial question, as I would expect that this type of "frequency analysis" is used quite frequently.
Any ideas?
Thanks in advance,
MaxMax 90,
Sean's suggestion about buffered edge counting should work well and will be particularly handy if you want to know "at a glance" the cumulative total # of TTL pulses that have come in. You can find the pulses per 1 msec bin by doing a simple finite difference. Everything will be hw-timed, and you won't miss any pulses between bins.
Another possibility is to do buffered period measurement with the DAQmx units set to "Ticks." This would directly store the # of pulses during each 1 msec bin time.
Either way, you'll probably need to set the "Duplicate Count Prevention" property (buried down deep in the DAQmx Channel property node). I think the right setting is "True", but you can always try both True and False to see which works properly. One setting will actually store 0 values during 1 msec bins with no incoming TTL pulses, the other setting will simply ignore such intervals and only store a value during the intervals where there are 1+ pulses.
Finally a comment about your mention of "Nyquist criteria" in your original post. For most counter tasks, you wouldn't generally consider Nyquist criteria the way you would in an analog task. Consider your app: your 1 msec bins are the same as sampling at 1 kHz. However, it's apparent that you expect several TTL pulses to occur within some of those 1 msec bin times. So your signal can come in as fast as (perhaps) 5 kHz or more. If you automatically think of Nyquist, you might too quickly decide to sample at >10 kHz, which is both unnecessary and actually unhelpful for your app.
-Kevin P. -
Counting TTL pulses within specified integration time
Dear all,
I have a PCI-6014 board, and I use Labview 7.1 and would like to do the following task with DAQmx7.4:
Analog source: analog square wave (or = 1Hz TTL pulses) produced by a function generator
Signal: photon signals from a photomultiplier (random TTL pulses)
I would like to count the photon signals at 100ms integration time, repetitively. But I don't want cumulative counts, just the number of photons (TTL pulses) in every 100ms. I would also like to make sure that I synchronize the counter with the analog source, i.e. to make sure I get exactly 10 data points in each analog cycle. ( I can't use the computer to start the function generator and it just keeps running., so I want to make sure I start counting on the starting edge of the analog wave.)
I used to do this with the traditional DAQ and connected the analog source to the "GATE" pin of the counter , so i could count "while gate is high" ( or while gate low, or count on rising edge/ falling edge. ) However I found some problems and I think my counter wasn't counting correctly, and I would like to rewrite the task with DAQmx anyway. Ideally I would like to separate the signals that occur in the first 1/2 and the second 1/2 of each analog cycle. But if that is not quite achievable, I can do the separation later when I process the data, provided that I know each 10 data points from the counter correspond to each analog cycle.
I have read several threads on the discussion board, but I still couldn't configure my applications using those examples.
Also I wonder if the "Arm Start Trigger" function is not available on my PCI-6014 card ? Because I can not find it in the Start Trigger property node.
Thank you very much for your reply. Any hint or advice would be greatly appreciated.
Joyce...(Continued from prev post due to 500-char limit)
Now, here's a proposal for a method that should be able to work, though it'll require more data and more processing. One key area to watch out for under DAQmx is the property node for "Duplicate Count Prevention." The behavior changed between 7.1 and 7.3 (on E and/or M series, but not on TIO-based counters), then the defaults changed in 7.4, and something changed yet again in 7.5
Bottom line: you can set it to True or False. One setting will allow you to buffer up 0 values for intervals where there are no Source signals (photon events) within a sampling period (10 Hz hw clock). The other setting will not record anything in the buffer for those intervals. Clearly, you need the former setting, so you can always experiment to see how it behaves. I kinda gave up on trying to interpret it, understand it, or keep up with the differences by DAQmx version and DAQ board.
Ok, here goes: I'm going to propose that you actually oversample by about 10x and that you capture the Analog square wave in sync with your photon counts. Then your post-processing can determine for sure which samples correspond to Analog Square High and which to Low. You'll also be able to adjust for times when you get 1 too many or one too few samples in a square wave cycle, due to having independent un-sync'ed timebases.
So on one counter you generate a 100 Hz clock. The other one is programmed for buffered period measurement using the 100 Hz clock as a SampleClock and the photon pulses as the Source signal (this must be set up using a DAQmx Channel property node I believe). Remeber to be careful also about the DuplicateCountPrevention property.
You would further setup an AI task using the same 100 Hz clock as a Sample clock. Be sure that the 100 Hz clock task is started after starting both the other tasks. Also, be sure to always read the same # of samples from both tasks to keep the counter period and AI data in sync.
Voila! You now generate a data record of # of photon pulses for each 10 msec interval along with the voltage of the analog square wave at the end of that interval. A bit of post-processing and you're covered. If you're not required to manipulate data while the acq tasks are running, you can surely afford to bump up the oversampling rate considerably. The main advantage is to gain resolution on the time of transition of the analog square wave. For any interval ending with a TTL state change, you won't know where within that interval the transition occurred.
-Kevin P. -
NI 6259 photon counter min pulse detection
Hello,
I have a PCI 6259 DAQ card which I'm using as a counter. Is there a limit to the minimum pulse width it can count while operating as a counter? My photon counter gives out TTL pulses with widths of 50ns which I think is below what the counter can read unless I am mistaken. I'm using the 100kHz internal clock as the clock source. Is there anyway to get the counter to pick up such small pulses?
Would the NI PCI 6120 DAQ card be a better choice for this type of measurement? I should be able to get my hands on one shortly.
Thanks for your time,
Mark.
Solved!
Go to Solution.A 50 ns pulse corresponds to a 20 MHz freq. You should be able to capture/measure such a TTL pulse with a 6259, but I don't think you'll really want to be measuring pulse *widths*. You'd only be able to get a nominal count of 4 timebase edges per width with a possible +/- 1 count uncertainty, i.e., 25% measurement error.
More likely, you'd either want to:
1. measure the period/frequency of successive rising edges of these 50 ns pulses, effectively timestamping every detected photon. Brief fast bursts of photons may produce an unrecoverable FIFO error. A newer X-series device with a bigger counter FIFO would be a better choice if this is an issue.
OR
2. perform "binning" by counting the # of these 50 ns pulses that occur during equal time intervals. Here you are pretty immunce to brief bursts of photons, but you need to sustain long-term throughput over the PCI bus. You're probably pretty safe sampling at <= 100 kHz or so, but if you need better precision on the bins & thus faster sustained throughput, I'd again recommend a PCIe X-series board.
You might also have to watch out for a feature known as "Duplicate Count Prevention" which could impact your measurement data if you ever have 0 photons in a given interval. The faster you sample, the more likely this is to come up.
-Kevin P -
I am trying to use gated event counting or single pulse width measurement techniques to count TTL pulses on two counters during an external gate pulse. The problem is that if zero TTL pulses (a possible condition) go to both counters during the gate, the "armed" attribute does not seem to change from "yes" to "no", allowing the vi to kick out of a while loop and read the value that the counter stored.
Is there a way of setting up the counters so that
1) both counters only collect counts during an external gate
2) zero counts are allowed
3) the counters change state from "armed" to "not armed" at the end of the gate pulse regardless of whether there were TTL pulses on the source channel during the gate?
Thanks,
-MartinBased on your description of the application, I assume that you are using traditional DAQ. If you have an application where you sometimes expect to have zero source pulses between gates, you should enable synchronous counting (ND_COUNTING_SYNCHRONOUS) (referred to as "duplicate count prevention" in DAQmx). Many of the examples in traditional daq have this as an option that can be enabled on the front panel.
I hope this helps!
gus.... -
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. -
Externally trigger binned counting
Hi,
I have a PCI-6221 and am trying to achieve the following. I've tried searching and found similar questions, but nothing exactly the same, so apologies if I have overlooked a previous answer.
What I would like to do is count total pulses per 100 µs for some fixed period of time, say 100 ms. The start of the 100 ms total measurement period should be triggered by an external signal which is much slower, e.g. 1Hz This is as I need to sum multiple mesurement events as follows, where the time bins given are times after the trigger signal and each measurement is triggered by the external signal.
Measurement 0-100µs 100-200µs 200-300µs etc.
1 2 1 0
2 1 2 1
3 2 1 1
4 0 1 0
total 5 5 2
If I could get the rolling total for each measurement that would also be fine, I can subtract each time bin from the previous in software. The previous example using this method would therefore be:
Measurement 0-100µs 100-200µs 200-300µs etc.
1 2 3 3
2 1 3 4
3 2 3 4
4 0 1 1
total 5 10 12
I have looked at previous answers such as http://forums.ni.com/ni/board/message?board.id=40&message.id=2056&query.id=1096458#M2056 and whilst I converted that to a finite number of measurements OK, I couldn't work out how to set it to digitally trigger without errors. I'm using LabView 7.1.
Thanks very much, I hope that this was clear.
AlexI haven't fully fleshed out this idea, but here it is in a think-out-loud form.
I'm assuming you don't have clocked analog output in your app, and will lean on using an AO task solely for its clock.
Here's the idea:
1. One of your counters is set as a retriggerable single pulse generator. Let's say it's CTR0. Use the external ~1Hz signal as its trigger, and set it up to generate a single pulse with a 100 msec high time and a minimal low time. You'll need a DAQmx property node to make it retriggerable.
2. Configure an AO task to generate at 10 kHz, corresponding to your 100 microsec bins. Configure it to be pause triggered by the output of CTR0. Thus, the AO generates samples at 10 kHz, but only while CTR0 output is high (for 100 msec). You'll have to write a buffer of analog values to generate, but it can just be an array full of 0 voltage, and you don't have to wire that output to anything either.
3. Configure your other counter, CTR1, for period measurement. This may be tricky to configure with DAQmx property nodes, but ultimately you'll need to treat your pulses of interest as the timebase for the measurement while using the AO sample clock as the signal to be measured. That sounds backwards, but the effect will be to store the number of your pulses of interest that occur between AO clock edges. You will need to research "duplicate count prevention" to make sure that 0 values get buffered properly.
I *think* that sort of arrangement could work. About every second, you get an external trigger. That trigger causes CTR0 to generate a single pulse with a 100 msec high time. Your AO task generates a clock pulse every 100 microsec, but only during the 100 msec when CTR0 is high. Each of those AO clock pulses buffers a value for your CTR1 period measurement. This should produce a measurement buffer like the first one you listed.
4. (Simpler Alternative) Configure CTR1 for simple counting. Use DAQmx Timing.vi to specify the use of the AO Sample clock, and specify your external pulses of interest as the signal to measure. By default, LabVIEW will expect to see those pulses at CTR1's default SOURCE pin. This arrangement should produce a measurement buffer like the second one you listed, though you may still need to research "duplicate count prevention" to make sure that gets set up right.
5. I can't help but think there's another way to do this without the AO stuff, but nothing's coming to me now.
-Kevin P
Message Edited by Kevin Price on 02-01-2010 02:19 PM -
Counter roll-over when measuring period
Hi,
I'm using PCI-6251 counter 0 to continuously measure the period of a signal, and I notice there are occasionally error readings. Since the counter can roll over when it reaches 2^32-1, I need to know what will happen to the period measurement when counter roll overs. Would anyone please help me?
Thanks.
DavidThe count value will simply wrap-around back to 0 and then continue to increment. I can think of a few ways to handle this:
1. Specify a slower timebase for the measurement. If you go from, say, 80 MHz to 100 kHz, it'll take 800 times as long a period to cause rollover. This method is pretty simple to implement, but not all apps can accept the loss in precision.
2. You can use a 2nd counter to be sensitive to the 1st counter's "terminal count". This gets a bit complex, so you may need to do more research on some of the terms that follow.
An internal pulse signal is generated on the board when the 1st counter rolls over from 2^32-1 back to 0. It's commonly known as "terminal count" or TC. You'll need to configure a 2nd counter that also measures periods of your external signal, but which uses those TC pulses as its timebase signal. You may need to fiddle with the "Duplicate Count Prevention" property on the 2nd counter so that it will buffer values of 0 during the majority of intervals where no TC pulse occurs. During the intervals where rollover happens, the 2nd counter will count how many times it happens.
You would further need the 2 counters to be started off a common "arm start" trigger to keep their data sync'ed.
3. Software method. You can query the DAQmx Channel property "Counter Input -> General Properties -> More -> Terminal Count Reached". When you get a 'True' output, the property resets such that subsequent calls will return 'False' until the next rollover occurs. The problem here is trying to correlate this software-detected rollover with a specific period in the 1st counter's measurement buffer. You'd probably also need to be querying and tracking the DAQmx Read property for Total Samples Acquired both before and after the TC event. Even then you might not always be able to determine unambiguously which interval had the TC event.
-Kevin P. -
Is it possible to count '0' events with 6229?
I have set up a buffed edge counting which works fine with our E-series
boards. Using a new NI 6229, however, the same program returns
minimally 1 count.
It seems that in the case that the signal frequency is
lower than that of the timebase (in our case ctr0 is producing pulses at a
frequency of 1kHz, ctr0out->ctr1gate, signal to be measured arrives
at ctr1source) the card completely ignores the timing. Example: with
1kHz at the gate I would expect to read 1000 datapoints per second; if
the signal runs at a lower frequency than 1kHz I read a number of
datapoints corresponding to the signal frequency (all value "1").
At higher signal frequency it seems to work as expected.
I have tried a different BNC-2110 box and switching the order of the
counters (ie using ctr1 as timing device and ctr0 as the actual
counter), but this problem remains.
The cabelling has been done according to the NI-6229 port/pin scheme
found in the documentation directory of Labview. (ctr0out is BNC on the
box, ctr1gate=pin41=PFI4 on the box, ctr1source=pin42=PFI3 on the box;
for opposite configuration ctr1out as on box, ctr0gate=pin 3=PFI9 on
box, ctr0source=pin 37=PFI8 on box).
I would be very thankful for any help with this,
Gerhard
my apologies for the cross-post, but I put this question first up in the wrong discussion board.The behavior you are seeing when no edges occur on your event counting terminal are the result of not enabling duplicate count prevention. In DAQ 7.4, the default behavior of duplicate count behavior should enable this for you by default, but if you cannot upgrade to DAQ 7.4, I'd enable "duplicate count prevention" attribute. There are a number of previous posts about this attribute, including this post.
I hope this helps!
gus....
Maybe you are looking for
-
Since 1.0.1 - no longer have choice of Passcode or Hex/ASCII key
Since 1.0.1 update I no longer can tell the iPhone that my WEP password should be treated as a Hex/ASCII key. I'm able to successfully connect to this network from my Macbook no problem. I tried putting a $ before the password to no avail. Any though
-
FTP adapter --- Not picking up files
Hi, I have set up an FTP adapter in archive mode to read files from FTP server and process it while archiving a copy of it. I have set up Poll interval at 40 secs and retry interval also set up. It works great the first time . Processes the file and
-
I've set that password long ago and now forgot on how to remove it. Should I go to Apple store for this?
-
Error using edit in Photoshop Elements 8
When I click on the edit button I get the following error. Searched the forum and found no answers. Any one have any suggestions? I did reboot and tried again. Thanks
-
Does iMac or MacBook need anti-virus?
Wondering if I need to get software. I'm new to Apple and I hear that the OS really doesn't lend itself to attack. Comcast offers a free package - is it worth it, or does it just slow things down in the background for no real benefit?