LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

question about VI with 20+ sub VI's

Ok in a nutshell: I have delopped a pretty large app consisting of various tabs and a whole bunch of sub vi's. What it does: collect data and save (basically).

So now I've noticed that when making the application larger the maximum rate at which I can collect data gets slower (I use timed loops, and if it misses a cycle it passes a true so I can see whats going on)

 

So before I could go down to about 10 ms (when the app was small), now I'm around 50-100 ms. I have spreaded my VIs over the various execution threads and the app runs very smooth. So my question is: should I mess with the Vi priorities? Or is there something else I can do to allow faster data aquisition.

 

Oh yeah Im running on a core I7 @ 4 ghz with 2000 mhz triple channel RAM.

 

Message Edited by _Faust on 05-09-2010 05:33 PM
0 Kudos
Message 1 of 10
(3,086 Views)

A program with about 20 subVIs is actually quite small unless you've violated the general rule about keeping a block diagram the size of a single screen.

 

In therory, your acquisition rate should be whatever your hardware can handle and even 10 ms is a very slow rate. A timed loop. different threads/different priorites will not fix a bad architecture and you have not provided any details on that. Post your code or at least a better description.

Message 2 of 10
(3,079 Views)

It depends on your application.  To be honest, it sounds like your coding architecture may not be up to scratch.  Post some VIs or at least some code snippets (images).

 

In many cases changing the Execution priority to Subroutine can increase execution speed immensly.  This only applies to VIs which do not need to show their front panel.

 

Refer to this Nugget.

0 Kudos
Message 3 of 10
(3,062 Views)

_Faust wrote:

Ok in a nutshell: I have delopped a pretty large app consisting of various tabs and a whole bunch of sub vi's. What it does: collect data and save (basically).

So now I've noticed that when making the application larger the maximum rate at which I can collect data gets slower (I use timed loops, and if it misses a cycle it passes a true so I can see whats going on)

 

So before I could go down to about 10 ms (when the app was small), now I'm around 50-100 ms. I have spreaded my VIs over the various execution threads and the app runs very smooth. So my question is: should I mess with the Vi priorities? Or is there something else I can do to allow faster data aquisition.

 

Oh yeah Im running on a core I7 @ 4 ghz with 2000 mhz triple channel RAM.

 

Message Edited by _Faust on 05-09-2010 05:33 PM

 

Since sclaing up decreases performance, I have to think memory useage buffer copies or excessive use of the User interface thread.

 

I have been collect tags for LabVIEW performance here.

 

THat collection of tags, if read will make you a LV performance expert.

 

THe two questions you should be asking yourself to start the correction process are;

 

Are you using all of the CPU?

 

Are you using all of the memory?

 

Re: adjusting thraed assignments...

 

I have not had to touch those settings since LabVIEW 6.1 and if I had know better what i was doing, probably not then. 

 

Have fun!

 

Ben

 

Message Edited by Ben on 05-10-2010 08:02 AM
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 4 of 10
(3,033 Views)

Dennis Knutson wrote:

A program with about 20 subVIs is actually quite small unless you've violated the general rule about keeping a block diagram the size of a single screen.


What size screen?

 

My current monitor is 1920x1200 back when I started I was lucky to have a monitor that had 1024x768 resoultion.

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 5 of 10
(3,002 Views)
That mythical "screen size" limitation has been slowly growing as monitors get bigger and cheaper.  I usually try to keep my block diagrams fitting on a 1280x1024 and my front panels even smaller since my code may have to run on the smaller monitors in the production department.  Of course it all depends on your situation.
LabVIEW Pro Dev & Measurement Studio Pro (VS Pro) 2019
0 Kudos
Message 6 of 10
(2,996 Views)

Ben wrote:

 

I have been collect tags for LabVIEW performance here.

 

THat collection of tags, if read will make you a LV performance expert.

 


What are these "Tags" about?  Click on the link and I see nothing - No Tags.

0 Kudos
Message 7 of 10
(2,955 Views)

Hi battler,

 

due to some forum problems (?) you see your own tags - none Smiley Wink

 

Look for Ben's profile to view his tags...

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 8 of 10
(2,946 Views)
Thanks!
0 Kudos
Message 9 of 10
(2,918 Views)

Please let me know ifthis tag cloud works.

 

The forum tracks tags by user and as a group and unfortunatly, it will not let you see my private collection.

 

THe link above should be for the entire community which has a lower SNR than my private collection but it should still have all of mine.

 

If that link works and if you chase down the links and related links, you will read what I have marked as "required reading" on the LV performance topic. 90% of what I know about LV performance was learned on this board and I set up those tags so others can "cheat" and get up to speed fast*.

 

sorry about the bad link,

 

Ben

 

* Pun intended

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