From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

notifiers and queues advice

Thank You Wes,

 

I mean using shift registers as a global variable i.e shift register in a VI refer the attachment. 

I glanced through the Asynchronous Message Communication (AMC) which is interesting.

But I want to know about how queue and shift registers are working and process/threads as well.

 

 

 

0 Kudos
Message 11 of 14
(386 Views)

@sridarm wrote:

Hi all,

 

We are depeloving applications for Automated Test Equipment and the applications are very large. We mostly use PXI systems for the ATEs. Every ATEs contains atleast 20 instruments minimum. We are advised to use the shift registers instead of queue while transferring data between parallel running VIs. Reasons are Shift registers access memory directly and Queues are running in a process/thread to transfer which may load the CPU. Queue may not get updated sometimes as it is in process/thread.

 

I want to understand the background on how queue and shift registers are working and which is the best way to transfer data between VIs running in parallel for such large applications. Please share your thought about about large applications development.

 

Thanks,

Sridhar


 

That state was true for LV 5.1 but as of LV 6i, Queues became polymorphic and are capable of transfering data "in-place".

 

Prior to LV 6i, I used Action Engines (AE) to realized "Round-Robin" buffer becuase queues only came in a "String" flavor so putting data in and getting it out required a buffer copy on both sides (in/out). my benchmarks at teh time showed that the AE always would beat the queue (unless transfering strings).

 

But as of LV 6i NI introduced the polymorphic version that could be any data type. A simple explanation of how they can "transfer data in-place" goes as follows.

 

THe queue reference is a handle that points to an array of of handles where each handle can be used to find the data being transfered. When a code snippet wants to pump the queue with new data, the handle for the buffer holding the data (that is to be queued up) is copied to the array that holds the handles (Think of this as what is in the queue) and stops looking at that buffer.

 

Meanwhile the thread wating on the data (can be in a resource wait state so OS can now mark the resource as available and schedule the recieving code to be placed in the compute queue (this is an OS data structure used for scheduling tasks so don't get confused here).

 

So...

 

Transfering data using a queues amounts to copying a handle and marking code as computable.

 

No data copy required.

 

An AE on the other requires at least one cata copy to get the data into the SR so the queues win this race.

 

Of course the above scenario is optimal. If you are branching wires with large data sets you COULD force a buffer copy so the sending code has a copy while the other copy is assigned to the queue.

 

When can a AE win out?

 

When small parts of a large data set are used in multiple parts of your code. If you used queues to transfer the data to all of the parts that want it, you will have to make a copy for every duplicate queue. If the data can be put in an AE and the AE has methods that operate on the data in its SR's "in-place" then an AE could perform better.

 

Re: Asyncronous call...

 

I suspect the UI thread is required fo rthe data transfer so that could be an issue.

 

YOu should also concider DVR (Data Value references) that are LV's version of a pointer.

 

SO queues beat the pants off AE (sr's) in most simple cases.

 

if you want be come an expert on this topic start using "Show Buffer allocations" regularly and if you want to know what thrad does what, when, try out the Desk Execution Toolkit.

 

I will now step down off my soap box.

 

Ben 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 12 of 14
(378 Views)

Gotcha, 

 

The vi that you have enclosed is commonly known as a LV2-style global.  Some people call it a functional global.

 

This is a common way to pass information from loop to loop across a single instance of LabVIEW, whether it be in the development environment or as an executable.

The AMC is my design pattern of choice, however, as it is future friendly incase you need to talk over the network.

 

Ben has provided some excellent info about these things, so I won't be redundant. 

 

Post again if your question isn't answered.

 

Wes

 


--------------------------------------------------------------------------------------
Wes Ramm, Cyth UK
CLD, CPLI
0 Kudos
Message 13 of 14
(372 Views)

Thank you Ben and Wes

 

Now I am able to understand the funtional globals, queues and their concepts

.

AMC is quite interesting need to study that in detail.  

 

Thank you again guys.

Message 14 of 14
(365 Views)