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

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.

Buffered counter output in C

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,
Stefan

It'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

Buffered counting and 6602

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 Elam

Hi 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 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?

Synchronize hardware timed buffered counter acquisition with buffered analog input acquisition

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 KB

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

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,
Josh

Thanks 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

PCI-6220 COUNTER (Labview): Does "Sample Source" = "Gate Source"?

Hello,
I'm using Labview, DAQmx, PCI-6220 (Counter0). I connected an incremental encoder signal to the source input of CTR0. In Labview, the "DAQmx Timing" vi requires that the "source" input be wired. Does this "source" actually mean the source of the sample clock vs. the "Source" input to the counter?
Thanks for your assistance,
Chris

Chris,
When you talk about using a DAQmx Timing vi, I assume that you are performing
buffered event counting or any other task that performs buffered acquistion.
You can see an example that performs buffered event counting in NI Example
Finder called Count Digital Events Buffered - Continuous. The DAQmx
Timing vi in this example is used to read the current state of the counter
into memory at a constant rate. The source input of the Timing vi in this
case means the source of the sample clock. This clock is what determines
when the counter state is read and stored into a buffer.
If you are performing event counting, and do not need buffered acquisition (no
sample clock), you can look at example Count Digital Events.vi in Example
Finder. In this example no DAQmx timing vi is used.
Regards,
Jesse O.
Application Engineering
National Instruments
Jesse O. | National Instruments R&D

Serious bugs in the SR400 gated photon counter LabVIEW drivers

Hi
I am developing an application with SR400 and came
across what I think is a bug in the LabVIEW driver. Essentially, none
of the VI's allow you to set the preset counters. For instance, if you
call Read VI and choose mode A, B for preset T, there is no way to
specify preset T, which means that the count period defaults to some
factory default, not a situation you want. This might also explain some
of the timeouts some people are getting to SRQs that come later.
Further,
if you look at the block diagram of Read VI, the line selector string
is set to "CM 0" for two distinct choices of the count mode. This is a
serious bug. I do not know who wrote this driver, but it does seem, at
least to me, that they did a rather shoddy job of it. How this driver even got certification to be posted at IDN is something I cannot explain.
Comments welcome from those that use LabVIEW with SR400 and have used this driver.

Hi. Dwell time of 2ms is good for me. It would be great if you can send me this file to circumvent the 2000points/measurement. Also, If i understand it right, if I set the Gate to CW, then my gate should always be open for the count period, they why do I have to set the gate parameters at all. I want to change the integration time, but for some reason I am not able to change it in your setup 2.VI at all. I made some changes in setup 2.vi. I removed the setting for channel B as I am not going to use it and I integrated the readchannel.vi into this file. I am not sure if I made a mistake in doing this. Now, I am able to write some data to a file, but I not as I want. If it helps, I am uploading my modified VI file and an example data file (Gate A width is 0.992s, Gate A delay and delay step are 0, Gate A mode is CW, Dwell time is 0.002s).
Attachments:
SR400-V.vi.vi ‏125 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,
rgames

Hi 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

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

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

One 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

Timing / buffering problems

Hi, I am trying to operate the SRS SR400 photon
counter using LabView. I have an optical chopper as the external
trigger and I am using both channels A and B in a gated way. Basically
I can get the photon counter to operate perfectly, but if I collect
only one data point at a time in Labview, the data displayed is that
recorded on the photon counter 7 counts previously. If I ask LabView to
record say ten counts, I generally get 9 of the same number repeated
(the same number which appeared on the SR400 7 counts previously) and
the a random 0 or 6. I am using a new NI USB-GPIB card to interface the
PC and SR400. I am sure the problem lies in some buffering or
handhsaking issue, but I'm relatively new to LabView and can't figure
it out. Any help will be greatly appreciated!
The code I'm using is attached
AllThatStuff.vi (76 kb)
SR400 Read_e2.vi (130 kb)

Greetings efcloos
I don't know which discussions Khlume was referred to. However, I looked for the driver in the NI website and noticed that it is not NI certified. Which means the driver is probably incomplete and hasn’t been tested. So what I did is find some discussions related to the driver:
http://forums.ni.com/t5/LabVIEW/SR400-change-from-GPIB-to-serial-RS232/td-p/2474706
http://forums.ni.com/t5/Counter-Timer/SR-400-gated-photon-counter/td-p/519716
http://forums.ni.com/t5/LabVIEW/Serious-bugs-in-the-SR400-gated-photon-counter-LabVIEW-drivers/td-p/...
But also I will give you these links, which I believe will be more helpful to you.
http://www.ni.com/white-paper/3271/
http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/modification_instruct/
Write back if you have additional questions.
Regards.
Luis J.
Applications Engineer
National Instruments

Buffered counting labVIEW 5.0

Similar Messages

Maybe you are looking for