Synchronization issues on USB 6341

[pricea2]

Hello,

Before I get into the problem that I'm seeing, I'll start off by describing what I want to do.

I have the USB-6341 X Series DAQ and two photon counting head PMTs.

I want to bin and read the number of counts at each PMT with user-defined sampling rates between 500 and 10,000 Hz, resetting the tick count to zero after each reading.

I want the data from each PMT read/sample to be a single number - this is because I need to compare the two PMT outputs in real-time (i.e. calculate a ratio between PMT 1 and PMT 2 that I use to determine downstream operations).

Lastly, I need the reads from the PMTs to be "perfectly" synchronized. The (PMT 1/PMT 2) ratio means nothing if the data is misaligned by an arbitrary number of samples.

I've attached a copy of my code below. I'm using ctr0 to create a frequency pulse train with the same frequency at which I want to sample. The output of ctr0 is used as the source for the sample clocks of my input counters (ctr1 and ctr2) and also as the source for their Arm Start triggers. 

Unfortunately, the inputs from each PMT (counters 1 & 2) are unsynchronized, even with the Arm Start triggers (which I read were the only way of synchronizing counter tasks). I know this not only from the reviewing data that I've saved but also because when I stop the program, the number of samples recorded along the x-axis of each strip chart is different. I don't understand how that is possible. This discrepancy is arbitrary for each run. I should mention - I don't see the discrepancy on the strip charts at all if the PMTs are removed from their respective screw terminals.

Does anyone have any insight that can help me?

As a side note, I also see this behavior when I have two analog inputs that share the same task! That program is also attached below.

[kevins33]

Hi pricea2,

I believe the counter output task should be started after the counter input pulses to ensure synchronization, so what I would recommend is to use error wires so that the DAQmx Start Task.vi for the CO Pulse Freq task begins after the DAQmx Start tasks of both CI Cnt Edges tasks. 

[pricea2]

Hi Kevin,

Thanks for your time. I wired my error wires to do what you suggested (new VI below, but same name as before) but it doesn't fix my problem. Here is a screenshot of what I typically see once I press the stop button:

What is hard for me to understand is how, if I've set up my code to have each counter input task read 1 sample for each iteration of the while loop, how can I end up with a different number of samples (102325 and 102322) than while loop iterations (102337)?

[pricea2]

Any ideas?

[kevins33]

Hi pricea2,

Here are a couple of suggestions:

1) Can you please try to run this for a shorter period of time?

2) Can you create an array of the samples read from the counters, and obtain an array size value that you can compare to the number of loop iterations?

3) Also, try changing the Plot from a Chart to a Graph.

4) Can you ensure that all three charts start at the same point? 

[pricea2]

Hi Kevin,

I got started on some other stuff in the lab and so I haven't been working on this as diligently as I was before, but I did what you suggested in point 2, which was to build arrays within the while loop and compare their size to each other.

Here is the code that I added to my program:

When I run the program, the indicators for array size all give the exact same value. The interesting thing is that my strip charts will continue to give a completely arbitrary value that relatively close to the values in the indicators. Any thoughts as to why?

But, once I included those arrays into my while loop, the signals from my PMTs synched up perfectly. Once again, I don't understand why, but it did.

Alex

[Kevin_Price]

I have little to add about the chart indexes, other than suggesting that you right-click each one and choose "Data Operations...->Clear Chart" before your next run.  I'm guessing the discrepancy in index numbers might have accumulated before you followed the earlier advice about sequencing the task starts.

Couple points to ponder that *might* make this a bit more reliable:

1. I'm not a fan of using the same signal and edge for both the trigger and the sample clock.  I'm not *sure* that it can be a problem, it just always felt like a case of inviting trouble due to a possible race condition with signal propagation.  Could one counter circuit recognize the edge at the trigger circuit before recognizing it at the clock circuit whlie the other counter gets the order reversed?   I'm not sure of the answer to that question.  Thus, I avoid using the same edge of a given signal as both trigger and clock.

   Recommendation: the easiest thing is to drop the arm start trigger altogether, now that you've properly sequenced your task starts.  The only additional catch is that you should take and ignore one reading before the loop starts.  This is because the first reading will measure counts during an unknowable time interval.  Counting starts when you start the counter input task, *sampling* of that count value starts when you start the counter output task that's used as your clock.  The very first sample interval will be different for the two input tasks.

   You could also set up the arm start trigger to be sensitive to a falling edge, but you'd still need to discard the first sample from the two input tasks.  Even though in this case they'd have the same sample interval as each other, it would be shorter than all the subsequent intervals.

2. Similar reasoning about your count reset operation.  (Ironically, despite being the guy who asked for this feature, I still haven't gotten a chance to play around with hardware that supports it.  Should get that chance real soon though... )

   Might the same signal edge sometimes cause sampling to occur before the count reset and other times vice versa?  You seem to get a lot of 0-count intervals which in your data set look like they could be entirely real but I'd worry that they could (maybe?) be a case where reset happened nanoseconds before sampling.

   Here are two possible recommendations, pick one or the other.

   Alternative A: change your input tasks to do period measurement.  In this mode, the reset occurs internally immediately after the sample with no risk of race condition.  You don't need to configure the "count reset" properties.  Caveat: you may need to deal with a property known as "duplicate count prevention" in order to produce the results you expect.  Way way back in the early days of DAQmx, the behavior wasn't totally consistent across various hardware families and minor DAQmx revisions, so I'm never sure if I'm remembering the current behavior or an obsolete behavior that imprinted itself on me and won't go away.

   Alternative B:  I'm supposing that the "sample freq" setting is really most specifically about setting the interval over which counts are incremented.  So if you're gonna stick with edge counting tasks, I'd suggest configuring count reset to be based on the falling edge.  Then you'd want the pulse you generate to have a "low time" (rather than total period) of (1 / sample freq).  If it were me, I'd pick a very short high time then calculate my actual sample rate as (1 / (high time + low time)).

3. Speaking of count reset, I'm surprised that you don't seem to be specifying the property CI.CountEdges.CountReset.Term.  Your data makes it look like the reset is happening, but I don't know what signal is being used to do it.  Not sure what the default terminal would be when unspecified and wouldn't guess that two distinct counters would use the same default terminal.  They tend to have unique default terminals for the other programmable inputs.

   If you go with Alternative B above, I'd define both tasks to use the falling edge of PFI12 (the signal whose rising edge is your sample clock).

-Kevin P