Code golf: stop two while loops with guaranteed iteration ratio

[MacNorth]

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 😉

[MacNorth]

Here's one implementation that uses 

Spoiler

a Notifier.

[altenbach]

I would use a single loop running at a common factor of the two rates, then use case structures to enable each case depending on the required multiple of the iteration count.

[User002]

---

@altenbach wrote:

I would use a single loop running at a common factor of the two rates, then use case structures to enable each case depending on the required multiple of the iteration count.

---

There are benefits with parallell loops with high latency/jittey/processor intensive code. Also there could prove to be some interesting maintenance issues if you decide to extend this concept.

Br,

/Roger

[Norbert_B]

While i find LV puzzles very interesting in general, i have some headache with this one:

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).

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.

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?

Depending on the above points, notifier and other things might be an invalid choice of data transfer/synchronization....

just my 5 cents,

Norbert

[altenbach]

Here's what I meant, assuming that the computer can keep up with the two tasks.

[MacNorth]

---

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 😄

---

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 🙂

[Norbert_B · Accepted solution]

---

@MacNorth wrote:

[..] 

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.
[..]

---

This is a very good point. But i wanted to make sure, that you should/must discuss the advantages as well as disadvantages of the design. Building up an application is most often a "case specific" process. So a framework/design pattern for one application does not necessarily fit for another application.

Designs are always heavily depending on the requirements and constraints. So giving designs here will result in educational services, sure, but not necessarily as reference designs for specific applications.

Advantage of single loop:

• No synchronization between multiple loops required
• Can easily implement any integer factor between the services (quotent & remainder function for a case structure

Disadvantage of single loop:

• Does not take advantage of multi core systems (at least not much)
• Can easily miss timing constraints (hardware does not 'reply' fast enough, data manipulation takes too long, ...)
• Code will cumulate within case structures, hence readability might suff

Advantage of multiple loops:

• Essentially see disadvantages of single loop (multiple loops do solve those)

Disadvantage of multiple loops:

• More complex, esp. for synchronization/stopping (not beginner friendly, requires more/better design)
• Can easily contain source issues like race conditions and dead locks

A little side note:

Even if the hardware does run different acquisition rates, it does not necessarily mean that the software has to use different rates for fetching the data. You can use the same time pattern, but fetch X times more values for the faster running task than the slower one. The "only" thing to care of are buffer sizes and bottlenecks in data transfer.

---

@MacNorth wrote:

[..]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). [..]

---

No, it is not laughable. For many applications, this approach for stopping multiple parallel running loops is OK. The constraint: Only for simple parallel running loops.

More complex loops (producer/consumer and similar) with more complex data relation ships require more stalwart approaches like queues, notifier or user events.

just my 5 cents,

Norbert

[User002]

---

Disadvantage of multiple loops:

• More complex, esp. for synchronization/stopping (not beginner friendly, requires more/better design)
• Can easily contain source issues like race conditions and dead locks

---

I add one more disadvantage:

• Multiple loops cause more context switching and might slow down overall application performance.

Br,

/Roger

[MacNorth]

Norbert,

A wonderful reply! Thanks for your pragmatic balance and cautions about over-application of specific implementations to the general reference design.

I concede your point about the local variable stop strategy -- it does work for loops that don't share data or combine to represent a system's state. <joke>I'm just hard pressed to find those conditions in the real world ;-)</joke>