cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Making LabVIEW multi-threaded, for independent parallel processes, connected by queues

Making LabVIEW multi-threaded, for independent parallel processes, connected by queues

Good day,

I am working with a complex LV program, in which data-acquisition is done using DMA buffers (because data rate is high, 2.2GB/s. DAQ is done using subVIs that came with the DAQboard (AlazarTech)), and some of the data is copied to LV (1 in N) into a lossy queue, on which some processing had to be done and finally displaying. (also some AO signal are created and send out using NI board, but let's forget about that for now.)
The problem I am having is that when I do some processing and displaying buffer overflow of the DMA buffers starts occuring. If I disable the processing and displaying, but still copy some of the data to LV I can avoid buffer overflow by only copying 1 in 15 buffers to LV. (buffersize is 6MB, which according to Alazar is in the referred range 1-8MB). Of course the copying to LV takes some time, so during that time the buffer being copied has to stay on the DMA buffer, and therefore the other DMA buffers will start filling up, until the copying is done and the buffer can be released. If I now do some processing on the buffer in LV I did not expect that to influence the DMA buffer behavior, especially since I'm using a lossy queue in LV.
After quite some discussion with AlazarTech, I finally understand that since LV is governing the DMA buffers (though ATS Api) it can slow this down if it is too busy with other things, such as processing and displaying.
Therefore I would like to make my program multi-threaded so that the governing of DMA buffers, and copying 1 in N to LV is separate from the processing and displaying.
In general I read that LV should make things multi-threaded itself, e.g. if you have two separate while loops. One question I have regarding this is, If I have nested loops, they probably cannot be on different threads, correct? (Of course I've avoided nested loops by now, but I'm curious, e.g. can 2 while loops inside another while loop or inside a case structure be on different threads?)
I've also read about the subVI priorities. I've set the governance of the DMA buffers to highest priority, and I've made a processing subVI which I set to low priority. I have also put the preferred execution systems to different ones for the DMA buffers and the processing, hoping that would make them multi-threaded. I have turned off debugging in the execution tab for the DMA and processing subVI, because I read that that would be a good choice if you want something multi-threaded. And in the processing I have put some multi-channel FFT subvi's I have on preallocated clone reentrant execution, so that they have their own memory space and don't have to wait for eachother (there are only 2). For the DMA buffers I've used non-reentrant execution, because the order of execution is very important here.
To come to my question, which might not be the correct question to ask, maybe from my story you can guide me in a different direction:

Can I make labview run different parts of code on different threads, and would that help me in solving them influencing each other?
Perhaps the problem is that the threads have to communicate through the queues and that makes them somehow dependent?

I hope someone can give me something new to look at.
Thank you very much in advance!
Best Regards,

Judith

0 Kudos
Message 1 of 12
(283 Views)

Re: Making LabVIEW multi-threaded, for independent parallel processes, connected by queues

Our data rates are significantly lower than yours, but the problems are similar.  We are monitoring animals in a behavior experiment, with 24 stations having a video camera that records the behavior (about 2-5 seconds of video, 640x400 RGB at 30 frames/sec, centered around the behavior that occurs 4-10 times an hour) and other sensors that let us know when the behavior occurs.  

 

We run each Station as a LabVIEW sub-VI that contains independently-running loops for the "behavior sensor" (sending us data that we record at 10 Hz and use to decide when to make an AVI of the Video), the Camera, and a Video routine that takes frames from the Camera and makes an AVI when the Sensor loop says "Go!".

 

We run these "clones", spinning up 24 of these sub-VIs using Start Asynchronous Clones.  The Clone is configured as a Queued Message Handler, with the top-level controlling program sending some of the messages via the Message Handler Queue (unique for each of the 24 Clones).  This works very well for us -- the Clones do not appear to interfere with each other, and seem to "share" the computer resources nicely.

 

Bob Schor

Message 2 of 12
(252 Views)

Re: Making LabVIEW multi-threaded, for independent parallel processes, connected by queues

Remember not to use code which is a shared resource. The main obstacle in this is the UI thread which is used for e.g. property nodes on UI elements.

So the "sharing" of computer resources works only nicely (as Bob worded it) as long as you do not implement any bottleneck. LV is inherently multithreaded, so no additional work to be done here. But please note that you might require some sort of synchronization by using queues, notifiers or user events (at least these are the recommended methods).

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 3 of 12
(248 Views)

Re: Making LabVIEW multi-threaded, for independent parallel processes, connected by queues

Since AlzarTeck password protects the ATS-SDK installer I can only speculate from the manual.

 

The LabVIEW Drivers are thin wrappers around Call Library Function Nodes.  Are they set to run in any thread or is require the UI thread selected (Default?) Right-click on them select configure and see.  The DLL may not be thread-safe You would need to check with them on that

Message 4 of 12
(239 Views)

Re: Making LabVIEW multi-threaded, for independent parallel processes, connected by queues


Jeff·Þ·Bohrer wrote:

Since AlzarTeck password protects the ATS-SDK installer I can only speculate from the manual.

 

The LabVIEW Drivers are thin wrappers around Call Library Function Nodes.  Are they set to run in any thread or is require the UI thread selected (Default?) Right-click on them select configure and see.  The DLL may not be thread-safe You would need to check with them on that


Jeff posted what came to my mind.

 

If they (Alzar Teck) will not let you at the code you will have to ask them how their driver is implemented. Specifically, 1) are they using "Call Library Function" and 2) is it orange or yellow?

 

