LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sub vi not peforming like the same code does either when the sub vi front panel is visible, or the code is brought to the top.


@SciManStev wrote:

I am including a large program, just so you can see what mine look like. I won't include the sub vi's but this is what I have been doing. I accept that I can, and will use what I have learned to do better.


Yikes! This code would never be allowed in our group. It is a miracle it works at all. I have no idea how you maintain that. There is no design or structure. As I said earlier. You really need to learn about state machines and forget that the stacked frame structure ever existed.

 

As to your comment about reading all of the test data in the beginning, there is nothing inherently bad with that. What is bad is that you pass it around in local variables. At a minimum you should use clusters and arrays. However, reading just the data you need when you need it is not a bad thing either. As I mentioned, our system has over 200,000 test points per device. It would be very inefficient to read all of that data at one time and pass it around the system. A good rule of thumb is you should only give a module the data it needs. If you are passing in data it doesn't need or use it this is a red flag that things can be improved. Once code starts getting more data that it needs or doing more than one basic task your code starts becoming too highly coupled and it makes it very difficult to get any type of reuse.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 11 of 20
(261 Views)

First as others have said you really need to learn to write in state machine format or something structured especially if (a) you or your company ever expects for someone else to be able to pick up the pieces and use/modify your code when you leave (b) if  you ever want to work on software as a member of a team or (c) you expect to ever pick up the code after several years and make minor mods to it.

 

I opened your Generic ATP program and immediately gave up as it is unintelligible until you learn what you were doing in each state frame, subframe, conditional, etc.  I am sure that your brain works fine with the details all buried like they are but I can assure you that most folks would have a really hard time dealing with such a structure. 

 

With a state machine I use enumerated strings or strings for the state control and I generally have a state called init, another what next, wait, or something which is where the program spends its idle time or makes branches out to other parts of the program.  Oh also my default state is always error.  Further when an error occurs within a state, the name of the state where the error happened gets prepended onto the error message so that it is easier to track down.

 

Second when you pass software around on a forum like this it is useful to save it as a .llb file with the top level vi marked as such in the .llb file.  This way all of the the subVIs, type defs, etc. go along for the ride.   Often times it is bad form to use .llb when you are doing complicated programs and all but it is a good way to pass everything that someone needs from computer to computer.

 

Third.  As others have said you probably have some type of race condition and (my two cents) it is acting OK when you have the subVI open because the program is taking machine cycles dealing with displaying what ever is in the subVI.  When the subVI is closed it is not using those cycles and the timing gets changed.  An example if you use a tab structure and it has a graph loaded with data (or was it a giant array of data I forget) the program runs a lot faster when that tab is closed and you are looking at a tab with very little data activity.

0 Kudos
Message 12 of 20
(254 Views)

Yeah, "read at the beginning then keep them around" is actually a very solid technique. It's just very hard to maintain when they're kept separately. Use a cluster in a shift register to contain things and wrangle it all around.

 

One thing to consider... please don't take everyone's advice here as getting dunked on. You're clearly very willing to learn and discuss and take advice, which is very commendable. Everyone here has written some monster VI's that take up gobs of real estate, and we've all been down the "path of enlightenment" where we convert a monster into manageable chunks. When most of us say "This code technique is a bad one" it's because we've gone down that path before. I'd be willing to bet that 99% of everyone here has made a VI with a ton of local variables in it, and the ones that haven't were likely mentored by someone that DID do those things.

 

In other words... thanks for being a good sport and talking through things. Most people here are super willing to teach if someone is willing to learn. Things can sound harsh and critical but don't take it personally. You're being very amenable to learning, so if you have questions about why a certain practice is bad, ask away! We're happy to help 🙂

Message 13 of 20
(245 Views)

Hi SciManStev,

 


@SciManStev wrote:

I am including a large program, just so you can see what mine look like.


Well this is just a tiny example from that VI:

Atleast you were very busy in creating this stacked sequence with 75 frames to place a single local variable into each frame just to initialize 75 indicators to the same value! (From a code review point of view: how do you verify you added all the locals you wanted to add into this structure?)

 

I will recommend the same as anybody else in this thread: rework (or better: start over from scratch) the whole VI…

Best regards,
GerdW


using LV2020 on Win8.1+cRIO
0 Kudos
Message 14 of 20
(210 Views)

I agree with many (if not all) remarks and suggestions, BUT: what about the original question?

Honestly, for all the improvements one can apply, I don't see why showing the FP can change the behaviour of the vi. Provided that no UI interaction occurs, of course.

Paolo
-------------------
LV 7.1, 2011, 2017, 2019
0 Kudos
Message 15 of 20
(190 Views)

Hi Paolo,

 


@pincpanter wrote:

