02-14-2013 01:26 PM
My event idea is unnecessary complex, just add a AE to the reentrant vi that adds when started and removes when quitting, then you can check from anywhere without hassle.
/Y
02-14-2013 01:32 PM
If they are running in paralle, you can have a race condition when they terminate. You will need an action engine of some sort to do it correctly.
02-14-2013 11:08 PM - edited 02-14-2013 11:10 PM
Hi tst,
I know that VI will parallely but what i mean to say is that they will be created serially.
CREATION IS ONE AFTER OTHER & RUNNING IS PARALLELY.
One more thing, in my all the VIs database is must & already told you that had a worst experience with FGV. So from my point of view DB is not a bad option.
02-14-2013 11:09 PM
Hi Yamaeda,
What do you mean by "Start and Quit-event". How you are implementing this
02-15-2013 12:18 AM - edited 02-15-2013 12:23 AM
@Ranjeet_Singh wrote:
Hi @Yamaeda,
What do you mean by "Start and Quit-event". How you are implementing this
My guess would be by user events in the clones.
Now back to the topic at hand- How many clones of a vi are running in an app instance? DETT should provide the trace if you need it.
My previous post should find the number dynamically (untested)
The BIG question is why you would want to know? You told LabVIEW to launch as many clones as are needed by preallocating clones. As many as are needed are running,- No more, No less. The exact number is trivia that LabVIEW can manage very well, as you requested, thank you.
You may very well have a use case I haven't thought of but, perhaps if we knew why, we could solve the need with other mechanisms (assuming is clone? does not work for your needs)
02-15-2013 12:31 AM
I dont want to know but mlwarren wants to know. But according to me this is perfect question becasue may be this is required in their project and by helping them this can be good experiece for us also. We dont know what environment you, me or mlwarren is working so we can never know what is good or bad for them.
Sometimes we not told labview how many clones needs to be created instead this will be created dynamically as per the requirement.
02-15-2013 12:39 AM
@Ranjeet_Singh wrote:
I dont want to know but @mlwarren wants to know. But according to me this is perfect question becasue may be this is required in their project and by helping them this can be good experiece for us also. We dont know what environment you, me or @mlwarren is working so we can never know what is good or bad for them.
Sometimes we not told labview how many clones needs to be created instead this will be created dynamically as per the requirement.
Ranjeet
I understand. The source and reasoning of the requirement may suggest a solution. Thats why I asked the leading question,"Why do you want to know after asking LabVIEW to manage it for you?" Don't get defensive. You contributions are appreciated.
02-15-2013 01:16 AM
Friend sorry i though in other way and by the way it was kind of defensive only
02-15-2013 02:23 AM
@JÞB wrote:
My previous post should find the number dynamically (untested)
I didn't test either, but I'm pretty sure that clones (or at least dynamic clones) are not returned by the All VIs property.
02-15-2013 02:31 AM
@Ranjeet_Singh wrote:
I know that VI will parallely but what i mean to say is that they will be created serially.
CREATION IS ONE AFTER OTHER & RUNNING IS PARALLELY.
Logging them at creation time will only work if you do it before you run the VI and it won't help when the VI stops and you have to remove the VI from the list. If you find it more convenient to work with DBs, then go ahead and do that (although I think it's a bad idea for something like this). Just be aware that updating a DB by reading-processing-writing will create a race condition unless you can absolutely guarantee that there is only one client doing it at any one time. That's one of the reasons people use transactions or stored procedures.
As for FGVs, you don't have to use them (although it tends to be helpful to be well versed in commonly used techniques). There are other ways that this could be solved without using a DB.