05-05-2019 07:03 AM
I have a problem, see pic attached:
I got three loops, they finish all at different times and should then pass forward data to the next VI.
So as it's now, i have to WAIT till the slowest finished - then only the data gets forwarded, all loops then reset simultaneously and start from the beginning.
This is sort of a huge waste cause the fastest one could already run like 5x in that time.
I want them all to run the fastest they can and forward the data once they are finished.
Is there some sort of LV technique/concept that can tackle that?
05-05-2019 07:21 AM
Yes, Producer/Consumer. But depending on the later VI, it might not help you with throughput. Does the later VI require all of the inputs? If so, you can pass the data to another loop which could wait for all data via Queues, and have your Producers (i.e the 3 source items) run more quickly, but the later VI won't start until the first 3 finish (i.e the slowest finishes). What should happen with new data from the fast VI in that case?
If you have multiple different data sources that are processed independently, then P/C is probably much more useful. You can have each of them run in a separate loop, and enqueue data as the finish. The consumer can dequeue data as it becomes available, and process appropriately (you may have to also encode the source, if the processing is not the same for all 3 sources).
05-05-2019 10:54 AM
Have you heard of the Principle of Data Flow (which is central to understanding LabVIEW, and sets it apart from many other languages such as Fortran, C, Basic, Matlab, etc.)? It says that a Structure or Function doesn't start executing until all of its inputs are satisfied. The important corollary is that Structures and Functions that have no input/output dependencies can run in parallel.
@cbutcher described the Producer/Consumer model that lets a Consumer run independently of the Producer (so the Producer can, in principle, run faster, but not "forever" as the data need to go somewhere ...). If you have three Producers that run at different speeds, but you need to "Consume" from all three inputs at the same time (meaning whatever you are doing requires the "next" set of data from all three), then you've created another dependency and the Consumer can run no faster than the slowest Producer. So a better diagram, if this fits your data situation, is to think about three independent Producers feeding three independent consumers. A simple model of this is three processes where you collect three independent sets of data, and want to "do something with each data set" as it comes in (say, make a time-consuming plot + save to a dedicated disk file), which maps "naturally" into three independent Consumers.
Bob Schor