LabVIEW: Concerns with Local Variables and Program Readability

[Nukem]

Hello everyone. I have been hired for the summer to work at my University setting up a new lab. Things are going well, but I have some concerns with my main VI. I am a new labview user coming from a C++ background. I have gone through many iterations of adding features, fixing bugs, and making my program readable. Before the last major "cleaning" my program was so bulky that I could not see the whole thing at once on my screen. My goal was to fix this problem. My solution contained three parts: Use a state machine to show only parts of my code at a time, Remove as many wires as possible, and use in place element structures to manually position my code. 

I have since come across problems writing other programs that brought me here, and I saw a series of posts condemning new programmers for their use of local variables instead of wires. I am sure my use of the element structures as fancy boxes that I can exclude from auto cleanup is also a terrible practice.

Having done some more reasearch on the topic I see that local variables add duplicate entries in the memory and that removing them can considerably speed up execution time. I do have a delay programmed in one part of my code, but the rest of it can run as quickly as it can as far as I am concerned. 

I have attached my main program. Looking at it I think I have done a nice job of making it readable. But I am also not an expert labVIEW user.

How do I balance efficiency (not using local variables, these element structures, etc) and readability. Before making these changes there was so much going on, and so many wires all over the place that I could not even tell what was going on, let alone my professor. I would also really like to be able to see my whole program without having to scroll around on this lab computer (1280x1024 resolution). 

Any tips on how I can achieve efficiency, simplicity, and common readability would be greatly appreciated. I feel like I have done the latter while sacrificing the first two. In the end the three should probably be equally as important. 

Thanks.

Nukem

LabVIEW 2010

[altenbach]

That's the first time I have see the use of in place element structures to be used as (mostly unecessary) sequence frames. What's the point??? That makes absolutely no sense!!!

Obviously, you have implemeneted a literal translation of text based code into LabVIEW. and that fits like a square peg into a round hole. You might want to learn a little bit about dataflow. How many times do you possibly need to bundle the same set of references? that should be done once before the main loop.

I am also a bit suspicious about the "transparent" (e.g. fast timeout) event structures trapped deep inside other structures. You even have an event structure inside another event structure! Bad!!!

[Nukem]

Honestly the in place element structures were just a random choice for a box. For my specific purpose of locking down parts of my code so I could manually move things without them being affected by auto-cleanup. They are easily removed at this point, yes. And I said initially that I wasn't using them for their original purpose. I just as easily could havee used the sequence frames. But again, I was only using them to help cluster pieces together. Before this last cleaning step none of them existed. 

If I was translating a text based program I wouldn't need labview. But yes, I took two courses in C++ programming and have experience with Mathematica and MatLab. So in my head I know what I want to do, and I have been learning as I go to try and implement things. 

The data flow was better before I moved everything to local variables for cleanliness.

The references have been moved, as they were place holders while I figured out how to disable most of my front panel but not all of it. 

I am not sure what you mean with the event structures. The nested event structure you are referring to is a pause/resume control I made with the help of posts on this forum. It waits for the pause button to be pressed, stops everything, and waits for the resume button to be pressed. Enabling and disabling these controls as needed. 

I am going to work on returning this program to data flow now that all of the features I want have been added with the ease of being able to see the whole program, and I will reupload the VI with the request that everyone helps me clean it up in an efficient, logical, and professional way. 

Yes, this is new to me, that is obvious. And there are little nuances hiding everywhere that have to be learned.

[altenbach]

Sorry, I don't understand your definition of "cleanliness". Local variables typically make a diagram look dirty. 😮
In any case, you definitely need to untangle your event structures.

[aputman · Accepted solution]

As altenbach said, fix your event structures.  There should really only be a need for one event structure, especially for a simple VI like this (I counted 3).  This is the second time I have recommended this today but go get JKI State Machine.  I use that as the foundation for most of my interfaces. 

Here is one way to handle the Pause with JKI.

[Nukem]

My definition of clean is simply that I can easily see what is going on, and someone who did not write the program can see what is going on. WIth a thousand wires coming from different places (tunnels, shift registers, etc) it can take 30 seconds or more to trace back a wire through its shift registers to its source to find out what a certian wire really represents. 

Spaghetti wires are not clean in my opinion, and while local variables may not be efficient. There is really no arguing for any reasonable person that minimizing the distance between the source of the data, and its destination, with the least amount of turns, crossovers, tunnels, registers, etc. Is easiest to look at and understand. I used the local variables so that there were virtually no wires to clutter the diagram. Only specific detailed information. 

Also, I don't understand what is wrong with nested event structures. The resume event can only occur after the pause event, so what is the issue having it inside the pause event? 

I am sure the JKI suggestion will work and works better in more general cases, but it also appears to be more complicated than I really need. 

[RavensFan]

---

@Nukem wrote:

Also, I don't understand what is wrong with nested event structures. The resume event can only occur after the pause event, so what is the issue having it inside the pause event? 

---

What happens if you hit resume before you hit pause?  Even if an event structure is not currently in the path of execution, it is still accumulating events waiting to process them once the event structure does get in the path of execution.

[crossrulz]

I haven't looked at your code at all but, unless you took care of a little setting, try pressing the Resume button when not "paused".  The front panel will lock.  That's one reason embedded event structures are bad.

As has been said, you should have 1 event structure in a given VI.  There's an Event Structure Caveats somewhere in the LabVIEW help that will clear this subject up some more.  I need to dig around to see if I can find it.

[Nukem]

I was already disabling everything that wasn't supposed to be touched during runtime. So yes, the resume button is disabled until pause is pressed, and vice-versa.

I initially used only one event structure for run, pause, stop, and resume, but I was having issues getting the program to return back to the right state in the state machine, since it doesn't know where it came from. 

By having it seperate I made sure the program finished a state before pausing, and then went to the correct state when resuming. 

Thank you everyone for your responses. I wasn't sure what I needed help with since I have been self teaching myself as I go with whatever has worked. Learn as you go clearly isn't the best method, but I didn't really have a choice. 

Once I have cleared up all these conventional issues we will sort out how to clean this program in a way that labview experts agree, however backwards it seems to a C++ programmer. 

[aputman]

---

Nukem wrote:

I am sure the JKI suggestion will work and works better in more general cases, but it also appears to be more complicated than I really need. 

---

JKI is the exact same construct that you have used in your VI except that it is string based and contains a cluster of data elements that you define, much like a class, that are always available in any state.