Alazar count edges synchronization

[BramMooij]

Hello,

We have an Alazar AT9350 of which the acquisition has to be synchronised with the acquisition of a Count-Edges channel on an NI-6259 DAQ board. Running them synchronously is easy, for we run the Alazar board with a trigger signal (50KHz) that we can route to the NI board as well. However, starting them synchronously poses more of a challenge. The original solution was to input the trigger on the NI-board and reroute it when the count edges VI starts. However, the board needs one counter to create the sample clock (or receive the trigger signal), and one counter to output the signal. This leaves no counter for the Count-Edges channel (our NI board has only two counters). 

I have come up with a possible solution for synchronisation, but it is a bit ugly. I output the task just after the start task VI to an indicator, and create a local variable. I connect a read version of the local variable to the acquisition while loop of my alazar board. My assumption: because the while loop has to wait till all data flows have presented data to him, the while loop must start synchronously with the start task. The actual program is much bigger, that's why I'm using a local variable here. A direct wire is also possible, but it would look even uglier. 

I have put a snapshot of a simplified version of my program as an attachment. I realise I am not actually saving any data or outputting what the Count-Edges reads, of course this is different in my real version. 

Is my method viable or should I use a different method? (or perhaps it is viable, but I should still use a different method).  

[BramMooij]

I think I have a solution. Within a few weeks I can verify whether the synchronisation is working in practice.

The solution is in the attachment, with the two main loops from the question replaced by Main loop 1 and Main loop 2, respectively.

[GerdW]

OMG!

Use a notifier. Or a semaphore. Or even a rendezvous. Anything from the synchronisation functions palette.

But DON'T rely on some polling loops burning the CPU while working with local variables…

[BramMooij]

Dear GerdW,

I realised beforehand that notifiers exist, but only found something about them in the sense that they continuously run inside my while loops. That was the reason I didn't use that method in the first place. The program is quite heavy already (from when the while loops start), as it has real time data processing with 50K FFT's per second. I thought this would be a reasonable (but ugly) solution, considering that the delay between the while loops is less than one second and they only have to execute once every time you run the program. Is it still a bad idea considering this information?

However, I prefer a proper solution, and have adapted my solution with your suggestions. I hope you can tell me whether this solution is good, or whether I should consider doing it otherwise. 

[GerdW · Accepted solution]

Hi Bram,

this one is better than before, but not good…

You only need one notifier: have both wait for new input data. Write data to the notifier once (in a 3rd loop) and both ReadNotifier functions will return as soon as they receive the new data!

The program is quite heavy already (from when the while loops start), as it has real time data processing with 50K FFT's per second.

Probably not "real time"… 😄

When you use DAQmx to read your input data you can synchronize input channels. Have you looked in the example VIs for that case?

[BramMooij]

Dear GerdW,

Thanks for your suggestions.

[quote]Probably not "real time"… When you use DAQmx to read your input data you can synchronize input channels. Have you looked in the example VIs for that case? [\quote] I use an NI board with DAQmx drivers to acquire the Count Edges. I use an Alazar board with their own SubVI's for the other acquisition. Therefore I cannot use the DAQmx synchronisation (which would've been quite easy indeed). And indeed, by "real-time", I of course mean that the amount of data I process per second is the same as the amount of data that I acquire per second .

I changed my example, hope I finally understood you well. I added a wait function to the loop that sends the notification. Otherwise the notification is sent on the same time, but there is still no synchronisation because the notifier is retrieved upon reaching the loop (and it essentially does nothing). To make sure I know when I start the two loops synchronously, I will add a high-resolution relative seconds to both loops and subtract them in another loop. If there is a better way to test synchronisation I'd happily take any suggestions. (Though perfect synchronisation is the best, one or two ticks off won't do much harm). 

[BramMooij]

I tested the method with the "High Resolution Relative Seconds" VI and the results look good. In the end one millisecond is enough delay to synchronise the two loops. Thanks a lot!