Buffered counting 6008
Hi to all
Is here some one who can tell me how i can make a buffered counting of the pulse count
This make sure i have a correct speed count/time
The problem also is that i also need to see on meter how fast the speed is i want to count as fast as possible ,but the meter must run at normal slow speed
Sorry guys i am new to labview to please do not be so hard on me ,
Any one who could help me?
i want a TDMS file
Attachments:
snelheid wielen].vi 28 KB
mm
strange on page 6008 specs
http://sine.ni.com/nips/cds/view/p/lang/en/nid/14604
here its says
Buffered Operations
Yes
is counting not a operation?
Similar Messages
-
How do I use the buffered counting mode at a fixed frequency?
Hi-
I'm using a PCI-6259 M-series board with the Nidaq MX
drivers in Labview 7. I am trying to use one counter to do
buffered edge counting (eg. count how many pulses appear on one input
in 400 successive time bins of 10 uS each following a digital start
pulse). That is, my inputs are:
Start Pulse (from experiment)
Count Pulse (from a photomultiplier tube in the experiment)
And I want to know:
# of pulses from 0 to 10 uS after the Start Pulse
# of pulses from 11 to 20 uS after the Start
Pulse (or, equally good, # of pulses from 0 to 20 uS....I can
subtract later)
# of pulses from 3991 to 4000 uS after the Start Pulse (or, # of pulses from 0 to 4000 uS...same thing)
The Count Digital Events-Buffered-Finite-Ext Clk.vi sample
appears to do half of this. I can set this up CTR0 with the Count
pulse (and possibly add the start pulse as an Arm Start....I can't use
a Start Trigger, right?). However, I need to generate a Sample
Clock Source at 100 kHz (to trigger the card to buffer the counter
value and start counting in the next bin). So, I tried to set up
CTR1 along the lines of Gen Dig Pulse Train-Finite-Dig Start.vi for
generating a finite pulse train starting on a digital trigger, and
connecting the output from CTR1 to the Sample Clock Source on
CTR0. However, I get an error -50103 saying the specified
resource is reserved if I do both at the same time. But, I can't
see any resource conflicts...the pulse generation on CTR1 works fine
alone, as well as the buffered counting on CTR0, and all the PFI pins
are different. Is there some reason I can't use both counters at
the same time?
I think I can use the FREQOUT pin on the card to generate a Sample
Clock Source at 100 kHz, since I think this is independent of CTR0
& CTR1. However, I can't trigger the FREQOUT to always start
when I get a Start Pulse (as I can if I trigger a Digital Pulse Train
to start on a digital trigger...or can I?)...so my bins will move
randomly by up to 10 uS.
This is an unrelated topic, but is there a discussion of
the relationship between the terminology in the manuals describing the
cards (SOURCE, GATE, OUTPUT terminals) and the terminology in NidaqMX
(Source Clock/SrcClk.Source, CI.CountEdges.Term, CO.Pulse.Term)?
Eg. is CTR0.GATE always the same thing as SrcClk.Source, or does it
depend on the mode of operation? If the M-series hardware manual
says to connect something to the SOURCE input, how do I assign an
alternate PFI pin to that SOURCE input in Labview? Does it depend
on the counter type, or is it always the same?Dave,
Hi, you brought up several questions / issues -- let me see if I can help with some of them:
I can set this up CTR0 with the Count pulse (and possibly add the start pulse as an Arm Start....I can't use a Start Trigger, right?).
Yes, you could set up this way. Also, as far as I know you're also correct that you need to configure for an "Arm Start" trigger using the DAQmx Trigger property node. The "Arm Start" trigger is used for counter input (measurement) apps while the regular "Start Trigger" can be used for counter output (pulse generation) tasks. I don't think I've experimented with recent versions of DAQmx though so it may have changed in 7.4 or 7.5
...I tried to set up CTR1 along the lines of Gen Dig Pulse Train-Finite-Dig Start.vi for generating a finite pulse train starting on a digital trigger, and connecting the output from CTR1 to the Sample Clock Source on CTR0. However, I get an error -50103 saying the specified resource is reserved if I do both at the same time
I highlighted the problem -- the FINITE pulse train. DAQmx uses CTR0 as a "helper" when you generate a finite pulse train on CTR1. It would generate a single pulse whose width corresponds to the exact amount of time needed for CTR1 to generate its specified # of pulses.
For your specific app, I think you could generate a triggered continuous pulse train with CTR1 -- this wouldn't need to use CTR0 as a helper. The Start Pulse would arm CTR0 at the same instant that CTR1 is started. If you set up CTR0 to acquire on the trailing edge of CTR1's pulses, then you'll get the time bins you want.
A final slight mod would be to setup CTR0 for measuring buffered periods (set units == "Ticks") instead of counting edges. In that mode, you wouldn't have to do the subtraction at the end.
This is an unrelated topic, but is there a discussion of the relationship between the terminology in the manuals describing the cards (SOURCE, GATE, OUTPUT terminals) and the terminology in NidaqMX (Source Clock/SrcClk.Source, CI.CountEdges.Term, CO.Pulse.Term)? Eg. is CTR0.GATE always the same thing as SrcClk.Source, or does it depend on the mode of operation?
There's an NI app note and some discussion forum hits if you search the site for "daqmx terminology."
If the M-series hardware manual says to connect something to the SOURCE input, how do I assign an alternate PFI pin to that SOURCE input in Labview? Does it depend on the counter type, or is it always the same?
Usually, that choice would be available under the DAQmx Channel property node. There'll be some place to define where the input signal is coming from, generally with "Term" or "Terminal" as part of its name. Sorry I can't be more specific as I'm not at my LV computer now.
Happy counting!
-Kevin P. -
LV7.1
DAQmx
PCI-6036E
SC-2345
Windows 2000
Greetings.
I am simply trying to synchronize AI readings with readings from one Counter.
I am trying to perform buffered analog input synchronized with buffered counter acquisition.
I'd like the AI acquistion to trigger the Counter acquistion.
I'm currently setting the Sample Clock Source for the CI Cnt Edges Task to "Dev1/ai/SampleClock" but when I try and set the source for the "DAQmx Trigger" I can't seem to select one that works. I assumed that the source should be the "Dev1/ai/StartTrigger" but that produces and error as does selecting any of the PFI's.
I'm new to DAQmx and didn't have any luck with the examples or what's been previously posted.
Thanks for your help.
Attachments:
Initialization.jpg 84 KBGentlemen-
All of your initial help was great. I had some noise on my counter lines so switched from an E-Series card to a PCI-6259 M-series card in order to use the counter digital filters.
Now I can't get a corellated buffered counter and buffered analog input acquistion to work. This same code worked fine on an E-series card but it doesn't on the M-series.
I verified that the source and gate of the counter are working properly using the test panel and a external function generator.
But when I run the attached code I get no data out of the "Counter 1D U32 NSamples", only an error saying that the timeout of the function was reached and no count data became available. Am I missing the specification of a another clock or something?
The counters also work fine using the M-series example code "Count Digital Events (M-Series DAQmx) but this is not a buffered acquisition.
Any help would be greatly appreciated.
Steve
Attachments:
Sample_Code.jpg 136 KB -
Retriggerable buffered counting edge task
Dear all,
I have been working on "Retriggerable buffered counting edge task" on a single counter input channel, let me describe what I want to achieve:
Create a CI to count finite rising edges with external sample clock (eg. Dev1/di/SampleClock) at certain sampling rate, and set CI.edge.Term at one PFI which is hardwired to another digital input channel. Furthermore, I'd like to set "retriggerable start trigger" to this CI by another PFI line.
It turns out that I can only set "arm start trigger" on this counter input channel, instead of "start trigger" since the error of 200452: attribute not supported in task context showed up at configuring digital edge start trigger. It seems that I can only set "retriggerable start trigger" on counter output task, and use two counters to achieve above, but I was wondering if there is a way to accomplish by single counter. Any suggestion is highly appreciated.
Solved!
Go to Solution.Dear John,
I just tried and run into another issue with overflow. The idea is to synchronize this counter with finite DI and to read both buffers out when DI's buffer is filled. Since I am running CI in contineous mode, it seems to be reasonable to run into overflow on buffered CI after a couple of triggers; Error: -200279 when trying to read CI buffer. Is there a way to skip/ignore overflow but still read buffer with size that I specified at attribute of SamplePerChannel? or any better idea of design to achieve what I am trying to do? I was wondering how effective it would be by increasing buffer size to avoid overflow since no known pattern on the trigger signal.
Really appreciate your help. Thank you. -
Benchmarks for Buffered Counter Input with X-Series Devices
Hi,
Does anyone know the maximum transfer rate (using dma) for the x-series cards?
I'm looking for data simillar to the one in this link:
http://digital.ni.com/public.nsf/allkb/72A7E41EE5A8756A862571DA0076F1D7?OpenDocument
More specifically I want to know the transfer rate for the PCIe 6343.
Thank you,
Eyal
Solved!
Go to Solution.I benchmarked 8MS/s on a single channel on a USB-6353 (should have similar performance to the USB-6356/66) with a buffered counter input task. This was only a 10 minute test on my Dell E6400 laptop ( Windows 7 32 bit, Dual core P8600, 4GB memory) so a sustained 24/7 rate is likely less. Also, I wasn't doing much with the data, just displaying it in an array. This is pretty much topping out USB streaming on this system (32MB/s) so I wouldn't expect to get higher. I wasn't running much else in the back ground (Explorer, Powerpoint, Lotus Notes) and CPU was at ~20%.
Hope this helps,
Andrew S
Getting Started with NI-DAQmx
Measurement Fundamentals -
Hi everyone,
I am looking for a possibility to generate a finite buffered counter output with varying pulse widths, using the X-Series. I am working in C / Python.
I want to output two pulses triggered to an external signal. The first pulse should be short, the second pulse long.
The following code outputs only two identical pulses. How can I modify it to output two different pulses?
CreateCOPulseChanTicks(channel,"","100MhzTimebase",DAQmx_Val_Low,0,300,300)
CfgImplicitTiming(DAQmx_Val_FiniteSamps,2) #output two pulses
CfgDigEdgeStartTrig(src,DAQmx_Val_Falling) #external signal
SetStartTrigRetriggerable(True) #retrigger
Best Regards,
StefanIt's good you found a workaround but the behavior doesn't seem right to me...
The default behavior in DAQmx (the C / LabVIEW / .NET APIs) is to regenerate data from the buffer. Perhaps the python wrapper you are using is disallowing regeneration somewhere? I tried this with regeneration disabled and it gives the same behavior you reported (though with regeneration enabled it does not).
You can use DAQmxGetWriteRegenMode to verify this theory and DAQmxSetWriteRegenMode to enable regeneration in case it is disabled.
Best Regards,
John Passiak -
Hello,
I am trying to run the vi 'Single Buffered Event Counting' using a
PCI6602 board. I have the vi set to use the internal timebase. It
seems to run , however it gets stuck in the While Loop. I don't
understand how the counter gets to be 'unarmed'. Perhaps there is
something I am missing. I also want to be able to write the data to a
file for later viewing. Has anyone written a vi to do this?
Thanks in advance,
Kristie ElamHi Jon,
I am trying to do some buffered counting and only read the data if a large number is available.
I attach a Labview version of what I am trying to do.
My program does not do anything means that the terminal count is never reached. If I remove this condition, I can actually read some data.
Thanks.
Attachments:
SingleTimeStamping_v8.vi 197 KB -
Buffered Counter Start/Stop
I am currently running an application requiring buffered counting
of high-speed events. I have a PC-6602, and I will be running three
groups of two counters each--one counter will run at 20 MHz for high
resolution timing, and the second counter in each group will count
rollovers of the fast counter to keep real time data. For neatness, I
would like to have three separate gruops of counters, but will they start
at the same time? I need all the counters to start simultaneously, and if
they are in different groups with different task ID's, how can I assure
they will all start at the same time?
Thanks,
JoshThanks for the response Filipe, I'll let you know how it goes. I only went into the header file because example code provided by NI ... paste ...
iStatus = GPCTR_Read_Buffer(iDevice, ulGpctrNum, ND_READ_MARK, ulReadOffset, ulNumPtsToRead, ulTimeOut, &ulNumPtsRead, pulReadBuf);
showed use of 8 parameters - in agreement with the header file and in disagreement with the on-line help file function documentation.
Tom -
Buffered counting labVIEW 5.0
I try to use the measure buffered period.vi with labVIEW 5.0 and my NI-TIO device is the 6601. The problem is that: I can find the vis used to run the measure buffered period.vi. i.e. Counter group config.vi, counter get attribute.vi .......
Augerspecto,
I am assuming that you are referring to the Measure Buffered Period.vi example included with LabVIEW. If the example is not finding the counter VIs when it is loading you probably need to check your NI-DAQ installation. Ensure that you have NI-DAQ installed and if you don't, you need to download it and install it for those VIs to be available (http://digital.ni.com/softlib.nsf/MainPage?ReadForm&node=132010_US). If you already have NI-DAQ installed then check to see if you have the VIs on your Functions Palette (Functions > NI Measurements > Data Acquisition > Counter). If you don't have the VIs on your palette then reinstall NI-DAQ and ensure that you install support for your version of LabVIEW.
Ames
Applications Engineering
National Instrumen
ts -
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 KBKevin, 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 -
How do I deallocate counter buffers?
I'm using a buffered counter operation for encoder measurement. I don't see a way to deallocate the buffered memory in Labview. How is this done?
When using the AI VI's, the AI Clear VI deallocates the memory used by the AI buffer. There must be similar functionality for the counter buffers.
Thanks,
rgamesHi rgames,
If you have sub VIs that are using your buffered memory, you can make a call to the Request Deallocation VI under Advanced >> Data Manipulation of LabVIEW 7.0. In previous versions of LabVIEW, there was an option to deallocate memory as soon as possible under Tools >> Options >> Performance and Disk.
Hope this helps!
Jeremy L.
National Instruments
Jeremy L.
National Instruments -
Counting TTL pulses at high speed
Hi all,
I am using PCI-6221 board with DAQmx to count the number of TTL pulses (which varies in its frequency between 0Hz to 10MHz) at a high speed (200,000 samples/sec.) and I am having a problem when the TTL pulse frequency drops below a certain level.
I am using CTR0 to generate continuous pulse train at 200kHz frequency to feed to CTR1 Gate input. I verified that the pulse train is being generated fine.
I am using CRT1 with buffered counting to collect the count for 200,000 samples at a time (duration of 1 sec.). I got the example code (Cnt-Buf-Cont-ExtClk) and pretty much used it as is.
CTR1 Gate is coming from CTR0 Out, which is 200kHz pulse train with 50% duty cycle, and CTR1 Source is the TTL signal that I am trying to count. At first, I thought that everything was working fine with the Source signal being at around 5MHz. Then, when I had the Source signal down below about 300kHz, I noticed that the program is taking longer than 1 sec. to collect the same 200k samples. Then, when I got the Source signal down to 0Hz, the program timed out.
I am guessing that somehow the counter is not reading for the next sample when there has been no change to the count, but I cannot figure out why and how.
Any information on this and a way to get around would be greatly appreciated.
KwangOne thing you can try is to set the counter input CI.DupCounterPrevention property, this setting will filter the input, it is possible that when the ctr 0 is slow then many of the values you are counting become zero as well and are filtered out, since they are nolonger points, the counter will not collect enough points before the time-out occurs and the counter input read times out. I am not sure if this is your issue but I found out the hard way that this occurs when I switched to daqMX where this feature was added. Let me know if it worked,
Paul
Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA -
X Series is here – New Counter Features!
Hey All,
The new X Series Multifunction DAQ devices have been announced – check them out here.
I’m posting here because I think X Series has several new counter features that many on this forum have been looking for. The user manual
will have all of these details and more with timing diagrams but I
thought I’d summarize a few of the sexier features and open it up for
comments/feedback.
First off – what stayed the same between
M Series/TIO counters and X series counters? The pinouts between M and
X series are the same so the PFI lines and default counter pinouts are
the same. The DAQmx programming is the same (you’ll need DAQmx 9.0, it
should be up this afternoon) and all the functionality that was
supported by M Series is supported by X Series, though a few behaviors
may have changed. Counters are still 32 bit.
Now on to
the fun stuff – the big one that I tend to overlook: X Series has 4
counters per board! They all have the same features and Freq Out is
still there too (with an additional 20MHz timebase).
Timebases:
X Series devices have 100MHz, 20MHz and 100kHz timebases. Note the
difference between 80MHz on M series and 100MHz on X series. DAQmx will
take care of the difference for you, unless you were programming in
terms of ticks and hardcoded in numbers based off of a 80MHz clock.
Counter
FIFOs: X Series has a 127 sample FIFO per counter. When combined with
PCIe/PXIe, our benchmarked buffered counter rates went from ~350k on M series
(with a 2 sample FIFO) with a single counter to 10MHz on all four
counters (160MB/s streaming rate). The FIFO also allows us to implement…
Buffered Counter Output: Probably my favorite new feature. You can
now use a multi point write on counters and write out a buffer of pulse
values. There are two timing modes for this: implicit and sample
clocked. With implicit timing, every idle/active pair you write is
generated as a pulse. You can vary the idle/active time for every pulse
in your pulse train. Check out the "Gen Dig Pulse
Train-Buff-Implicit-Cont.vi" shipping example. With sample clock
timing, the idle/active time are updated every time a sample clock is
received. Check out the "Gen Dig Pulse Train-Buff-Ext Clk-Cont.vi"
shipping example. These modes give you much more control over your
waveform – now everything about it can be hardware timed. Also, I’ve
benchmarked the output rates at 10MHz on all four counters at the same
time.
Finite pulse train with one counter: Each X Series
counter has an Embedded counter paired with it. The embedded counter
isn’t directly programmable, but it does allow you to do counter
operations on one counter that used to take two. A finite pulse train
used to take two counters – one to generate the pulse train and one to
gate it. Now a counter generates the pulse train, and its embedded
counter counts the TCs and disables the counter when it reaches the
number of pulses to generate.
More sample clocked
measurement modes: Edge counting and encoder measurements always
supported sample clocks, all other counter measurements were implicitly
(timed by the measurement waveform) timed. With the addition of the
sample clock terminal to the counters now all counter measurements
(except for semi-period) support sample clock timing. You can now get
the pulse width of the pulse just before the sample clock rather than
getting all the pulse widths and figuring out where they happened in
time. Why not semi period? We added a new “pulse” measurement instead
that returns a sample that contains the high and low time (or high and
low ticks, or frequency and duty cycle) so for each sample clock edge
you get a full pulse spec. Semi period still supports the same
measurements it used to, just not sample clocked. Speaking of sample
clocked…
Sample clocked frequency/period measurement
with averaging: X Series still supports the three frequency modes: Low
frequency 1 counter, 2 counter High Frequency and 2 counter Large
Range. In addition it supports sample clocked averaging. This is
essentially a method that is high accuracy method based on the sample
clock rate. With the same measurement time it has the same accuracy as
the Large range mode but it doesn’t take two counters. Note, counters
do not have their own internal sample clock so you have to provide them
with an external signal.
Hope this helps,
Andrew S
National Instruments
Multifunction DAQ Product Support Engineer
Getting Started with NI-DAQmx
Measurement FundamentalsHi guys,
I drew up a schematic of one of the applications I need to get running in our lab. To recap:
1) We have several piezo controllers for nanopositioning of samples under a microscope, some of them driven by a digital circuit that handles coordinate programming and trigger line programming (for syncing detectors to the piezo motion), other controllers are analog and need to be driven by voltages.
2) We would like to emulate the behavior of the digital controller using the analog HW (we have much more analog controllers than digital ones).
3) The basic implementation is like this (see also slide one in the attached pdf file) and runs perfectly:
a. A global pulsetrain ticks with a certain frequency
b. At each tick a voltage is written on an AO line and this tick is also sent to an RTSI line to sync multiple detectors
4) To fully emulate the digital controller we also need to implement 4 trigger lines that exist on the digital controller. These trigger lines allow for fully programmable pulsetrain output that is in sync with the movement of the piezo. Slide two in the attached pdf illustrates what is needed. These trigger lines allow for much more intricate syncing of our detectors (only measure during certain parts of the motion instead of all the time).
After a lot of thinking and experimenting with the existing M series boards back here I came to the conclusion that the desired behavior is not possible with an M series board since they only allow for the output of “simple” pulsetrains with a given frequency.
Looking at this webpage (http://zone.ni.com/devzone/cda/tut/p/id/9384#toc3) however, I think that the X series board would offer exactly what we need since it allows for buffered counter output that enables definition of very complex pulstrain “shapes”.
Looking at the schemes I provided, could someone confirm that the X-series covers our needs? If this is the case, we would be interested in purchasing these kinds of boards.
Cheers,
Kris Janssen
Attachments:
Raman Imaging Timing Implementation.pdf 76 KB -
Buffered aquisition with multiple counters on 6602
Here's the scenario: I have a 6602 card, and I need to do buffered event counting on five counters at once.
I can't use DAQmx, because the drivers don't support the 6602 yet.
The traditional DAQ drivers don't support multiple counters per group...
...so I'm left with needing to create five independent tasks, each responsible for it's own buffered counter operation. However, when I do this, each task gets assigned the same taskID, so I can't figure out how to differentiate between the tasks when it comes time to reading their respective buffers. I attached a quick example VI that shows the taskID problem.
Anyone know how to run multiple buffered counting operations at once?
-Michael
Attachments:
StartCTRsTIO.vi 80 KBHi M.J.
This example VI should exactly do what you want:
http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B45EACE3DC9F56A4E034080020E74861&p_node=DZ52325&p_source=External
Hope this helps,
Luca
Regards,
Luca -
it is OK for 2 counters if I count a defined number but I would like the values during a time for example 10 s .It seems that the acquisition is not complete.Is a problem of circular buffer, time out error .....?
Hi:
I am assuming that you are using 2 counters to generate a finite pulse train for 10 seconds and are using this pulse train to gate the other counter. If this is your setup, you should not have a problem in retrieving the correct number of readings.
You can monitor to the backlog and number read by wiring indicators to Read Buffer VI. Please also look at the Count Buffered Edges (DAQ-TIO).vi examples to learn how you can correctly set up a buffered counter acquisition.
To open up the example, click on Help -> Find Examples -> Hardware Input & Output -> Traditional DAQ -> Counter -> NI-TIO.
Regards,
Bharat Sandhu
Applications Engineer
National Instruments
Penny
Maybe you are looking for
-
Can someone please help. I have a really old MacBook that is running really slow. I want to wipe everything and reinstall the latest software but don't know how to do this. Also is there a way of keeping Microsoft Office when doing this? Thanks in ad
-
Purchase Order not getting saved
while creating Purchase Order iam getting the PO number while trying to change in ME22N system is throwing the error MSG *"Express document "Update was terminated" received from author "mm_SAP"* clicking on the inbox iam getting Transaction.. ME21N E
-
Here's a strange one that I can't find any documentation on. I hope someone may be able to help me. On my Late 2008 MacBook Pro I did a fresh install of Leopard from the included install discs. When I go into the Desktop and Screensaver settings pane
-
Creating a water Effect using AS3
Hi There I have created a water effect in Adobe Flash using AS2, however I now wish to create a flash application with the same effect but using AS3. Please see the attached code I have used to create the water effect using AS2. I am looking for some
-
I need the help of a host !!
My post under this thread : http://discussions.apple.com/thread.jspa?threadID=2581911&tstart=0 Is getting repeatedly deleted .I am trying to prevent a user from inserting a wooden toothpick inside a macbook pro's headphone socket . And no matter what