PFI1 and PF2 reference pulses not limiting CTR2

[adreilly]

I'm working on getting an old optical table from 2015 (running on labveiw 2012) up and running and have been able to get a majority of it working; however, my gate pulses for the avalanche photo diode aren't restricting the reading intervals and as a result instead of limiting counts to specific times between microwave pulses, it is constantly counting throughout the experiment. 

It is worth noting that I want only instances from the APD within the width of individual signal and reference gate pulses to be counted while all instances between and outside of these two pulses to be ignored. (refer to pulse image)

 

Some additional info:

I used DAQ assistant to verify that the signals are being recieved by the DAQ (for example i can count the pulses of PFI 2 when it was assigned to any Ctr )

I attached a screenshot an image of the DAQ board set up along with PFI connectors' respective counting functions

 

I am using DAQmx 15.5.1 drivers (i also tried 9.9.0) with NI USB-6366 series x multi-function DAQ with BNC ports

The TTL signal pulses are generated by a PBESR-PRO-300-USB-RM. I tested the outputs of this signal generator as well as the BNC cables being used with an oscilliscope and saw no issues.

Running the actual vi's don't give any error messages however the task out from EPR init.vi is blank, due to this I believe if it is a software issue this is likely the source of the problem. Swapping any counter with another causes an error *example swapping Ctr0 with Ctr3, Ctr2, or Ctr1 for the first line in the EPR init terminal gives back error -50103

There was an issue when trying to update this system to labveiw 2019 and as a result the drivers and labveiw 2012 had to be reinstalled. Due to this it could be an issue with drivers/installation and not the code since this code (according to previous users) did not have issues before.

I can also attest to the fact that i was able to get all time independent measurements working without having to change any of the labview code. It seems only measurements that require pulse gated measurements are faulty

I attached the DAQ layout, the pulse sequence, the measurement vi (pulsegenerator3), the embedded vi (EPR init), and the counter vi since this must also be running for the other vi's to work 

I am new to labveiw and started using this code 9 years after it was made, so I'm out of my element and may have missed some information

below i attached the main vi (pulse generator 3) as well as a screen shot of the specific part that i believe to be where the error is occurring, I also sent they two vi's embedded in the main vi that i believe are causing problems in the main vi (EPR init and EPR run), laslty i added the photon counter vi which is required to run the main vi 

[Kevin_Price]

The vi attachments are missing.

I'm a little fuzzy on your exact requirements, but it appears that you have 2 distinct "APD gate" signal wires that will each carry pulses -- one for "Sig" and one for "Ref".  You show 1 microwave pulse, but I don't understand what role it plays in your system.  Same for the laser pulse signal.

Based on the part I *think* I understand, you need 2 counting tasks where each is configured with one of the APD gate signals acting as a Pause Trigger, configured to "pause when low".  That way the only APD pulses that will increment the count will be ones that occur during the high times of the APD gate.

One task counts APD pulses during "Sig", the other counts during "Ref".   Simple enough, but only until the next set of Sig and Ref pulses arrive.  Now you'll accumulate more APD counts and will have lost the first set of count values.   Unless your counter tasks are *also* set up with DAQmx timing to buffer up count values in reaction to a sample clock.  So each task should probably *also* use the falling edge of its APD gate pulse signal as a sample clock.

-Kevin P

[adreilly]

Main vi terminal

main vi terminal

main vi

main vi

sub vi terminal (EPR init)

sub vi (EPR init)

sub vi 2 terminal (EPR run)

sub vi 2 (EPR run)

counter terminal (counts photon instances)

counter vi (counts photon instances)

[adreilly]

Thank you for your help,

i attached some photos as well as zip files of the vi's used. To be honest i am also not too sure of the purpose of the microwave and laser (AOM) sequences being sent to the DAQmx, since these pulses are also sent directly to the instruments, but my assumption is that they are connected to the DAQmx to act as counters for other vi though i may be wrong (i haven't had problems with them but its also possible that they are encountering the same issues as the APD gates)

The attached photos and vi will be able to explain whats going on better than me, but i believe the counter tasks are also set up with the DAQmx with the setting set to "falling" (this is done in EPR init)

[Kevin_Price]

Things are still kinda fuzzy to me -- more description would be helpful.

A lot of what I see in the screencaps looks pretty good.  I think I may have a couple quibbles but on the whole it looks likely to be pretty close to what you need.  (Although again, exactly what you need remains kinda fuzzy to me.)

The biggest issue I think I'm seeing relates to sync among tasks, counts, and sampling.

1. You haven't established sync among your counting tasks (ctr0, ctr1) and your sample clock task (ctr2).  They're all free to start in any sequence.  You may sample before any counts get registered or register lots of counts before sampling starts.  There's just no dataflow to enforce a desired sequence.

    The simplest solution is to make sure both counting tasks start before the sample clock task.  Then realize that the first sample *might* be a somewhat arbitrary value that needs to be subtracted off all subsequent counts.

