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: 

Optimally structuring several writes/reads

Hi All,

 

I'm brand new to the forum and somewhat new to LabVIEW. I'm curious if I could ask for some input on the best way to optimally structure the attached vi. I have also attached the sub-vi for reference.

 

I can see a few ways to change this around but don't have a solid understanding of how that would affect what's going on under the hood - hence why I came to the experts!

 

 

Thank you for your time,

 

Adam

Download All
0 Kudos
Message 1 of 6
(2,923 Views)

First, in Heat Test, the framed sequence is totally unnecessary (except to fill space and make it harder to arrange your code) -- everything is (appropriately) serialized by the Error Line Running Through It.  

 

On the other hand, the "floating" parallel loop above it is curious.  What in the world is it doing there, totally disconnected for the rest of the code?  I don't get it -- it seems to be "out of place" (or simply "inscrutable").

 

I notice that ACL CC1 TC, which is called often, opens a VISA connection, does some I/O, then closes the connection.  Open, I/O, Close, Open, I/O, Close.  Why so many Opens and Closes?  Why not open once before you start looping, then close when you're all done?

 

Bob Schor

Message 2 of 6
(2,905 Views)

Hi Bob,

 

Thank you very much for your prompt feedback. I have taken your first two tips of advice as both of those somehwat inscrutable complications were caused by me trying to organize the code visually in an easy to understand manner.

 

On your third comment, I understand that opening and closing  a waste of computation time. The Sub VI was developed as a way to make it easier for me to write and read a visa command in various situations or various other VIs. Is it highly beneficial to avoid performing this kind of wasteful computations?

 

 

Thanks again,

 

Adam

0 Kudos
Message 3 of 6
(2,862 Views)

B-locks wrote: Is it highly beneficial to avoid performing this kind of wasteful computations?

YES!!!

 

There are a lot of things that could go wrong when closing and recofiguring a port (missed messages, synchronization issues, bus hardware setup, etc).  Not to mention it takes time, sometimes a lot of time, relatively.


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 4 of 6
(2,852 Views)

@crossrulz wrote:

B-locks wrote: Is it highly beneficial to avoid performing this kind of wasteful computations?

YES!!!

 

There are a lot of things that could go wrong when closing and recofiguring a port (missed messages, synchronization issues, bus hardware setup, etc).  Not to mention it takes time, sometimes a lot of time, relatively.


To the point that you will probably spend more time configuring than communicating!  (Maybe even orders of magnitude more time.)

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 6
(2,845 Views)

Thanks all for the input!

 

Taking your quick tips, I have removed the Sub VIs, minimized the number of Open and Close communications (for VISA and DAQmx), and run a profile of the performance and memory.

 

It appears that the Optimized VI runs for a total time of 62.5 milliseconds while the original runs for 343.8 milliseconds - almost six times and definitely an order of magnitude! I have attached the Original VI, Sub VI, Optimized VI, and an excel sheet with the data.

 

Now that we've moved beyond that issue, I feel as if my method for running the separate commands can also be optimized in some way.

 

I appreciate any and all input, thanks! 

0 Kudos
Message 6 of 6
(2,828 Views)