Photon Counting on 6321

I am attempting to count photons from 2 photomultiplier tubes (PMT) using Labview. I currently have written a program which will count from a single PMT. I was wondering if the manor in which I wrote the program will reliably count up to 1 MHz, which I believe the card can do, and if it is the best way to write this code. I am relatively new to LabView (esspecially counting).
The program is designed to take a count every 10 - 100 ms and store them for analysis later. I will at somepoint require a program like this to run for up to an hour. It would also be nice if the counter reset evertime instead of reporting the summation of the counts.
Using labview 2012.
Thank you,
A
Attachments:
Simple Count.vi ‏89 KB

Your 6321 has a max samplerate of 250kSPS , so if you need to measure your pulse energy and assuming 5 samples per pulse you can go up to 50kHz ....
(less since it's statistic)
And you will need some pulse shaping .... (a 7 step RC,OP buffer chain? )
Since it is a multiplexing card, make shure that your pulse shaping circuit has a low output impedance (more 1Ohm than 50Ohm and close to the DAQ)  (take a look at the settling time error in the spec)
Crosstalk between the channels need to be investigated.
Look at the examples about DAQ streaming TDMS data to file.
Think about a producer-consumer architekture. One loop is reading (producer) and one loop is saving (consumer 1) and two more loops take copied slices of the data to make online monitoring ...
If you just want to count the pulses, you can use the internal counter, up to 1Mhz shouldn't be a problem (again a fast pulse chaper, comparator needed)
Greetings from Germany
Henrik
LV since v3.1
“ground” is a convenient fantasy
'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'

Similar Messages

  • Sr 400 photon counter (stanford research system)

    hi,
    i need help regarding sr400 two channel gated photon counter(SRS)
    my problem is:
    i open getting start wizard ,it shows.
    hardware presence verified
    software  "        ''          ' '
    interface sequential verified
    upto here it is ok .but when i goto max and open NI488.2 communicator and write string in send string(*IDN?), IT GIVE ERROR
    iberr=EABO
    i tried the same with interactive control and when i write
    GPIB0: ibwrt" *idn?"
    it gives
    [c100] <errtimo cmpl>
    error: EABO
    count : 0
    so can u plz tell how to tackle that problem.
    thanks

    You need to understand the difference between the GPIB bus commands and instrument commands. You seemed to have looked at the basic example that's in the manual. The first line in the example does some things to the GPIB bus's interface management lines like interface clear (IFC) and remote enable (REN). You do not issue these commands in MAX's communicator when you want to program the instrument. Those sort of commands are available but you don't normally have to do any of that. You do need to issue the commands that are listed in the section on remote programming. The very first example listed is the command "CM". As the manual states, if you send CM {j} where {j} is 0-3, you set the counter mode. If you send just "CM", the instrument returns the counting mode. You will not get a response back from the instrument when you set something. You will only get data back from the instrument when you issue a specific command that tells the instrument to return something. Instruments designed within the last 20 years have better command sets than what you have to work with. These "newer" instruments use a "?" at the end of every command that tell the instrument to return data.
    Before you do much more, I would recomend that you do a little studying on the GPIB bus. There are some tutorials and app notes at : http://zone.ni.com/devzone/devzone.nsf/webcategories/3992D796622FADB1862567BD006DBD98.

  • SR 400 gated photon counter

    I don't have a ton of experience with Labview, but I'm trying to get the Stanford Research Systems SR400 gated photon counter to use a fixed gate mode to count.  I looked at the example driver that I found and realized that it isn't capable of doing anything more than a cw sweep.  I found this driver in the forums (http://forums.ni.com/attachments/ni/40/1879/1/sub​vI.vi), but in the process of updating to labview 8.2 (from labview 7.1 it said), it is missing some connections somewhere.  I was wondering if anyone knew how to find the problem pieces in it and how to fix it.  I have another question about the SR400.  Is labview capable of trigging it through the software, or do I need to have an actual physical trigger going in to the trigger input.  Thanks for your help.
    JOn

    Hey Jon,
    I'm unsure if the SR400 is able to trigger externally, but if in the manual for the SR400, you're able to find the command for it, you should be able to easily implement it. If it's GPIB communication, just open labVIEW, and go to Help->Find Examples->and Search for GPIB, and you should find a nice example called "labVIEW<->GPIB.vi". If it's serial communicaiton, just search "Serial" and you should be able to find a nice example called "Basic Serial Write and Read.vi". Just copy the triggering command if it's found in the manual into the write field, and you should have no problem implementing it. I like these two examples a lot, because they're easy to build from.
    Regards,
    Nick D.

  • 2d raster scan photon counting optimizati​on

    I have written a VI for a 2-D raster scan and counting TTL pulses from a photon counter at every pixel.
    It seems to be working fine and is serving its purpose for the time being. However there are a couple of thing I want to improve
    Currently, I have 2 loops, on within the other for each of the axes (x and y) for the scan. Then within the inner loop, I am counting the pulses. Now, the problem I am facing is that I have not figured out how to start the counter from 0 at every iteration. Instead, what I am doing is running the counter twice in a for loop and outputting the difference between these two iterations using shift registers.
    What I would like to do is avoid having to count twice for each iteration. I tried the start task and stop task vi but they seem to be doing nothing. 
    The other thing that would be nice is to avoid having the loops. I have heard that it is "expensive" to use the loops and they cause some overhead time in the program. I don't really think it is bothering me at this point but I think if I have to do faster scanning rates then it might. Currently I am scanning at >100ms per pixel. 
    (And also, just FYI, my raster wavefrom is slightly different in that in is a "triangle"instead of sawtooth. i.e. it goes to the end of the fast axis, then starts the next line from the end rather than the beginning to avoid sudden jerks to my hardware.)
    I have attached my VI. thanks
    Aditi
    Attachments:
    Galvo_Scan_Image 5.vi ‏92 KB

    I cannot help with your counter issues.
    The loops do have some overhead. It is on the order of a few nanoseconds. While loops are probably slightly slower than for loops because of the extra testing. Compared to your DAQ timing the loop time is completely negligible. Look at the test program below.
    Since you know (or can calculate) the number of steps, for loops are probably the better choice. I think the conditional for loop is available in LV 2011.
    You should probably move the AO Create channels VIs and associated Clear Task VIs outside the loops. Connect the task ID wires via shift register so that the value will be passed in the event someone enters start and end values which result in zero iterations of the loops.
    Generally to speed things up you want to move any calculations and any displays (indicators) outside the loops when it can be done without adverse impact on functionality.  For example the divide by two can be moved to the outer loop; the inputs do not change within the inner loop.  If you do not need to see every update immediately, reducing the number of writes to the Intensity graph amy speed things up a bit.
    Avoid right to left wires and wires behind other objects. These have no effect on program performance but they make it much harder to understand what is going on and to fine problems. I have attached a cleaned up version of your program.
    Lynn
    Attachments:
    Loop times.vi ‏12 KB
    Galvo_Scan_Image 5.2.vi ‏74 KB

  • PCI6602 to detect TTL output from single photon counter

    Dear all,
    I am learning how to use Labview.
    Here is the system I try to set up.
    1.   Single photon counting module, 2.5v TTL output, 20MHz light source
    2. BNC-2121 block
    3. PCI6602
    4. Labview 7.0, NI-DAQmx
    The aim of this system is to counts the number of the detected photons from the light source.
    I have problem to start this task. Can you guys help to creat a sample which i can start from?  
    Your help will be greatly appreciated.
    Frankie

    Hi Frankie,
    I would suggest using the NI-DAQmx counter shipping examples to get
    started.  The Count Digital Events VI would be a good starting
    point. 
    You can open it through:
     Help >>
    Find Examples >>
    Hardware Input and Output >>
    DAQmx >>
    Counter Measurements >>
    Count Digital Events >>
    Count Digital Events.
    Hope this helps!
    Micaela N
    National Instruments

  • 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

  • Photon counting

    Hi i am setting up a fluorescence correlation spectroscopy (FCS) experiment based on a home made confocal microscope coupled to a single avalanche photodiode (SAPD Perkin Elmer) that is able to count photon by delivering TTL pulses (2.5 V, 9 ns). To perform FCS or single molecule FRET experiment analysis I need to record photon count during several minutes. We have installed a PCIe 6361 with a connector box. I am a newbie in the labview "world" and I tried to record photon flux by using the attached vi. as you will see it is not really optimized in term of speed acquisition. it works well if i record 1 000 000 points with 1µs time resolution. unfortunatly for ma purpose it is definitively not enough moreover the NI card is a able to run 100Mhz.
    would it be possible to use some tricks ? like FIFO mode or a sliding buffer ?
    many thanks for your help.
    regards
    Attachments:
    essai_1.vi ‏26 KB

    Dear John,
    thanks for
    your answer. I apologize; I did not give enough information in my post. If
    fact, in our experiment the count rate is at maximum 1 MHz, moreover the APD is
    saturated when the count rate reach 10 MHz. Basically we perform two kind of
    experiments; in the FCS scheme, the photon flux is recorded and we have an
    algorithm that is computing the autocorrelation of the fluorescence signal. As
    you can see on the picture, we typically need a microsecond resolution on a
    time scale that covers several orders of magnitude. In this case we need to
    record the flux with µs resolution for let says 1 minute. I am wondering if it
    is possible instead of counting the photon to record the arrival time of the
    photon. Indeed when the count rate is low (10-50 kHz) we will have zero values
    most of the time so it is maybe more clever to record arrival time …. The
    second kind of experiment is the energy transfer scheme in which we monitor the
    interaction between two biomolecules by using two fluorophores. A laser is
    exciting the first one (donor) and if the second one (acceptor) is at less than
    10 nm you will observe an energy transfer from the donor to the acceptor. It is
    hugely used in biology to evidence molecular interaction. In this case you need
    to record with the detectors the fluorescence signal for several minutes with a
    time resolution of 1-100 µs. Again the size of the file can be very big.
    I hope this
    will help you in your answer.
    Regards,
    pascal

  • Device for photon counting system

    Hi
    I want  to design a photon counter for my optical measurement (very low intesnity). I need experiences of design and advice to choose a suitable  counter : low rate to high rate (up to 100M counts /sec), little dead time..., TLL input. I was told about such a PCI counter card.
    Thanks

    Hi hanh,
    The PCI counter/timer board that matches the specifications you have given would be the PCI-6602. You can find more detail about it in the NI 660x Specifications. The 100 counts/sec would be possible but you will have to use the prescaler. More information on this process can he found in this article which also has links to examples. Take a look at this device and see if it matches what you need.
    Regards,
    Kent
    Applications Engineer
    Digital Multimeter Home

  • Photon Counting with an Oscilloscope

    I am faily new to LabView, and I am trying to emulate a photon counter
    with a digital oscilloscope for determining fluorescence lifetimes. So
    far, the program downloads the waveform from the scope and determines
    the arrival time of each peak above the discriminator/threshold. But, I
    cannot figure out how to sum the counts for each time bin - ie add and
    store a count for each value in the "locations" array, and then store
    all the counts into a histogram. Any help is greatly appreciated.
    Attachments:
    Photon Counter.vi ‏247 KB

    The Replace array subset does nothing with an empty array. Do you fill the Total Counts array with the right number of elements before running the VI? I modified the VI to initialize the array with the number of elements in the peak location array. I also set the for loop to autoindex on the locations array and removed most of the coercion dots. Without any data I cannot test.
    To give us some data, run a sample of some data and Make the Current value default on the Current Waveform graph. Then remove the Instrument IO Assistant and convert the Current Waveform graph to a control. Save the modified VI and post it.
    Lynn
    Attachments:
    Photon Counter.2.vi ‏231 KB

  • 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 to use counter using PCI 6259

    Hello, users,
    I have a PCI 6259 board and use Labview 7.1.
    I'd like to repetitively count the photon signals at 10ms integration time. I want cumulative counts in every 1 sec (1000ms) (or 1 min (60000ms)) And I want to save counts into txt.file which is open in excel program.
    I am a beginner to use counter using PCI 6259 board.
    1. Could you explain default NI-DAQmx counter terminals, i.e., CTR 0 SRC, CTR 0 GATE, CTR 0 AUX, and CTR 0 OUT?
    2. How do I use them or how can I connect to count TTL pulse using PCI 6259?
    3. As I mention my purpose above, which example is the first step to start working my purpose?
    4. If you know good example, could you tell me about that?
    5. If anyone has labview example which is similar to my aim, could you give me some tips or your examples?
    Any hint, comment or advice would be appreciated.
    Thank you so much for your response.
    Leek2

    I have never used the PCI 6259 but have used counters many times with labview, the coding should be the same independent of the board.  What you want to do is finite buffered edge counting using a internal clock.  The best way to do this is to look at the examples programs and use the express vi to get started, then you can use this code to customize your program exactly as you need.
    To address your questions:
    1. CTR0 means "counter 0" the name of the physical resource sometimes listed at GPCTR0.  Each counter has 4 connections to the outside world:
    source "src"(for counting input TTL signals),
    gate (for synchronizing to external clocks and edges),
    out (for pulse-train out operations)
    and aux (specialty operations such as up/down counting and encoding)
    2.For event counting with internal clocking you will only use the src this is the input from the signal you wish to count (ie PMT discriminator for photon counting).
    3,4,5. Look at the count edge examples, there isn't one that does exactly what you want but I have done this with a 6602 (it has e counters) where I use one set of counters to set up a finite pulse train in your case 1000Hz with 1000 pulses, and another counter to edge count on an external pulse, with the source of this pulse routed from the out of the other counter.  Then you can start the task and read when 1000 samples are in the buffer (about 1 second later).
    Hope this helps,
    Paul
    Paul Falkenstein
    Coleman Technologies Inc.
    CLA, CPI, AIA-Vision
    Labview 4.0- 2013, RT, Vision, FPGA

  • AO+ 2 counter tasks of PCI-6110

    Hello
    I'm trying to get synchronized analog output task and pulse counting of two counters using PCI-6110,
    meaning generate an AO signal first then count incoming pulses at two different counters simultaneously.
    After searching this forum and testing some methods, (like https://decibel.ni.com/content/docs/DOC-5779 and https://decibel.ni.com/content/docs/DOC-11755)
     I thought that this PCI card is not suitable for my purpose.
    It seems impossible to trigger the counters in S series DAQ device.
    I'd like to know whether this is true or not and
    If so, which additional counter should I buy and connect it to PCI-6110 through a RTSI bus cable?
    Thank you for your time.

    Hello Eric
    This is for a photon counting setup and I'd like to send AO signals first to my device and then count pulses from two independent photon counters simultaneously. So I tried to use use aoStartTrigger as a trigger for these tasks, but it didn't work well.
    I haven't tried a digital trigger. Do you suggest any tricks to use AO as a digital trigger?
    A test vi file is attached, but I guess this cannot do what I think.
    Thank you for your kind support.
    Attachments:
    test.vi ‏36 KB

  • Losing counts using asynchrono​us reads

    Hi guys,
    I have been working on an application to allow me to do imaging on a microscope. Using an external clock source I need to "bin" photons coming from my sample for a set period of time.
    To do these measurements I devised an APD object in C#. The code to this opject is attached.
    When I want to measure I call the following code to instantiate the APDs I need;
    Identifier (Not Daq related, used by my code elsewhere),
    Channel number (Not Daq related, used by my code elsewhere),
    Device (a 6601 or 6602),
    The counter delimiting bintime,
    Timebase (20 or 80),
    The line taking in triggers,
    The counter counting photons,
    The line taking in the actual photon TTLs
     this.m_apdAPD1 = new KUL.MDS.Hardware.APD("APD1", 0, "Dev1", "Ctr2", "80MHzTimebase", "PFI27", "Ctr1", "PFI39");
     this.m_apdAPD2 = new KUL.MDS.Hardware.APD("APD2", 1, "Dev1", "Ctr4", "80MHzTimebase", "PFI31", "Ctr3", "PFI35");
    Where "this" is the form that hosts my APDs.
    I start actual measurement like so: 
    this.m_apdAPD1.StartAPDAcquisition(2, 128*128, 128);
    Meaning that I will bin photons for a 2 ms period, that my image consists of 128*128 pixels and that I will read those pixels line per line. Once this method is called on the APDs they will sit around and wait until triggers come in on PFI27 or PFI31 (indicating a new position of the sample reached) and then they will count photon TTLs coming in from either PFI39 or 35...
    Internally the APD object uses BeginRead and EndRead sets to read the actual photon counts. TheStartAPDAcquisition is called on the UI thread and for the Reader I set SynchronizeCallbacks = true; Therefore, also the CallBack is fired on the UI thread, which means all measured variables are updated on the UI thread (not that I think it matters here, but still).
    All this works fine most of the time, however, in a seemingly random fashion it will happen that APD1 does not register all triggers coming in on PFI27 and thus never collects all 128*128 pixels (and thus times out). What is strange is that if I switch around PFI27 and PFI31 like so:
     this.m_apdAPD1 = new KUL.MDS.Hardware.APD("APD1", 0, "Dev1", "Ctr2", "80MHzTimebase", "PFI31", "Ctr1", "PFI39");
     this.m_apdAPD2 = new KUL.MDS.Hardware.APD("APD2", 1, "Dev1", "Ctr4", "80MHzTimebase", "PFI27", "Ctr3", "PFI35");
    it is  still the first APD that will time out.
    Furthermore, I am 100% certain the triggers are indeed coming in on these lines from my external source. Also, when I was using my APD objects synchronously in a previous version of the code (or rather, when they relied on Synchronous Reads internally), all counts also registered perfectly. Sadly enough I cannot keep working synchronously for various reasons.
    The randomness of the issue makes me suspect I might be suffering from a bug related to threading/async operations where things happen in the expected order most of the time, yet not always.
    This issue is a big showstopper for me so any help would be greatly appreciated!
    Message Edited by KrisJa on 09-21-2009 05:01 AM
    Attachments:
    APD.cs ‏17 KB

    Hi Dan,
    Thanks already for the interest. First off, I tweaked the code for my APD class just a little bit (commented out some stuff I think was superfluous and explicitly start one of my tasks). The new version is attached, together with the source to PhotoDiode, another detector class that also suffers from the problem.
    I attached a scheme for the triggering/timing as well, I hope it is somewhat clear, if not I can provide more detailed info.
    The APDs are instantiated on a form like so;
    // Board, Binpulsegen, Timebase, Triggerline, TTLCounter, Inputline
    this.m_apdAPD1 = new KUL.MDS.Hardware.APD("APD1", 0, "Dev1", "Ctr6", "80MHzTimebase", "PFI31", "Ctr5", "PFI39");
    this.m_apdAPD2 = new KUL.MDS.Hardware.APD("APD2", 1, "Dev1", "Ctr4", "80MHzTimebase", "PFI27", "Ctr3", "PFI35");
    Subsequently, their events are hooked up and they are started;
    this.m_apdAPD1.StartAPDAcquisition(
                        _docDocument.TimePPixel,                          ​                   // For example 2, indicating 2 ms
                        _docDocument.PixelCount,                          ​                   // For example 128 * 128                   
                        _docDocument.PixelCount / _docDocument.ImageWidthPx); // Mostly 128, to read in 128 value chunks but can be -1 also this.m_apdAPD2.StartAPDAcquisition(
                        _docDocument.TimePPixel,
                        _docDocument.PixelCount,
                        _docDocument.PixelCount / _docDocument.ImageWidthPx);
    When they are started they will sit and wait for triggers coming in from an external Piezo controller (see attached scheme). They will timeout after 5 second.
    The eventhandler for the BufferUpdated event is;
     private void det_BufferUpdated(object __oSender, EventArgs __evargsE)
                KUL.MDS.Hardware.IDetector _idetDetector = (KUL.MDS.Hardware.IDetector)__oSender;    // Get to props/methods of the sender
                ScanDocument _docDocument = this.Document as ScanDocument;                                 // Class that holds data
                if (_idetDetector.Type == DetectorType.APD)
                    //_docDocument.StoreChannelData(1, this.m_apdAPD2.APDBuffer);
                    _docDocument.StoreChannelData(_idetDetector.Channe​l, ((APD)_idetDetector).APDBuffer);
                if (_idetDetector.Type == DetectorType.PD)
                   // PhotoDiodes get treated differently, this eventhandler is used by all IDetectors...
    The AcquisitionDone event is currently not used...
     Finally, my form also holds a Forms.Timer that ticks every 800ms, the Tick handler is as follows;
    private void m_tmrUITimer_Tick(object __oSender, EventArgs __evargsE)
                PaintToScreen();                                  ​                     // Paint the recorded images from both APDs to screen
                UpdateUI();
                if (this.m_apdAPD2.IsDone & this.m_apdAPD1.IsDone)
                    if (this.m_Stage.IsScanning)
                        this.m_Stage.Stop();
                    this.m_tmrUITimer.Stop();
                    this.m_Stage.Home();
                    // Handle auto-save, omitted for clarity.              
                    // Enable all controls again.
                    EnableCtrls();
                    UpdateUI();
                    // Unhook some events here... deleted for clarity.
    I attached the code for the form where all this happens for completeness, it is more messy than my other source files though, because I am constantly tinkering it.
    Finally, what I mean by missed counts is that in 8 out of ten cases, when I set out to record a 128*128 image both APDs actually accumulate 128*128 pulsewidth measurements (=photon counts for every pixel) as expected. However, every so often APD1 (the one that is started first in code) fails to accumulate the full amount of points. After 5 seconds it obviously times out.
    I did a number of tests;
    I disabled each of the APD's one at a time in code and used Measurement and Automation to check if the piezo controller was actually feeding the correct amount of triggers to the terminals used by the disabled APD. As far as I could tell (I tried 10 times for each APD) this was always the case, so the problem is not with actual missing HW triggers
    I changed the counters and PFI's used by each instance of my APD class. This also had no effect. 8 out of 10 measurements were ok butevery so often APD1 failed ( so again the instance that was started first ) even though it was now hooked up to collect the signals that were previously going to the APD2 instance (I hope this makes sense).
    I set the APD's up to do -1 reads (all samples available) and the amount of lost pixels is way less than 128 and appears random.
    So in conclusion, the bug is quite random. Mostly my app works fine, but sometimes it does not. AFAIK the HW is fine. The randomness of it all makes my suspect something to do with concurrency (in the async calls???) but I do not see how... This is a really frustrating issue!!
    Anyway, I hope my ramblings make sense to you! If you need info, please let me know!
    Attachments:
    Imaging Timing Implementation.pdf ‏66 KB
    APD.cs ‏17 KB
    PhotoDiode.cs ‏16 KB

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

  • Gated event counting for a finite time

    I am using a PCI 6110 card for gated photon counting. The digital signal is coming from a single photon counting module, which generates a single TTL pulse upon receiving a photon.  It also generates ~100 dark count /sec.  To get rid of the dark counts, I use gate pulses with very small duty cycle.  In this way, the dark counts are suppressed.  I want to operate for a fixed time interal with a resolution of ~1ms.  My gate pulses are at 800kHz.  Their duration is on the order of 10ns. Is there a way that I can perform gated counting for only 10000 gate pulses?  Thanks.

    Hi UMeng,
    Your question stirred up an interesting discussion at the office.  You can't do gated, buffered counting as the gate input is used to trigger the latch to the buffer.  We came up with a couple of ideas here, but neither are perfect.  It is important to also consider that you are running right at the specifed minimum pulse durations for the gate and source pulse durations for the 6110, which is 10 ns. 
    NI PCI-6110/6111 Specifications
    http://digital.ni.com/manuals.nsf/websearch/A9694D34EF10469386256E3000539747
    With that in mind, you could use an external high speed AND gate to generate a signal for a simple event counter to read using the laser gate and the photon detector output as input to the AND gate.
    Otherwise, you could try doing gated event counting on the signal and simple event counting on the gate as long as the gate frequency is consistent.  Then you could use the frequency of the gate and number of counts of the gate to get the total acquisition time.  This will require that you start and stop both counter tasks at as close to the same time as possible.  The start could be triggered with an Arm Trigger.  Getting the values from the counters would always require 2 software calls, but the longer the acquisition, the less important this error would become.
    Let me know if either of these sound appealing.
    Regards,
    John Bongaarts
    AE Specialist - Test Products

Maybe you are looking for