LabVIEW
order of execution
Solved!
@Toan_Le wrote:
Hi,
Thank you for your thought on my problem. However, I think I may oversimplify it. Here it my actual program that I wrote( autosnapshot.vi). If you take a look at the last for loop, that for loop contains two part, the first part (the upper one) opens an window and upload a picture on that window and the second part ( the lower one) comands a camera to take a picture. I want the first part be excuted before the second part, how can I do that?
In this case, just use the error cluster to force the order with data flow. You will also want to use the Error In and Error Out on the File Dialogs to make sure they come up only when you are ready for them to.
BTW, this is not an exception to my rule. All of these functions do something with the error.
@Toan_Le wrote:
Would you mind elaborating on how to use error cluster to force the flow? (I am sorry, I am a littile bit slow since I am new to labView)
Wire Error Out of function A to Error In of function B and down the line. By doing this, you are creating a data dependancy between function A and B and then another data dependancy between B and C. This will force A to finish be B can start, and B must finish before C can start. So if you wire the last Error Out of your top function to the first Error In of the bottom, then the top must complete before the bottom can start.
@Toan_Le wrote:
Thanks alot
Thanks are given with Kudos and Marked Solutions (Unofficial Forum Rules and Guidelines)
Yes, the error wire is important here, because the second part of the code should be skipped if the first part completes with an error.
Depending on your experiment, you might even need to include a small delay to make sure that the everything is ready for the second part. In the more general case, you could even implement it as a state machine.
@crossrulz wrote:
@billko wrote:
@crossrulz wrote:
@amitwadje wrote:
Thank you Altebench and Rolfk for your thought on my view,
How about?
If there is no necessity of serialization then we can connect the ‘Error Wire’ in parallel and merge the errors after execution, this way we avoid unnecessary serialization and improve the execution speed.
Thank you.
If you are just adding in the error cluster to VIs that cannot generate an error, then you are limiting the compiler. Let normal data flow do its thing.
But two paths that need to run in parallel and both can cause errors, then you will want to use Merge Error when the parallel section is done.
Unless of course, that VI is a wait with an error passthrough to aid in dataflow execution.
Which I have found is RARE that you actually need. I used to put the error terminals on everything and then one day I just realized I was cuasing slow downs in my code for no good reason. If your code does not do anything with the error, then it does not need to have it. So it runs in parallel with something else. That is the point of data flow.
The only times I have found an exception to this is when I am using global variables or something else that breaks data flow.
I have to disagree about rarity. At least in testing. I often need this if I am communicating with "dumb" equipment that doesn't know how to acknowledge a command. The wait HAS to follow the command. The wait can't happen when it wants to. And it sure beats enclosing the wait inside a sequence structure every time I want to do this.
On the other hand, I do a lot of branching of error wires and re-merge them later if I can imagine errors happening but want parallel execution. Also, properties that I don't care when they get set won't even have error wiring if I don't care when it happens AND I am sure it won't generate an error. (For instance, setting the color of something in my "Init" state.)
billko wrote:I have to disagree about rarity. At least in testing. I often need this if I am communicating with "dumb" equipment that doesn't know how to acknowledge a command. The wait HAS to follow the command. The wait can't happen when it wants to. And it sure beats enclosing the wait inside a sequence structure every time I want to do this.
Ok, I'll give you the wait needing error lines. As many instrument communications I have done, you would think that would be the first thing that pops in my head. But I would would still argue that your wait should be conditional based on the error wire, so it technically is not an exception since it does something with the error wire. Splitting hairs there.
@crossrulz wrote:
billko wrote:I have to disagree about rarity. At least in testing. I often need this if I am communicating with "dumb" equipment that doesn't know how to acknowledge a command. The wait HAS to follow the command. The wait can't happen when it wants to. And it sure beats enclosing the wait inside a sequence structure every time I want to do this.Ok, I'll give you the wait needing error lines. As many instrument communications I have done, you would think that would be the first thing that pops in my head. But I would would still argue that your wait should be conditional based on the error wire, so it technically is not an exception since it does something with the error wire. Splitting hairs there.
Yeah, I am splitting hairs also because I definitely agree with the main theme of your post. 🙂
