Code golf: stop two while loops with guaranteed iteration ratio

Question

Proposal
In the vein of the Perl tradition, I'd like to see if there's any interest in solving short programming puzzles in LabVIEW. Anyone can post a problem and define the rules for solving it.
Here's a beginning/intermediate question to whet your "palette".
Description
With one user-action, how would you stop two while loops such that the ratio of their iterations is the always the same? One concrete way to visualize this situation is in taking measurements: two instruments use the same timing source to take measurements, but second divides the clock down so that it is an integer factor slower than the first. For example, if the slower instrument is four times slower, then at the end of the VI, if the slower instrument takes 100 measurements, the faster instrument has taken 400.
Rules
You may only use vi.lib
You cannot include any other subVIs
Your solution must pass for loop1 interval as low as 25 ms
Template (attached in LabVIEW 2009)
If folks are interested in this, then let's figure out how to make future problems better. Please post your suggestions and critiques, but only if you also post a submission ;-)
Solved!
Go to Solution.
Attachments:
Multirate Loop Code Golf.vi ‏11 KB

Answer 1

Norbert_B wrote:
a) You work with an integer factor of speed. While this matches many application areas, there are still cases where the factor has to be floating point (e.g. 2.5). Additionally, the factor might "invert", so the master loop runs slower than the slave (factor 0.5 for instance).
It sounds like you're about to post another code golf question. If you think the problem scope is too small, you're welcome to fashion one to your taste. Thanks for volunteering :-D
Norbert_B wrote:
b) This example does not take into account that the hardware has to be synchronized with more accuracy than the software supplies (PXI?). If hardware synchronization is required, there are two possible ways:
- The factor can be included in the synchronization (using PLL for instance)
- The factor has to be software implemented by data reduction for the task running at the lower pace.
Hrm, maybe puzzles aren't really your thing after all. You are correct: I did not define every constraint that can lead to a provable best closed-form solution, but that does not prevent people from stating their assumptions and forming creative, well-reasoned, and still correct designs. I overlooked this reading of the description and neglected to add a statement that said solvers were free to add their own conditions. I will do so in the fugure :-)
If we choose the first of your suggestions, the VI must still retrieve the data at different rates. You can dedicate a loop for each instrument to decouple any jitter and latency introduced by their connectivity or internal operation; this adds some margin of safety when there is thread and driver contention. You can also implement a single counting loop like altenbach and forego the multiloop complexity.
Norbert_B wrote:
c) You don't state anything about "what happens with the data". Is this time consuming? Does it introduce additional delay in loop iterations? Is it OK to have data loss?
I don't know -- you decide, you disclose, and you solve :-)
In my specific situation, the measurements are time consuming and do add delay (each data "sample" is 5-20 megabytes), none can be lost, and the data must be available for others to analyze later. In addition, the amount of data is saturating the hard disk throughput. If a particular write takes too long, the instrument driver may overwrite a yet unfetched sample, which is unacceptable. I did not add these details to the problem discripton becuase they don't impact the puzzle.
I don't want to burden people with my situation and ask them to solve my problem: I want to encourage them to bring their intuition and experience to a discussion. This is the design process at its heart: understanding why and how constraints affect your decisions. If a person states the additional conditions they've assumed, readers can learn why, and more importantly, when a Notifier might be more desirable than an Occurance or a Queue more robust than a Data Value Reference.
The best NI-published advice for stopping multiple while loops (https://www.google.com/search?q=labview+stop+multiple+while+loops) is laughable (and is the "solution" in my template).
Would you care to re-approach and contribute to this puzzle? I suspect you have a lot to offer :-)