How to set the timeout of a Notifier in a consumer loop if intention is to run no faster than the producer loop

[ChuckVersusTheVI]

If I have a producer loop sending a notification every X ms, what value should I wire to the consumer's Wait on Notification timeout to ensure the consumer loop runs no faster than the producer?

For example, in the snippet below, I would set timeout of the consumer loop equal to the wait of the producer loop, however, when I do this, I see a loop rate of ~0 s. 

Why does this happen?

To ensure the consumer loop runs no faster than the producer, what should I wire to the timeout with respect to the wait of the producer loop?

[crossrulz · Accepted solution]

Leave the timeout input unwired and it will default to waiting "forever".  If you really need a timeout, you just need something that is (much) larger than the producer loop rate.

[ChuckVersusTheVI]

Understood. That is congruent with what I found by increasing the timeout past the producer loop rate.

I am still confused why having the timeout value the same or very similar to the producer loop rate would cause the consumer to become a 'greedy' loop and run as fast as possible?

[crossrulz]

I think I see what is happening now.  I think you are seeing a combination of a timeout and then immediately getting the Notification, which results in a loop rate of 0ms.

[ChuckVersusTheVI]

I don't understand why the 'Wait on Notification' VI would behave that way.

Even if it timed out then immediately received a notification, it should still have to wait some amount until the next notification is received, not immediately get a new value over and over again, since the producer isn't sending new values that fast?

I modified the code to calculate the average loop rate over the current number of iterations, and I get a value that is about half of the specified timeout:

This is interesting and still would like to know exactly how the aforementioned combination creates the 0ms loop rate, but as said above, I get the desired functionality by setting the consumer timeout to higher than the producer rate. 

[aputman]

It's not that it becomes a greedy loop.  It's because your timestamp is calculating immediately when the iteration starts and not when the notification is being received.  One iteration will be really fast and the next iteration will be delayed while it waits for the message to be received.

I duplicated your code and when I run it, the consumer loop rate flashes.  I can see another larger value appear but it changes quickly.  It appears like your consumer is running really fast because you only see the 0.01ms value on the screen but it's because your timestamps are calculated wrong. 

[ChuckVersusTheVI]

True, that is the behavior I expect, and so should be getting an alternating loop rate between 0 (really fast) and something greater than 0 (while it waits for the next notification), but instead what I'm seeing is a constant loop rate of 0ms when using the timestamp (Get Date/Time in Seconds) to calculate loop rate.

[cordm]

Wire the consumer loop rate to a waveform chart to see that you receive two values in quick succession. Or use a history probe.

[ChuckVersusTheVI]

Ah good point, a waveform chart does show the expected behavior. Looks like I tricked myself by assuming the numeric indicator would catch that behavior. Thanks