LabVIEW
"case structure" execution completion
No, this is not guaranteed. If there is no data dependency between the case structures, both can execute in paralell. Try it yourself: Place a while loop with a small wait in each case structure and display the iteration terminal of both. Both will increment!
@jspaarg wrote:
Assume a while loop with multiple case structures in it.Assume that there are no wires connecting any of the case structures.Is it guaranteed that once execution enters a case structure that all VI's and variables modified by the structure will be completed prior to another case structure being entered?
@MattH wrote:
You could, I assume, disable multithreading and see if this works the way you desire.
NO! This has absolutely nothing to do with multithreading, so disabling multithreading will not "solve" anything. 🙂
jspaarg, please explain what you want to do and why something like this is important. Most likely, you're chasing the wrong ideas based on some misconceptions.
In order to efficiently write LabVIEW programs, you need to familiarize yourself with the basic details of dataflow programming. If you require a certain execution order, simply create a data dependency.
Just limit your use of local variables and the rest will fall into place naturally. Always go with the dataflow! 😉
Message Edited by altenbach on 07-19-2006 12:28 PM
@jspaarg wrote:
1: The block diagram tends to be extremely long from left to right:
2: More importantly, there are wires everywhere. Even if the wires are kept to a minimum it still winds up being spaghetti code (in looks if not implementation).
Hmm, maybe you're doing something wrong. A local variable is a 2D diagram object with a length depending on the name of the control/indicator and thus takes up significant horizontal and vertical diagram space. A wire connecting two objects is only a few pixels and takes up much less diagram space.
If there are many wires always going to the same places, bundle them together.
Also have a look at my old post here: http://forums.ni.com/ni/board/message?board.id=170&message.id=112401&query.id=0#M112401
@jspaarg wrote:
I have gotten into the habit of using local variables (I realize that the code is not as efficient, but I believe it is far more readable).
A diagram peppered with local variables is significantly less readable in my book, because there is no way of tracking where the data goes, where it comes from, how stale it is, and what other part of the diagram modified it last. In contrast, on a diagram withhout locals, it's just "follow the wire". You know exactly where the data comes from! 😄
Line based code executes sequentially. If you translate each statement into labview using local variables, it is the same as completely scrambling the statement order.
Dataflow has huge advantages, even more so in the future where multicore, multiCPU, etc. systems become more prevalent. I would suggest you fully embrace it and "go with the (data)flow". Why first break dataflow with locals, then enforce dataflow with sequences (...and then argue that it makes the diagram smaller and more redable. ;)). Something does not quite add up. 😮
@jspaarg wrote:
The problem is that if "Update" gets set true prior to the data that needs to be updated is modified, then the update case structure could be activated and perform an update on data that is not yet ready.
You just described a typical "race condition" directly caused by the use of local variables. These are difficult to troubleshoot and track down.
It is hard to make more detailed suggestions without seeing the code, but I am sure there is a better way. Maybe you should take a few steps back and look at the diagram. What can be improved? Is there repetitive code that could be replaced by a subVI? Are logical execution traces aligned horizontally or does everything go criss-cross?
Good luck!
