Hello, AlienVI6789. I see you have changed your Forum name.
It is very difficult to follow your code, and understand what you are trying to do. There are numerous examples of "hard-to-understand" LabVIEW code (which can be "solved" by a number of techniques I'll outline in my comments). Here are some suggestions to (a) help you visualize your code and see/solve programming issues yourself and (b) help others understand the "important points" of your code and help you "see the forest for the trees" (if you get what I mean).
- (Almost) never use a Frame Sequence -- it tends to "bloat" the Block Diagram and (if proper Data Flow and use of the Error Line is followed) is very rarely needed) (and you don't seem to use it in your code).
- Until you become "something of an expert" in LabVIEW, always use the Error Line (running as straight as possible left-to-right) for all functions that have Error In/Error Out terminals.
- "Hide the details", especially of "messy computations", by writing a sub-VI with a name of "what it does" ("Compute Charge Time" or something). Use a 4-2-2-4 Connector Pane (the default), with Error In/Error Out on the lower left (input) and right (output) terminals, and try to keep the inputs to 1-3 wire (if there are multiple parameters that are related, bundle them into a Cluster and bring in a single wire). Give you sub-VI an Icon (use the Icon Editor), something as simple as a Big Square Box with 2-3 short words ("Compute Charge Time") so you and we "know what it does".
- Use the Error Lines to show flow of data ("Do this first, then that ..."). Keep the wires short, neat, and running as straight as practical (the Error Line should be straight, usually).
- Strive to make the entire Block Diagram fit on a single Laptop screen. [Most of my Top Level VIs, "Main Whatever", and virtually all of my sub-VIs, do this -- makes it easier to "examine for bugs" by me, and much easier to explain to my colleagues).
LabVIEW differs from other programming languages because it is a Data Flow language. I presume you know the three basic principles of Data Flow, but just in case, they are:
- A Structure does not start to run until all of its Inputs have data.
- A Structure does not express outputs until it finishes executing.
- Within a Structure, components not connected by wires have no particular order of execution (i.e. their position within the Structure tells you nothing about when they can run).
There are some exceptions (Queues, Notifiers, Asynchronous Channel Wires), but you don't seem to be using any of these in your code. So "disconnected Loops", by the rules of Data Flow, all operate independently all the time. If they need to "share data", then you either have to connect the loops by "wires" or "beam the data between them" someway (I'm not going to mention Global or Local Variables).
From looking at your code, I can't easily see (or understand) what the various loops are supposed to be doing. It would help me (and, potentially other readers of this Forum) if you gave a brief description of the (independent) duties of each of the loops, perhaps mentioning how they might interact with other loops.
A not uncommon mode of interaction is that a loop "looks for data", and when it finds some, "sends it off for processing" (which might involve "saving it to disk"). This two-loop "data gatherer->data processor" is called a "Producer/Consumer Design Pattern, and LabVIEW has a number of ways to do this, typically using Queues or (Stream or Messenger) Channel Wires.
Many LabVIEW programs have a single While Loop with an Event Structure inside, monitoring (among other things) a single Boolean called "Stop", looking for a Value Change Event. When this happens, the "Event Loop" acts as a Producer and sends the value the Stop button ("True") to all of the other loops, where the value gets wired to the Stop Indicator. As long as the Loop is running and once a loop cycle "sees" its Stop indicator, pushing the Stop button will cause that loop to stop. One Button to Stop them All, One Button to Bind them. One Button to Rule them all, and in the VI, find them. In LabVIEW, where the Good Code lies.
Bob Schor
