Thursday, September 18, 2008

Retriggerable First Call

Over the years, I've grown to like the First Call? primitive on the Synchronization palette. It's a simple, useful tool if you want to run a subVI, or a section of a block diagram in a case structure, only once when the VI first starts up. I find it particularly useful for initializing the behavior of modules that I've implemented as functional globals. Recently, though, I found that several of the modules and applications I've been working on needed the ability to do what I call a "soft restart." That is, they need to be able to be returned almost completely to their start-up conditions, without completely stopping and restarting the applications. This is particularly true for my RT applications, which, lacking a GUI, can't easily and directly be stopped and restarted. Herein lies the quandary: First Call? returns true only once, but to perform a soft restart we need the ability to effectively reset it so it that returns true again, on demand. The solution: Bob's handy-dandy Retriggerable First Call routines.

First Call Retriggerable.vi













Used in a manner similar to the First Call primitive, this reentrant VI will return a TRUE the first time that it is called. It also will obtain a reference to a named Notifier (and keep said reference on an uninitialized shift register) which is used to accept the retriggering notification. There is an accessory VI, called Retrigger First Call Nodes, which when called will cause all instances of this VI to again return TRUE the first time they are called after the Retrigger VI is invoked. In this manner, we can use this VI for initialization functions, while retaining the ability to restart processes if necessary.

Retrigger First Call Nodes.vi


















Pretty straight-forward: obtain the Notifier reference on first call, keep it on a shift register, and send notification every time the VI is called. Unless, of course, an error is passed in, in which case do nothing.

For completeness and cleanliness, I suppose there should also be a third component to this utility: a clean-up routine to destroy the notifier reference. Also, looking again a little more critically at the Retrigger First Call Nodes.vi, we could make the diagram a tad simpler. What we really want is to get rid of the error-handling case structure, and instead wire the error in and out cluster through the Send Notification. As my professors in college used to say, "I will leave this as an exercise for the interested reader."

7 comments:

Anonymous said...

Nice little piece of code Bob!
Wouldn't that make a good OpenG candidate?

Anonymous said...

That's pretty slick. Thanks Bob!

Anonymous said...

That first call has nailed me in the past. I'm happy to welcome the retriggerable first call into my life.

Unknown said...

Shouldn't a unnamed notifier be used? Now every Retr. First Call? is reset at the same time.
And the VI should be reentrant so every instance has it's own reset point.
Now than a cleanup routine is very handy, we could do something in the end by looking up every clone, but then we are doing exactly th same as LabVIEW clean-up code.

Ton

Jonathon Green said...

Thanks Bob. I just implemented the retriggerable VI's in my latest app and love it.

I did make a small change where the string used to name the notifier is an input to both VIs. That way I can retrigger exactly the modules I need to based on name and still have the VIs as reentrant.

I think this set would be good OpenG VIs too.

Anonymous said...

Hi Bob, could you give me some example for how to use this retrigger first call ? I have been developing one myself but got stuck, luckily I found your solution here, but I have no idea how to use that 'notifier' at all. When I just 'create control' for the left shift register, the notifier reminds me 'invalid parameter input'.

Let me know if you could do me a favor, I would check your blog as often as I can.

Thanks!

emigre459 said...

Hi Bob, I know this entry hasn't received a comment in a while, but I just wanted to thank you for posting this. It's saved me a large headache in figuring out the concepts of notifiers and retriggering for my own project! Thank you!