I don't see why showing the FP can change the behaviour of the vi. Provided that no UI interaction occurs, of course.


  • I would be very careful when reading from/writing to controls/indicators connected to the connector pane: their terminals should always stay outside any structures. (The OP didn't care about that…)
  • I would also be very careful when reading from a local variable "because" the terminal ("Level count") is used in a later frame of the stacked sequence. Especially when that control also is connected to the connector pane…

Even this "small" subVI should be a statemachine, with a shift register for the internal data…

Best regards,
GerdW


using LV2020 on Win8.1+cRIO
Message 16 of 20
(184 Views)

@pincpanter wrote:

Honestly, for all the improvements one can apply, I don't see why showing the FP can change the behaviour of the vi. Provided that no UI interaction occurs, of course.


Just having the front panel open will slow down a VI just slightly.  In this case, the speculation is that the code is being slowed down just enough to get lucky on a race condition.  Similar to if you used Execution Highlight and suddenly your code works.


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
Message 17 of 20
(175 Views)

@SciManStev wrote:

I am including a large program, just so you can see what mine look like. I won't include the sub vi's but this is what I have been doing. I accept that I can, and will use what I have learned to do better.


I agree with what the others are telling you, but before you can comfortably move to state machines you need to learn how to encapsulate. And I'd know because the first two LabVIEW projects I delivered were not all too different from the, frankly, abomination of a VI that you have posted. And I was lucky enough to discover, mostly by sheer luck, the book that changed it all for me and set me on the path of implementing sustainable source code:

 

A Software Engineering Approach to LabVIEW, Jon Conway, Steve Watts, 2003 (that same Watts is still around on this very forum, by the way)

 

It will teach you how to encapsulate code into maintanable subcomponents, or as some would call it, to abstract functionality. And once I learned that, all my (nested) sequence structures disappeared, everything became readable, block diagrams shrunk and debugging became a breeze. Once you master that the transition to state machines will be all the much easier, since they are nothing more than stacked sequence structures that don't have a set sequence between the different states. Can't recommend that book strong enough to you.

"Good judgment comes from experience; experience comes from bad judgment." Frederick Brooks
Message 18 of 20
(114 Views)

@Dobrinov wrote:

@SciManStev wrote:

I am including a large program, just so you can see what mine look like. I won't include the sub vi's but this is what I have been doing. I accept that I can, and will use what I have learned to do better.


I agree with what the others are telling you, but before you can comfortably move to state machines you need to learn how to encapsulate. And I'd know because the first two LabVIEW projects I delivered were not all too different from the, frankly, abomination of a VI that you have posted. And I was lucky enough to discover, mostly by sheer luck, the book that changed it all for me and set me on the path of implementing sustainable source code:

 

A Software Engineering Approach to LabVIEW, Jon Conway, Steve Watts, 2003 (that same Watts is still around on this very forum, by the way)

 

It will teach you how to encapsulate code into maintanable subcomponents, or as some would call it, to abstract functionality. And once I learned that, all my (nested) sequence structures disappeared, everything became readable, block diagrams shrunk and debugging became a breeze. Once you master that the transition to state machines will be all the much easier, since they are nothing more than stacked sequence structures that don't have a set sequence between the different states. Can't recommend that book strong enough to you.


Another good book is the LabVIEW Style Book by Peter Blume.  Sounds like they both talk about the same things.

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.
Message 19 of 20
(88 Views)

@billko wrote:

@Dobrinov wrote:

@SciManStev wrote:

I am including a large program, just so you can see what mine look like. I won't include the sub vi's but this is what I have been doing. I accept that I can, and will use what I have learned to do better.


I agree with what the others are telling you, but before you can comfortably move to state machines you need to learn how to encapsulate. And I'd know because the first two LabVIEW projects I delivered were not all too different from the, frankly, abomination of a VI that you have posted. And I was lucky enough to discover, mostly by sheer luck, the book that changed it all for me and set me on the path of implementing sustainable source code:

 

A Software Engineering Approach to LabVIEW, Jon Conway, Steve Watts, 2003 (that same Watts is still around on this very forum, by the way)

 

It will teach you how to encapsulate code into maintanable subcomponents, or as some would call it, to abstract functionality. And once I learned that, all my (nested) sequence structures disappeared, everything became readable, block diagrams shrunk and debugging became a breeze. Once you master that the transition to state machines will be all the much easier, since they are nothing more than stacked sequence structures that don't have a set sequence between the different states. Can't recommend that book strong enough to you.


Another good book is the LabVIEW Style Book by Peter Blume.  Sounds like they both talk about the same things.


That book would be the next one on my list to recommend, but they are very different books, in my opinion, and deal with different aspects of the development process. I, personally, explicitly don't agree with some of the things as outlined in the LabVIEW Style Book, but can understand why the author does it the way he does. Either way, absolutely worth the read. Actually, it is a borderline must to own those two books.

"Good judgment comes from experience; experience comes from bad judgment." Frederick Brooks
0 Kudos
Message 20 of 20
(75 Views)