04-08-2016 02:11 AM
I am a newbie just arrived from VEE, so please be patient.
In VEE I always have sequence-output and sequence-input pins on any bow that allow me to force the execution of a box.
In labview instead I dont see those, so I guess the execution order is always data-driven, correct?
Now, I just created some local variables where I want to store some internal informations, so I have the objects in the front panel, and the "set local" connected to them in the flowchart:
(as you can imagine, I'm modifying a complex program, I didnt write it...)
Now, since these couples: "Acq length", "timeIntensity", "Acq Time Start", as a whole doesnt have any input/output, I dont see how to force their execution. In fact, they are never executed ...
what am I doing wrong? Thank you for your help...
Solved! Go to Solution.
04-08-2016 02:26 AM
On the right side of the main LabVIEW forum page, there are links to tutorials. Try them out. Your experience with VEE may help you, but it may hinder you, also. It might be just similar enough to be really confusing.
04-08-2016 03:29 AM
> On the right side of the main LabVIEW forum page, there are links to tutorials. Try them out.
thank you for the suggestion...
I am already following at least 3 manuals/tutorials in parallel,
but nowhere I did find an answer to this question.
From what I saw (please correct if I'm wrong), the execution flows according to:
1) the data flow
2) the error in / error out pins
... since in my case neither is available, I'm really at a loss about what to do.
P.S. just in case my use of local variables be considered not necessary: I transfer data using wires whenever is possible, but in this case I use locals because I set some values inside a given case of a case structure, and I have to use them inside another case.
If data transfer by wires between cases is possible, I'll be happy to learn it!
Alessandro
04-08-2016 03:48 AM
You are correct that data flow is the primary mechanism for determining execution order (although there are also things which can add delays, such as the dequeue element function in your code, which will wait if the queue is empty and will only continue when somewhere else in the code a value is added to the queue). Error terminals are just a specific case of this principle.
I'm not actually sure about your question. You say that they "don't execute", but they would. The code just doesn't do anything, since you're simply reading the value from the control and then immediately writing it back in. There's nothing preventing you from creating additional local variables for the same control and using them in the other cases.
That said, you should be careful with that, as it makes it very easy to create race conditions. The most common answer to your question about accessing values in other cases is a shift register, which passes a value between the iterations of a loop. You could create a state cluster holding all of the current relevant values and then bundle and unbundle it (by name) in the relevant cases. This isn't functionally different from using locals, and it has some disadvantages of its own, but it's generally preferable and makes it harder to create race conditions.
04-08-2016 09:28 AM - edited 04-08-2016 09:31 AM
@alzyx wrote:> On the right side of the main LabVIEW forum page, there are links to tutorials. Try them out.
thank you for the suggestion...
I am already following at least 3 manuals/tutorials in parallel,
but nowhere I did find an answer to this question.
From what I saw (please correct if I'm wrong), the execution flows according to:
1) the data flow
2) the error in / error out pins
... since in my case neither is available, I'm really at a loss about what to do.
P.S. just in case my use of local variables be considered not necessary: I transfer data using wires whenever is possible, but in this case I use locals because I set some values inside a given case of a case structure, and I have to use them inside another case.
If data transfer by wires between cases is possible, I'll be happy to learn it!
Alessandro
You're on the right track, except that the error in and out is just another example of data flow.
LabVIEW data flow can be summed up in two sentences:
A node will not execute until all inputs are satisfied.
A node will not produce an output until the node has executed completely.
When you boil everything down to basics, those are the only things that determine data flow. If you take those two statements literally, any case where it seems that the order of execution is ambiguous really is ambiguous - and you'd better fix it if one node actually has to execute before the other.
This is definitely a case of "easier said than done". 😄