Photon Counting, Time Stamping, and basic help with how DAQmx works

[ChrisErven]

Hi Leslely,

I have 8 counters grouped into 2 groups of 4, but all 8 are performing time stamping. Now for the experiments were doing, we're sending two entangled photons, one to each group of 4 detectors. But only 1 detector in the group of 4 will detect the photon, so at any one time, there will only be a max of 2 detectors firing. So at any one time there will only be 2 signals to route through a DMA channel. So I should be alright then? Each detector doesn't need a dedicated channel, instead the driver should be smart enough to route the signals, yes?

Thanks,
Chris

[Kevin_Price]

Chris,

The DMA vs. interrupt assignment can only be done "statically", prior to starting the task. And it binds to the specific counter involved in the task. So as far as I know, each detector will need a dedicated channel. 3 specific counters will get to use DMA, the other 5 will be stuck using interrupts.

-Kevin P.

[tdowd18]

Hello

I'm really new at LabView, and I'm trying to set up a system very similar (but simpler) than Chris's here. I've been working through these threads, but I'm having trouble seeing how the trigger in the example here relates to the rest of the block diagram. From the thread I get that the trigger is supposed to tell the VI where to look for the input, but I'm not really sure how to do that

Thanks

Tim

[e-Cash-Money]

Hello Tim,

In general, the DAQmx Trigger VI and DAQmx Trigger Property Node are used when you want to configure a trigger for your DAQmx Task.  In either the Trigger VI or the Trigger Property Node, you will need to specify the source of your trigger (i.e. the pin/line that your trigger is going to be connected to).

The DAQmx Trigger Property Node in Kevin's example (C:\Documents and Settings\elee\Desktop\SingleTimeStamping_v2.llb) is used to arm the counter when a hardware signal is received.

The ArmStart.TrigType input specifies what kind of hardware trigger signal to expect.  In this case, we are looking for a digital TTL signal to arm the counter.
The ArmStart.DigEdge.Src input specifies on what pin to receive the trigger.  In this case, the trigger line has been selected to be PFI2.
The ArmStart.DigEdge.Edge input specifies on what edge to trigger off of.  In this case, we will trigger off the rising edge.

With this configuration, in order for the counter to start counting, we will have to receive a rising edge on PFI2.

The input values of these properties can be changed.  For example, you could trigger off a falling edge coming into PFI3.

After you configure your trigger, you use the DAQmx Start VI to start the task.  However, this does not cause the counter to start counting.  This is because we have configured a trigger to tell the counter when to start counting.

I hope this helps out.  Let me know if you have any other questions!

[tdowd18]

Ah, great. Thank you very much for all the help!

I'm making a pared down version of the application that Kevin developed, because I only have one channel to worry about and I'm not trying to synchronize it with any others.

I just want to make sure I understand a few more points.

Since I don't have to synchronize the two channels, can I just set the Start.TrigType property mode to none, and forget the trigger entirely?

Along that same line, do I have to use his event structures in my VI at all? As far as I could tell, they seemed to be there to keep the VI watching for a trigger signal... I couldn't tell what the one in the file writing loop was doing at all.

And lastly, as far as I can tell he set the rate for the sample clock to check as very slow, because all his stuff with the queue and querrying to see if there's any data makes this value irrelevant.

Am I on the right track?

Thanks again

Tim

[e-Cash-Money]

Hello Tim,

> Since I don't have to synchronize the two channels, can I just set the Start.TrigType property mode to none, and forget the trigger entirely?

The only reason you would need to keep that property node in there is if you want to trigger your operation with a hardaware signal.  It sounds like you aren't, so you can eliminate the entire property node.

> Along that same line, do I have to use his event structures in my VI at all? As far as I could tell, they seemed to be there to keep the VI watching for a trigger signal... I couldn't tell what the one in the file writing loop was doing at all.

You do not need to use the event structure unless you want to.  The top event structure is used to handle user events (clicking on front panel controls) and the bottom event structure is just there to see if the program has been stopped by the user.

> And lastly, as far as I can tell he set the rate for the sample clock to check as very slow, because all his stuff with the queue and querrying to see if there's any data makes this value irrelevant.

If you are using an external clock, the sample rate is used by the driver to determine the size of the buffer.  It is recommended that you put in the maximum rate you expect your external clock to be so that the driver can create a large enough buffer.  If you are not using an external sample clock, this input will determine the rate of your sample clock.

> Am I on the right track?

Absolutely!

[tdowd18]

I'd appriciate anyone who has some more advice about this application

I have a setup very simmilar to the one that is described here. One change that I've made is that instead of having the DAQmx read node check to see if there are any samples in the buffer before reading, I just have it go ahead and read. I've found this seems to work ok because I've wired the available samples node to an indicator, and my intensity seems to be enough that i've always got hundreds of photons availible.

Although I've told the DAQmx node to read whatever is in the buffer, I find that the system works for a while, and then freezes. It says that the data was overwritten before it could be read, which seems strange to me, because the buffer is 5 orders of magnitude bigger than the largest amount of samples the "availible samples per channel" node is telling me that there is.

I might be looking at this way to simplistically, but my current line of thinking is that the data is going into the buffer and being read, but then isn't being removed from the buffer. Does that make any sense?

[gus]

It may be an issue of hitting the limitations of the DMA capabilities (with PCI bus latenceies) of your counter device.  How fast would you say samples are being placed in the buffer?

[tdowd18]

Hey Gus

Thanks for the help. I'm having the problem when the rate is as low as 30 samples/50 ms



Tim

[gus]

That's really strange.  Can you post your code?  And what is the exact error number you are receiving?