LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Community Nugget 4/08/2007 Action Engines

Solved!
Go to solution

See here for a thread where Christian posted an example of a progress bar that can be used in a parallel For loop.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 71 of 161
(3,958 Views)

Due to a failure of the Forums, the images used in this nugget may not be available.

 

I have posted copies of all of the original images in this albumn.

 

Thank you,

 

Ben

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 72 of 161
(3,818 Views)

Hi Ben,

 

            Thankyou.This thread is highly informative.Detailed everything neatly.Intresting and informative for newbies like me.Thanks again.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Thanks as kudos only:)
Message 73 of 161
(3,714 Views)

@danil33 wrote:

Hi Ben,

 

            Thankyou.This thread is highly informative.Detailed everything neatly.Intresting and informative for newbies like me.Thanks again.


 

And thanks right back at you Danil33 ! I am plesed that this Nugget is still useful and the extra Kudos are always welcome.

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 74 of 161
(3,696 Views)

This nugget is wonderful. I just used an USR for my code and it's really awesome.

 

Thanks.

 

Message 75 of 161
(3,617 Views)

@pierroil wrote:

This nugget is wonderful. I just used an USR for my code and it's really awesome.

 

Thanks.

 


Thanks for the kind words Pieroil!

 

Yes to a large extent DVR can replace AEs. There is only one issue with DVR's and as long as you knowa about it, you can avoid. WHen using multiple DVR's there is a potential for a dead-lock condition where two threads each have access to a DVR but are dead-locked waiting fo rthe other DVR. The analogous situation using AEs could use one AE inside antoher AE. Since recursion of AEs is difficult (is it impossible?) the dead-locks can be avoided.

 

So watch out for dead-locks and DVR away!

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 76 of 161
(3,633 Views)

Well time to go look up DVRs I guess!

 

haha thanks!

 

0 Kudos
Message 77 of 161
(3,621 Views)

@Ben wrote:
Yes to a large extent DVR can replace AEs. There is only one issue with DVR's and as long as you knowa about it, you can avoid. WHen using multiple DVR's there is a potential for a dead-lock condition where two threads each have access to a DVR but are dead-locked waiting fo rthe other DVR. The analogous situation using AEs could use one AE inside antoher AE. Since recursion of AEs is difficult (is it impossible?) the dead-locks can be avoided.

 

So watch out for dead-locks and DVR away!


Just so you know, if you have two processes and two DVRs, as long as each process uses a single Inplace Element Structure to acquire both DVRs, LabVIEW has built in mechanism to avoid the deadlock known as the Dining Philosopher's Problem. The IPE will acquire the DVRs in refnum numerical order every time, thus guaranteeing that if a process gets one of the DVRs, it will get both of the DVRs, and no other process will get any of the DVRs until it can both of the DVRs. Any time you have multiple DVRs shared by the same two processes, and you are going to have the same subroutine using both of them, you should acquire both DVRs using a single IPE.

Message 78 of 161
(3,610 Views)

I know this is an old thread but I thought it would be a good time to update it now that Feedback nodes are available.

 

 

For pure number crunching AEs the FB node has shown itself to be up to 10X faster than the traditional form. I understood this as being atributed to the over-head required to check the stop conditon of the loop. Using FB nodes there are no checks required so pipelining in the CPU does not have to stall the instruction pre-fetch.

 

The benchmark I used for the test was a simple "Init" "Increment" Get" AE. The "Icrement was called repeatedly and timed. The benchmark was run in LV 2014.

 

I was suprised.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 79 of 161
(2,896 Views)

Ben wrote:

The benchmark I used for the test was a simple "Init" "Increment" Get" AE. The "Icrement was called repeatedly and timed. The benchmark was run in LV 2014.


Mind sharing your benchmarking code?  I would really like to look at this myself.  And we may even find some issues with your benchmarking.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 80 of 161
(2,890 Views)