2. It's unclear why you'd want to claim a 10 kHz sample rate and then read 1 sample at a time from the counting tasks.  It's much more efficient to read multiples samples at a time from buffered tasks.

3. It's also unclear why you'd claim a 10 kHz sample rate but then configure the counter acting as a sample clock to have a frequency determined by a front panel control called "N Loop".   That seems fishy.

4. Consequently, it doesn't seem that your sampling method is properly synced up with your intervals of interest, where "sync" means capturing a count value right at the end of each such interval.

-Kevin P

[adreilly]

Sorry i don't have answers to some of your questions as I am still very new to lab view and wasn't present for the creation of the code. That said I will do my best to give more details.

1) here is an image of the input pulse sequence (yellow goes to PFI0, green to PFI4, blue to PFI1, and red to PFI2)

2) based off of my the past measurements done with this software. The idea behind it is to establish the parameters for pulse sequence before any sampling is done (load board). Then have the pulsegenerator emit the sequence (start/restart) and initialize the data taking. Pressing (Track and EPR) first focuses the laser onto the sample following this the data is recorded onto a txt file. 

it is also worth noting that photon instances are always being counted though the counter vi, and the counter vi is also running during the measurement process

3)The pulse sequence cycles through the parameters of the desired measurment, ex: rabi pulse steps are at 96 when going from width 2E-8 to 5E-7 at a stepsize increase of 5E-9. After the max pulse width is reached it returns to the minimum pulse width and repeats the process for "N Loop" times. The counts for each step are added to themselves from the other loops and recorded onto a txt file. So if 2E-8 width has an avg of 3 photons counted per loop within the width of the signal pulse, and 200 loops were performed, it would log the counts at 600

4) due to this recording sequence and/or spreading out any sample to count sync error between the steps, i think this is why no additional code was used to properly time the tasks

5) for reading multiple samples at a time, is this done by giving samples per channel an integer value?

6) for your third point about it being fishy for the 10khz sample rate being used with the sample clock, i have no explanation nor understanding of why this is done

7) from what i understand for your 4th point, you are saying that, at the end of each gate pulse the counts accumulated over those pulses are not recorded 

[Kevin_Price]

Sorry, there are still a lot of details that are unclear to me.  Please keep in mind, I've never worked on anything similar to your app.  I've gotten into a lot of threads about laser emission and photon counting because I'm good at working in the realm of timing relationships among pulse signals using NI DAQ equipment, but I have no real idea how to translate something like the following into those kinds of specific pulse timing relationships:

The idea behind it is to establish the parameters for pulse sequence before any sampling is done (load board). Then have the pulsegenerator emit the sequence (start/restart) and initialize the data taking. Pressing (Track and EPR) first focuses the laser onto the sample following this the data is recorded onto a txt file.

My attempts to decipher behavior from the code alone leaves me pretty suspicious that it wasn't doing the best possible job of delivering the kind of data you seem to want from it.  I'm a little suspicious that it may have fairly significant flaws.  But it's hard to tell b/c I don't understand nearly enough about intent and how all the signals and equipment are supposed to interact.  Remember, this project may be a big part of your work day only but it's only grabbing a few minutes of my attention.

Your point #3 description seems to talk about sweeping through a specific range of pulse widths one by one, then repeating that whole sweep N times.  But then at the end, you want to organize the data such that you have a distinct set of N results for each specific pulse width.  It's not quite clear from my brief look at the code how that whole process is managed.  But it doesn't appear that anything special is being done to reorganize the data before saving, so I suspect that such analysis must be done by some other tool in a post-processing stage.

5. Yes, choose a multi-sample version of DAQmx Read and then wire in an integer for the specific # samples to read.  The function call will block and wait for that # samples to arrive if necessary.

7. It doesn't appear to me that the sample clock signal for capturing counts is correlated to the specific APD gate pulses that I think it *should* be (based on my limited understanding of your app, equipment, intentions, etc.)   Treat my comments as a point of *caution*.  It'll be *important* to really understand what's going on there.  And what *should* be going on there to produce the data you want.  And what to do (if anything) to make sure that "what is" carries out the desires of the "should be."

    I'm not fully clear on *any* of those components, so about all I can say with confidence for now is "watch out" for that specific part of the config.

-Kevin P   

[adreilly · Accepted solution]

Thank you for your assistance, 

I was able to locate the issue; it turns out that the EPR run.vi was corrupted. I replaced it with an older version of itself and this solved the problem.

Once again, i really appreciate the time you put into helping me with this problem 

Happy Thanksgiving