I believe ( I have not used it lately) the DETT (desk Top Execution Trace Toolkit) will let you check the threads that code it running in.

 

if worse comes to worse and they will not tell you and the DETT confirms the UI thread and you REALLY have to use the code from Alzar Teck....

 

You could launch a separate executable to run the Alzar Teck code and expose a TCP connection for your LV application to use to fetch updates. TCP/IP on a single machine is very fast but I admit it would be a real pain in the arse if you had to resort to that approach.

 

Re: all of those execution option setting changes you made.

Sometimes the wrong mix of settings and a hungry loop (no throttling) can cause more problems that it solves. I recall one of the help files reading something like "You should not have to set priorities but if have to set priorities you can do X, but you really should not have to ...". Made me smile when I read it.

 

The tag cloud found here are related to LV performance. They may give you other ideas.

 

Post your code and someone (probably not me) may be able to offer other ideas.

 

Ben

Message 5 of 12
(225 Views)

Re: Making LabVIEW multi-threaded, for independent parallel processes, connected by queues

Thank you all! I'm going to take a look at it Smiley Happy

0 Kudos
Message 6 of 12
(220 Views)

Re: Making LabVIEW multi-threaded, for independent parallel processes, connected by queues

Hi Ben,
Thank you for your reply.

I have answers from Alazar:
1) They are using Call Library Nodes in LabVIEW to call the C functions from ATSApi.dll. They use the non-reentrant (orange) nodes.
2) All API functions are set to be run in the UI thread.
3) ATSApi.dll is not thread-safe. Functions from the API can be called from different threads one after another but care must be taken not to call ATSApi functions simultaneously from multiple threads.

I do not know that much about how this works exactly, but I understand that since it is run in the UI thread it will give me problems. Do I understand correctly that it possibly can be run in another thread, since it is not thread-safe? Can I  change that by changing it in the VI properties? When I changed the preferred execution system of all their subVI's I'm using from 'same as caller' to 'data-acquisition' it caused the program not to run, but maybe I should try again? What would you recommend?
(and the orange means it is non-reentrant?)

I look forward to hearing from you. 
Regards,

Judith

 

0 Kudos
Message 7 of 12
(134 Views)

Re: Making LabVIEW multi-threaded, for independent parallel processes, connected by queues


Ben wrote:

 

 

I believe ( I have not used it lately) the DETT (desk Top Execution Trace Toolkit) will let you check the threads that code it running in.


Does the Time Stamp control fully block the UI thread? I thought it did in which case you can just check to see whether the DLLs continue to operate when you have the UI menu of the control open.

Matt J
National Instruments | CLA/CTD
You May Not Know
0 Kudos
Message 8 of 12
(127 Views)

Re: Making LabVIEW multi-threaded, for independent parallel processes, connected by queues

The DLL calls in the drivers are going to be a bottle neck.  And you should only use the "open in caller thread" for the Call Library Node if you know for sure the DLL is thread safe.  If dealing with hardware, it is likely it is not thread safe.

 

As said already, post some of your code so we can better understand your situation.  We can likely give you better advice then.


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

The discussions from the Advanced User Track is not over. Join in the conversation: 2016 Advanced Users Track
0 Kudos
Message 9 of 12
(111 Views)

Re: Making LabVIEW multi-threaded, for independent parallel processes, connected by queues

hi,

from what it seems we did not purchase the DETT yet, but I have to look into it more.

The code I'm working with has a very large BD, it is made by multiple people, and started from example VIs supplied by Alazar. I know many things are not done in a proper way, e.g. there is overuse of flat sequences, instead of using flow as it is intended in LV. And using a state machine would have made the code much clearer. I've don't know how to put the whole code on 1 print screen, so I've made a few, one of the place where the calls to the DMA buffers are done, and one of where the processing of the buffers from the queue is done and also displaying.

 

Regards,

Judith

0 Kudos
Message 10 of 12
(86 Views)