LabVIEW
Array will not change its forced input values.
Solved!
You write hardcoded values to e.g. "stage min" in frame 0 of the big sequence structure via a local variable.
(btw, you VI suffers from a severe case of localitis&sequencitis)
atomless wrote:On the front panel there is a set of values which list the minimum location of a slide (there are five or six of them). [I am not near a computer where I can find out.] When I try to change the values of the minimum value they always revert to default values everytime the program is loaded.
Obviously, you haven't grasped the gist of LabVIEW, why else would you place a diagram comment as follows:
It looks like Labview will not allow different array elements to be initialized to
different values. What a bullshit excuse for a programming language. In
any case, then, for the motion stage limits to make sense, I need to wire their
limits in here.
If you want an array with different values as defaults, simply fill the array, then make the new value the default (of the array, not the element!). Save the VI.
Well, this thing was written by a text programmer, because it has no resemblance to dataflow but is written like a text program. Instead of doing a few LabVIEW turorials, he simply started programming like a wild boar in a vegetable garden.
He basically declares all "variables" on the left, the reads and writes to them via locals. Since this breaks all dataflow, we need to add sequence structures to make sure things execute in the correct order and avoid race conditions. Each frame being a "statement".
Each local variable forces another datacopy in memory, so things are not very efficient.
See also this discussion.
We also have a long thread about the pitfalls of local variable overuse. I think I add this example to it too. 😄
Even though the code is peppered with sequence structures, there are still race conditions. Have a look at the code in the image.
This sequence frame has 3 independent code fragments and they can execute in any order. Let's look at the three "stage mv" locals. Most likely, the programmer expects that it receives a new value in A before it gets read at location B. however, there is a 0%--100% chance that location B gets read first, obtaining a stale value, The final value of "stage mv" when the frame finishes could be either from A or C, depending on execution order. The behavior is completly unpredictable. Even if it works now correctly by accident, small code changes or a LabVIEW version upgrade could invert the order, leading to unpredictable results.
