Timed delayed message

[drjdpowell]

tst wrote:

as there is currently no non-polling mechanism (at least none that I can think of) which can be configured to act at regular intervals.

Just calculate the necessary wait to feed to the Notifier, based on the calculated target time minus the current time.  No polling needed.

[tst]

drjdpowell wrote:

tst wrote:

as there is currently no non-polling mechanism (at least none that I can think of) which can be configured to act at regular intervals.

Just calculate the necessary wait to feed to the Notifier, based on the calculated target time minus the current time.  No polling needed.

Which was already suggested and is one of the ways of accounting for the drift in code which I said is needed.

P.S. Now I feel like a bit of an idiot, because I just thought of the timed loop, which as far as I understand can be configured to do this and was the original question in the thread. Shows you how much I use RT. Anyway, that option has already been discarded earlier.

[AristosQueue (NI)]

mtat76 wrote:

The word that seems to be missing is data.  We talk about "messages" and "functions" above as if they are are the sole object of a LabVIEW application.  But the reality is that many of us (most?) use LabVIEW to acquire some kind of signal (i.e. data).

And there's the split. The Time Delay Message function is totally inappropriate for use in gathering regular data, even if we modified it to not drift. The function you wrote PUSHES data. The Time-Delayed Message is a PULL for data. Totally different bases for generation.

If I wanted to use this function as a PULL for data, I would do the following:

1. start the time delayed message to my actor
2. have my actor acquiring data on a regular basis (using a loop very much like the one you wrote) and have it caching data in some sort of local storage -- something like an array of data values generated.
3. Every time the pull message arrives, transfer the array out of the cache and send it to the requester.

But, actually, I would rather not use Time Delayed Message at all.

1. Have someone send the actor a "Start Sending Data" message.
2. Have the Actor start gathering data on a regular interval (using the "no drift" mechanisms that you propose) and have it send a message containing that data at regular intervals.

Does that make sense? Earlier I abused the term "deterministic" trying to get this point across. If you want regularity to the data, it matters where you are making the slips in time. You either compensate at the receive of a PULL request by having separately gathered and cached the data or you compensate at the send of a PUSH request. The latter is far simpler and more reliable.

Making this function non-drifty does not improve it for use in pull requests. I don't think we should encourage that pattern at all.

[cirrusio]

No, I don't understand.  I didn't write a function to do anything with data.  I wrote a loop that executes with regularity. 

I *was* using the timed delayed message to do something akin to telling the device to go retrieve data as would happen if you had a user interface with a button that said "GET DATA" and then pressing that button kicked off a message chain that ultimately terminated in a request to the device actor to retrieve data from the device.  As represented here, it doesn't say anything about what happens to the data once the data is retrieved (and to be honest, that is not something I am interested in answering right now). 

If you were to remove the Timed Delayed aspect, would this be an inappropriate way to tell the device to get data (i.e. pressing a button on a user interface)?  If it is, then how would you do it in this framework?  If it is not, then why would it be inappropriate to use the Timed Delayed VI?  Is this not akin to having a low-paid undergrad sit at a user interface with a stop watch and just hit the "GET DATA" button periodically like a monkey?

Thank you, tst, for pointing out that we are now putting a greater burden on the processor by not allowing the thread to sleep.  For my interests, this is not an issue, but luckily we have the answer a little higher up.

[drjdpowell]

AristosQueue wrote:

The function you wrote PUSHES data. The Time-Delayed Message is a PULL for data. Totally different bases for generation.

I was just writing an actor today that uses a "Metronome" actor today.  The benefit of an actor using the Metronome is that it eliminates the need for a separate loop, with all it's attendant complexity.  Much simpler.   Note that for me the most common use is that ActorA launches ActorB, and then ActorB launches a Metronome to send itself messages that cause it to push data back up to A.  Metronome is an internal time source used by an ActorB.

It is not usually the case for ActorA to launch a Metronome to pull data from ActorB, though I have done that, when deliberately wanting to undersample, such as when taking time-lapse movies with fixed frame/second camera hardware (i.e. when the entire point is that I don't want cached data).

I only use a custom second loop if the data collection is blocking, as I can't then have it execute in the message-handling loop. 

[cirrusio]

You all don't mind if I just stand back, do ya??

These statements

drjdpowell wrote:

The benefit of an actor using the Metronome is that it eliminates the need for a separate loop, with all it's attendant complexity.  Much simpler.  

and

drjdpowell wrote:

I only use a custom second loop if the data collection is blocking, as I can't then have it execute in the message-handling loop. 

are to the point.  In many cases, I too use seperate loops for handling intensive work that might be blocking, but in the case I envisioned, the extra framework required to communicate with that external loop and ensure common state between the two loops did not seem to justify its use.  This is why I did not use AQs suggestions above in this case.

Thank you for articulating that.

[AristosQueue (NI)]

Interesting, drjdpowell. I generally favor adding code to Actor Core over the self messaging for stuff like that... I evaluated that as the simpler to set up. Just a difference of opinion there. Besides, I long ago created one Actor class that has a method "Repeat This.vi" that establishes a secondary loop (and the stop signal stuff associated with it) that calls the Repeat This method in a separate loop. So for me, the only use case I could see for the Time-Delayed was *between* Actors, not within a single Actor.

It wouldn't break any of the contracts of the existing Time-Delayed VI to change it to avoid drift. I've been resistant to doing that needlessly. Let me mull over your use case here a bit more.