LabVIEW
Flat Sequence not Initiating
Solved!
@endlessOranges wrote:
Why are they consuming so much processing power in the false case? Most of them aren't doing anything in that situation.
Yes, they are doing something!!!!
Since there is no small wait, they spin as fast as the computer hardware allows, millions of times per second! Constantly polling the buttons values and local variables.
Even a 1ms wait would reduce the CPU consumption by many orders of magnitude.
Well, I don't know your system enough to give detailed advice, but as a first step you should chose a suitable code architecture and eliminate some glaring programming mistakes and inefficiencies. Here is some general advice:
- Use a state machine with one loop dealing wit the UI and another loop dealing with parallel background processes. Look at the design templates that ship with LabVIEW.
- Create the virtual channel for the digital ouput exactly once before any loop. Don't create the same virtual channel over and over in two places in parallel without ever closing it. Create it once before the loop, write the points as needed inside the loop, and close it after the loops have finished at the end of the program.
- same with the VISA stuff. Configure the port once before the loop and not over and over. Close the VISA session once the loop has completed.
- Eliminate all these local variables, most (probably all with good coding) are not needed.
- When you write to the file, the use of a dataqueue of size=1 to basically convert a scalar to an array with one element is just silly. Just use "built array".
- Eliminate the dataflow flaws and race conditions. For example if somebody would switch the "system shutdown" button on and off, some loops would terminate while others would keep running. It is just not predictable.
- Use subdiagram labels to label the loops. Free labels may go elsewhere after a diagram cleanup.
- Change some of the blue diagram constants to U32 to eliminate the coercion dots.
- You write to "backwash pump error" in two different locations. How do you know where the problem occured?
- Your "sensor error" indicator only gets written once the program is stopped. Wouldn't it be more interesting to see these errors while the program is running? That terminal belongs inside the loop!
- etc....
Built array is a labview primitive and highly optimized.
The queue ptbypt is a subVI with lots of code (you can double-click it and inspect it). Firstly, you have the subVI call overhead, then you are invoking a huge queue machinery for basically nothing. It also retains old data until it gets overwritten or exceeds the configured size. It has four inputs and produces five outputs, but you only use one of them. It is like using an industrial robot to remove the toast from the toaster or use the supercomputer cluster ant the National Atmosperic Reasearch Center in Boulder to solve 1+1=2. Definitely possible, but there are easier ways.
Built array works with (almost) any datatype (strings, paths, numeric, references, etc.) while the queue ptbypt works exclusively with DBL. (There is a second version in the palette that works with complex double). This means that if you next time work with integers, you would need to re-learn from scratch.
And no, they don't look similar!
