HELP!!! I have struggled for way too long.

[billko · Accepted solution]

---

@kerplatz wrote:

It would appear that I need to learn what dataflow is in context of a VI. My concept of a terminal was like passing in parameters of a function in languages like C and Java. I don't understand why the main VI that is now acting like a sub VI has to finish (keep running).

So I thought about what I just said, and I think I get it now. Since the main VI is essentially a while one loop, its execution never stops and nothing gets a chance to be passed in, but if it behaves like a function then it needs to terminate (finish) so it can be called again when new data needs to be passed in.

It occurs to me that what I really want is for the main VI to act like a thread. Is that possible? I do have some things to look into. Thanks.

---

Dataflow Programming Basics in NI LabVIEW - National Instruments is a good place to start, but the gist of dataflow can be summarized in one awesome sentence from that link: "Remember that a node executes only when data is available at all of its input terminals and supplies data to the output terminals only when the node finishes execution."  So according to this sentence, your determination of why it isn't working is fairly accurate.

The easiest way to do make this function is to drop the VI in as a subVI to another VI (which you did) and hook up the data processing code to its outputs.  This is NOT what you are after, so...  Modifying a standalone VI to behave as a subVI is one of the more tedious/challenging things to do because their purposes are completely opposite from each other.  A top level VI is made to "do everything", but a subVI is made to "do something very specific".  So you're going to have to make some design choices here, because your loop will have to move outside the subVI and into the main VI.

[RavensFan]

---

@kerplatz wrote:

It would appear that I need to learn what dataflow is in context of a VI. My concept of a terminal was like passing in parameters of a function in languages like C and Java. I don't understand why the main VI that is now acting like a sub VI has to finish (keep running).

---

I disagree.  In any text-based language, a function doesn't return its parameters until the function is done executing.  If you put a while loop inside of it, it is not going to exit the function until the while loop inside of it ends.  Same thing with LabVIEW if you have a while loop inside a subVI.

The advantage of LabVIEW is that it is easy to do mult-thread applications.  You just have to use the appropriate tools available to pass data in and out while the while loop continues to run such as queues, notifiers, network streams, even global variables if you are careful about not abusing them, or the newer feature of channels.  The terminals are NOT that tool.

[kerplatz]

You keep asking for the VI, and I am not going to supply it because if you try to run it on a computer that does not have the LabWindows application that the VI is communicating to, via a DLL using a TCP connection, then nothing will happen. Besides, none of that matters. It has no issues and works great.

Unfortunately, I don't have time to rewrite the VI by stripping out stuff to simplify the problem. I thought I had explained my problem fairly well using English, or don't you understand English well, i.e. you have a poor grasp of the language. See, I can insult you too.

[altenbach]

---

@kerplatz wrote:

You keep asking for the VI, and I am not going to supply it because if you try to run it on a computer that does not have the LabWindows application ...

---

We can handle broken VIs. No need to be runnable to see potential architectural flaws.

(It is always important to embrace the advantages of dataflow principles, not fight them!)

[kerplatz]

I am pretty certain that the way I created the main VI using a while loop is my most significant problem. Since I learn best doing, I am going to go try a few things that I think will solve my problem which is getting this VI to behave as a Front Panel (it works as expected) and/or a sub VI (terminals pass no data). The user gets to decide which one he uses. I have been told by a knowledgeable NI coder that the VI can behave this way.

Thanks for all the useful input, and I understand that posting VIs can be helpful when giving help, but that should be my choice just as it is yours to help me. One last thing, if I had posted the VI and all you did is tell me where the problem is and exactly how to fix it, then I would not have learned very much. Discovering something in the process of figuring out how to solve a problem is much more educational. Tell me I am wrong!

[Kevin_Price]

People would like to help but there's a long history here that purely verbal descriptions are often inadequate and not-so-rarely outright wrong.  People's *ability* to help is pretty drastically restricted without actual code.

I liked this illustration another recent time this kind of thing came up.

- Kevin P

[Ben]

---

@kerplatz wrote:

I am pretty certain that the way I created the main VI using a while loop is my most significant problem. Since I learn best doing, I am going to go try a few things that I think will solve my problem which is getting this VI ...

Discovering something in the process of figuring out how to solve a problem is much more educational. Tell me I am wrong!

---

According to the way you have described yourself, you are probably correct. There are other personality types that learn differently.

I realize I am late to the game here but as you work to find an answer, it may be helpful if you put both the top-level VI and the called VI in execution highlighting mode (turn on the light bulb) and watch both as the code runs. I tell my noobs to watch their code and when they can get to the point of predicting what will happen they are starting to "get it".

There is a way for the sub-VI to react to changes to controls in the top-level VI using control references to either check the control's values or register (in the sub-VI) for value changes in the top level VI. But those are techniques that should come only after you get a good handle on the data flow idea.

LV and data flow required some learning curve climbing for me when I switched from C to LV. Text based languages are straight forward in that the next thing happens is determined by what is on the next line. Data flow looks at data dependencies and schedules "clumps" as each of the required input are satisfied.

I like that because its lets me work at a higher level thinking about what is involved in each code requirement rather than focusing on in what order I need to do things to achieve my end-goals.

Now whatever you do, make sure you take the time to have fun. After all you are coding in LabVIEW!

Ben