Multiple reentrant clones with not reentrant FGV timer

[bienieck]

Hi,
I want to create some timer launcher. So I created simple timer based on functional global variable and I tried to launch multiple clones of it in reentrant "timer launcher". The thing is that timer is not reentrant (every FGV that i saw was not reentrant) and I don't know how to create such a launcher.

Attached picture illustrate the idea. So I'm launching clone1 (which is some reentrant VI), in that clone I have not reentrant timer but it is not reentrant from the clone 1 perspective only. In clone 2 i have another timer which is not reentrant from clone 2 perspective but reentrant from clone 1 perspective and so on. It is quite complicated to describe but i hope picture demonstrate my problem somehow.

Please help

[drjdpowell · Accepted solution]

You can do this if you make your timer preallocate-clones-reentrant, and then call it by reference (one reference in each clone of the timer launcher so that each launcher is using a separate timer clone).

[bienieck]

Thanks drjdpowell, it works. I've attached my solution.

[drjdpowell]

You don't necessarily need the Open VI ref stuff.  You can just have two static references (which will preallocate two clones) and wire them directly in to the Call by Ref nodes.

[bienieck]

Ok, but I will open different number of clones in practice, so static refs is not the best idea, in my understanding.

[Sam_Sharp]

Another method I have used in the past is to store the timer information in a named queue (e.g. name your timers). This is a much simpler method for calling/creating timers - you call the same VI each time (or you can make it reentrant to speed execution but you get the data for the timer from a queue (Single Element Queue, SEQ). It's a common method for having multiple instances of an FGV. You could also store the data in a DVR and pass the DVR references around.

What you've got there will work but it seemed a bit overkill to me unless it was an exercise in asynchronous calling etc.

[crossrulz]

---

@Sam_Sharp wrote:

Another method I have used in the past is to store the timer information in a named queue (e.g. name your timers). This is a much simpler method for calling/creating timers - you call the same VI each time (or you can make it reentrant to speed execution but you get the data for the timer from a queue (Single Element Queue, SEQ). It's a common method for having multiple instances of an FGV. You could also store the data in a DVR and pass the DVR references around.

---

If you are using the SEQ, please change over to the DVR.  This was the exact case the DVR was meant to replace.

And instead of named queues, use a Variant and use the Variant Attributes to store your times.  The lookup is really fast and uses names.  Very useful function.

Personally, I would probably store a DVR of type variant in a global variable.  The In Place Element Structure will take care of all of the race conditions.

[Sam_Sharp]

Yes, I do almost exclusively use DVRs and variant attributes for this sort of problem but I was trying to think of a method that meant you didn't have to pass the references around and a named queue was what immediately sprung to mind but now that I think about it there's zero benefit in doing so.

[bienieck]

Can I ask for some snippet or other visual description of that solution? Or, if it is some standard approach, for some link with more info?

[Sam_Sharp]

Sure....

(error handling required)