Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

PCIe-6363, multiple tasks synchronized with different rates

Hello,

 

We have a BNC-2110 connected to a PCIe-6363 device.

We are trying to run 4 different tasks synchronously.

task1 - analog voltage output (write)

task2 - digital on/off modulation on line 0 and 1 (write)

task3 - digital edge count on pfi8 (through user1) (read)

task4 - digital edge count on pfi9 (through user2 (read)

 

Each task individually runs fine and works great but we do not manage yet to synchronize them.
The main task is task1 which runs e.g. with 10kHz and task2/3/4 should run with double the rate (here 20kHz).
Please find attached the vi.
Any help/comment is appreciated. Thanks in advance.

 

0 Kudos
Message 1 of 11
(4,423 Views)

just some additional information:

 

I am running the AO task1 as the main task and I can perfectly synchronize task2 to it.
But I am failing to synchronize task3 and task4 to it.

0 Kudos
Message 2 of 11
(4,402 Views)

Hello Ben,

 

I took a brief look at your code and it seems that you need to verify that all of your slave tasks, tasks 2-4, start prior to your master task, task 1. You also will want to verify that you are using a 20kHz sample clock for tasks 2-4. I would recommend taking a look at some of the DAQmx synchronization examples within the example finder. Navigate to Help > Find Examples >  Hardware I/O > DAQmx > Synchronization. I would also recommend checking out the following helpful document:

 

http://www.ni.com/white-paper/11369/en/

 

CH
Applications Engineering
National Instruments
http://www.ni.com/en-us/support.html
0 Kudos
Message 3 of 11
(4,385 Views)

I don't have LV 2017 installed so I can't look at your code.

 

The counter input tasks (#'s 3,4) should use the sample clock from the digital output task (#2), and the counter tasks should be started before the digital output task.  That'll be enough to make sure tasks 2-4 are sync'ed.   Since you've already sync'ed #2 to #1, that'll take care of things.

 

I'm guessing that you've got independent sample clocks for AO (#1) and DO (#2) but that you sync them with a shared Start Trigger.  That should work fine, but I'd probably be trying to do things a different way.

 

I tend to prefer syncing via Sample Clock alone whenever possible rather than syncing primarily via Trigger.  This approach lets me use the same code for tasks spread across multiple boards as I use for tasks on a single board.

 

In your case, I'd consider making AO the master task that gets started last.  All the other tasks borrow its sample clock as their own, and are started first.  Run AO at 20 kHz by doubling up every sample you would have generated at 10 kHz. 

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
0 Kudos
Message 4 of 11
(4,377 Views)

Hi and already thanks,

Please find attached the vi for LabVIEW version 14.

However, I still cannot follow how to do it. I start the AO task last but:

"...All the other tasks borrow its sample clock as their own, and are started first. Run AO at 20 kHz by doubling up every sample you would have generated at 10 kHz. "

My task1 runs on the onboard clock and the rest should use the ao/sampleclock? And I was thinking that the 'rate' defines the write/read frequency? So, why should I double the sample number?

Download All
0 Kudos
Message 5 of 11
(4,354 Views)

The code was a little much to trace all through.  A little tip:  it's helpful to keep your task ref wires pretty horizontal across your vi.  Then you can kinda tell at a glance which functions operate on which task just from its vertical level on the screen.

 

Anyway, yes, the DO task should also use "/Dev1/ao/SampleClock" just like the counter tasks.  Also, yes, 'rate' is the sample rate and it defines the write/read frequency.  Finally, doubling up each sample is a simple way to both let your AO sample clock be the master that syncs everything *and* also run your AO at 1/2 the speed of the other stuff.

 

Here's the walkthrough.  In your original plan where AO runs at 10 kHz, each sample value in the AO array you calculated will be generated for 100 microsec, then the next one, then the next, and so on.  However, there's not a great way to take this 10 kHz sample clock and use it to drive the other tasks at 20 kHz.

 

However, suppose you configure your AO to generate at 20 kHz.  Then it can drive the other tasks.  You just need to duplicate every sample in the AO array.   The new array will consist of 2 entries of your original sample #0, 2 entries of your original sample #1, etc.  While the AO task runs at 20 kHz and drives all the other tasks, the actual voltage output from the AO task will only change at 1/2 that rate -- the original plan of 10 kHz.

 

Below is a snippet to illustrate where and how you can use the "Interleave 1D Arrays" function to accomplish the doubling I was talking about.  Right between the "add" functions and "Build Array".

 

 

-Kevin P

 

interleave AO.png

   

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
Message 6 of 11
(4,344 Views)

Hey Kevin,

Thanks again for your suggestions.

 


@Kevin_Price wrote:

The code was a little much to trace all through.  A little tip:  it's helpful to keep your task ref wires pretty horizontal across your vi.  Then you can kinda tell at a glance which functions operate on which task just from its vertical level on the screen.

 


Just before I uploaded it to the forum, I "CTRL+u" it. This was probably not so helpful. Anyway, I attached a modified version (without cleaning up), where I think the timing sources should be correct now and the task wires should be vertical, but I still do not get the synchronization.

 

However, let me explain how I 'measure' the synchronization:

Please, keep all the input values default just play with the 'pixelSpeed(px/s)'.
X size and Y size should be 128, creating now a new array of the size 2*128*128 =32768 for the galvos as you described in your post above. (neat idea).

As you can see further, I put a small queue above task3 to write the elements from task3 into the queue. And if I stop the program I just flush the queue and get the array size. And that should mean:

If you put as pixelSpeed a value of 16384, and you stop the program after 1 second, you should get an array size of that 16384 (I stop it by hand after roughly 1 second, but you get the idea). That seems to work, at least for me. But as soon as I put higher numbers into pixelSpeed, let's say 50000, I do not get this number as array...I stay way below (like also around 25000). And higher numbers do not change a thing. That is why I think I am not in sync.

 

(I know it might be not the best way to check synchronization. So, how do I know that my hardware is working proper? We have a previous software from a former co-worker here with the same hardware settings (same port lines, same cables, same tasks etc...) and that software, with plenty of Sub-VI's, works well. I just extracted the tasks and try to build a new software since we have to combine now multiple systems into one.)

 

Thanks for further feedback.

Download All
0 Kudos
Message 7 of 11
(4,318 Views)

The latest code is LV 2017 and I can't open it.  Your description for "measuring sync" doesn't sound like anything to count on.  In general, the way to measure sync is to capture the physical signals on a scope.  

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
0 Kudos
Message 8 of 11
(4,311 Views)

@Kevin_Price wrote:

The latest code is LV 2017 and I can't open it.  

 


Sorry, my fault. Please find attached the VI saves for version 14.

 

And I agree that it is not a way to measure sync but is somehow a way for me to see if it works (which doesn't mean it is correct)

0 Kudos
Message 9 of 11
(4,306 Views)

I did some oscilloscope measurements: task2 is definitely in sync.
Task3/4 I couldn't get it...

0 Kudos
Message 10 of 11
(4,300 Views)