LabVIEW
Repeating case structure
Chip,
Please consider rethinking your code from scratch, the code is virtually unmanageable and full of race conditions due to overuse of local variables. It will never work as desired in its current form.
You might also read my comment here: http://forums.ni.com/ni/board/message?board.id=170&message.id=112401&query.id=0#M112401
Unecessary code: Once you create the image in frame 0, its content never changes. There is no need to carry the wire and rewrite the same data to a local variable of the image in subsequent frames.
I would suggest NOT to use formula express VIs for simple operations sich as "divide by two", "2*x1*x2", etc. Since the formula is hidden it is impossible to see what is going on without clicking the express VI. Use plain wires and basic math nodes!
Don't use value property nodes if the actual wire is right there. Just use a plain wire, eliminating the property node (property nodes pose a sever performance penalty).
It is also very confusing to have multiple terminals with the same name (e.g. "Trial Duration (s)", etc.). You have four (!) instances of basically the same while loop, where the only difference is one diagram constant. They can all be combined into one and have the diagram constant be a function of the current "state".
Race Conditions!!!
As an example, lets have a look at your first FOR loop. Since several code elements are chopped up without any direct data dependency, there is no way to tell what occurs first. (LAbVIEW does NOT execute left to right!). For example, you cannot tell if "Number of Bars Drawn" (A) gets written first or one or two of its two locals (B,C) get read first. Similarly, you cannot tell if D and E get updated before F and G get read. In a typical iteration, you'll probably get a random mix of stale and current values. There is no way to predict it.
As an example, lets have a look at your first FOR loop. Since several code elements are chopped up without any direct data dependency, there is no way to tell what occurs first. (LAbVIEW does NOT execute left to right!). For example, you cannot tell if "Number of Bars Drawn" (A) gets written first or one or two of its two locals (B,C) get read first. Similarly, you cannot tell if D and E get updated before F and G get read. In a typical iteration, you'll probably get a random mix of stale and current values. There is no way to predict it.
The insert shows an alternative implementation. Dataflow exactly determines the sequence of events and no race condition can occur.
I am sure with very little work your code could be simplified to 10% of its current complexity. At this point we can start troubleshooting the problem you mentioned. Most likely, everything will fall into place. 😄
Message Edited by altenbach on 06-28-2006 01:09 PM
