Triggering a counting vi on a timestamp

[anrran]

Hello,

I'm fairly new to LabVIEW and I have a question concerning timestamps. My experiment involves counting TTL pulses from a muon detector. I'm using the pci 6602 along with the BNB-2121. I'm trying to count how many pulses occurred during specified intervals (or time bins) for example 1 us bins. I think I've figured out how to do this except that I need to know the exact time of day that the experiment starts. The reason for this is because sometimes there is an increase in the amount of muons detected, and I need to know exactly when these increases occur.  All of the forums that I've search contained examples for timestamping counts relative to the start of the counting process but not the time of day.

The VI I have (which is basically a mixture of some of the code posted by different users on the forum) contains a sequence structure around the start task vi with a timestamp inside of it. When I run the VI with the highlight button I notice the timestamp and the start task happen at slightly different times. I'm trying to have at best micro second accuracy.

So I have a couple of questions:

1. Is the time between when the start task and timestamp happens significant enough to mess up the accuracy I'm looking for?

2. If so, is there away for the counting to be triggered by a timestamp? For example, check if time = 12:00:00.000000, if so, start counting.

3. Also, I plan on acquiring data continuously so I need to write the timestamp to the file as well, that way I can have multiple files with the relative timestamps, for example one file for every minute or something like that. Any help there would be appreciated?

Thanks,

Aaron

[Kevin_Price]

Are you sure you *really* need microsecond resolution for your time-of-day.  I kinda doubt you do -- unless you've taken great pains to ensure that your computer maintains microsecond-level accuracy on its time-of-day clock AND that the other stuff you want to correlate your time to is similarly accurate. 

The time difference you see when running in highlight mode is (probably) almost entirely due being in highlight

mode.  Otherwise, I'd expect you to see values that agree within millseconds, and that's almost always close enough.

-Kevin P

[anrran]

Hello Kevin,

Thanks for the quick response. I think I understand what you are saying; that my computer time of day may not be as accurate as I'm trying to measure. Let me know if I'm wrong. I know that the time from my computer may be slightly different from the time coming from another computer, and that the timestamp that I do get won't be exactly that time of day. Eventually the plan is to have the computer synchronized to a gps card and antenna, but I haven't implemented that yet. I was just wondering if it is safe to say that the timestamp that I do get is the start of my measurement according to my computer. So, if my timestamp is 12:00:00.000000 and my sample clock is running at 10000 Hz, can I consider the 1st element in the have occurred at 12:00:00.000100.

Thanks

Aaron

[Kevin_Price]

To be honest, I don't know much about how and when DAQmx assigns the t0 element of a waveform.  I almost always read plain arrays rather than waveforms and just haven't probed around a lot.  Here is what I *think* is true,

largely based on potentially obsolete and/or incorrect impressions from much older driver versions.

1. t0 is assigned when a task is started.

2. triggered tasks don't reassign t0 to represent the trigger time

3. t0 is queried via a normal system time-of-day timestamp function call and is subject to the normal vagaries of OS timing

4. All that being said, I'd expect the DAQmx t0 to be, on average, a little more accurate representation of task start time than what you'd get from your own time-of-day query.

5. I'd expect your 1st sample to occur quite close to 12:00:00.000000 and your *2nd* sample would occur closer to 12:00:00.000100

-Kevin P

[anrran]

So instead of reading the time of day like I have in my vi, I could get the time of day that t0 ( I assume t0 is the 1st element in the buffer ) was measured through the "time-of-day timestamp function call"? If so, where could I find that because I believe that is what I need? In the meantime, I will search for it. Sorry, I am new to LabVIEW and still do not know most of it's features.

Thanks

Aaron

[Kevin_Price]

Sorry,  I think I diverted things with the talk about the "t0" element in a waveform which isn't really relevant here.  I didn't reread the whole thread or double-check your code before my latest reply.  Since you are reading buffered counter values in raw array form, there is no waveform and thus no "t0" element. 

The timestamp function you are calling is pretty much the best I would know how to do.  I might sequence it so that the time is queried immediately after starting the task on the theory that the actual task start happens nearer to the end of the execution time of 'DAQmx Start.vi' than to the beginning, but that's about it.

BTW, I'm pretty old to LabVIEW and don't know all its features either...

-Kevin P 

[anrran]

Ok cool, thanks for the info Kevin, you really helped out alot.

Aaron

[johnsold]

From a glance at the 6602 User's Manual it appears that you can trigger the counters from an external signal after hardware arming: 

"Hardware Arm Start Triggers

You can arm each counter using a software command or by using the

Arm Start Trigger. The Arm Start Trigger may be an internal or an external

signal. By using the Arm Start Trigger, you can start more than one counter

simultaneously by configuring each counter to use the same Arm Start"

I would set it up to arm the counter in software, read the time of day clock, and then trigger from the one-pulse-per-second output of the GPS system. That way the triggering would be precise to the limits of the counter and the GPS and the time of day would only need to be good enough to tell you which second triggered the counters.

Until you get your GPS, set up a pulse generator form the best clock you have and pretend.

Lynn

[anrran]

Hey Lynn,

It sounds like your advice is the way to go. I'm currently doing another project right now, but when I get back to this one I will give your method a try!

Thanks

Aaron