08-24-2015 10:53 PM
Hi,
Is there anyway that I can set up an order of excution inside a for loop? For example I want to make a LabView program that first take a picture then secondly, upload the picture and after that repeat the first step.
Thanks
Solved! Go to Solution.
08-24-2015 11:05 PM
Wires, Flat Sequence Structure (if necessary)
I would recommend looking at the online LabVIEW tutorials
LabVIEW Introduction Course - Three Hours
LabVIEW Introduction Course - Six Hours
08-24-2015 11:48 PM - edited 08-24-2015 11:49 PM
Dataflow automatically ensures execution order. The upload cannot happen unless the picture has been taken is as available on the wire.
(just don't break dataflow by excessive use of local variables, for example).
08-25-2015 12:46 AM - edited 08-25-2015 12:46 AM
Prefer to to use the 'Error In' and 'Error Out' to every subVI you use, I think that is the best practice and also helps to mainitain the dataflow.
08-25-2015 01:27 AM
@amitwadje wrote:
Prefer to to use the 'Error In' and 'Error Out' to every subVI you use, I think that is the best practice and also helps to mainitain the dataflow.
Not necessarily. Excessive serialization, even if the order does not matter, prevents the compiler from efficiently parallelize the code.
08-25-2015 03:45 AM - edited 08-25-2015 03:47 AM
@altenbach wrote:
@amitwadje wrote:
Prefer to to use the 'Error In' and 'Error Out' to every subVI you use, I think that is the best practice and also helps to mainitain the dataflow.
Not necessarily. Excessive serialization, even if the order does not matter, prevents the compiler from efficiently parallelize the code.
While that is true, the question was about serializing a certain flow of operation and then the error wire is always something I connect too, since it is quite useful to know that the previous function had an error and skipping the next function in that case eventhough there is also a wire for the actual data coming from the source that serves as dependency for serialization.
If things don't need to happen in sequence then I agree that not connecting the error cluster can be often beneficial, although in many typical situations that is often not the limiting factor. Tight unoptimized loops running for many million iterations are usually a much bigger issue for performance than serializing a few VIs unneccessarily. Or using communication functions with unneccessarily long timeouts. 60 seconds to open a TCP connection might have been useful at times when even businesses were connected to the internet through dialup modems but nowadays if you can't connect within a few seconds, it won't happen within 60 seconds either even if the other system is across the planet.
08-25-2015 04:37 AM
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.
08-25-2015 06:16 AM
@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.
08-25-2015 08:01 AM
@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.
08-25-2015 08:17 AM
@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.