LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

This VI reference to strictly typed reference?

Hello,

 

I'm wondering if I can create a strictly typed VI about the VI I'm currently working in.

 

I'm working on a huge codeset written by others. The UI of this codeset is heavily rely on subpanels which display VIs launched in an async manner (launched with flags 0x40 and 0x80 so "Enable simultaneous calls on reentrant VIs" and "Prepare to call and forget")


The main application may launch several instance of a reentrant VIs with an async call. For example Proc1, proc2 and Proc3. My task is make sure that if Proc1 has finished its execution and then I the code wants to launch it again then it will call the already existing instance instead of creating a new one. (meaning the "first call" node should return False). (note: as it is launched as a reentrant instance, the reference of the created instance can be collected only from the instance itself)

 

My plan was to introduce an input parameter to the reentrant VI called "Function name". This would be a simple alias for the function the user call the reentrant instance for. Within the VI I pair this "function name" with the "this Vi" reference and write it to a function global variable (FGV), so later on before I launch a new instance of the same "function name" I can check if it exists in the FGV and if so then I can grab the VI reference and reuse it.


The problem I'm facing is that the code operates with Static VI references (the one shows the connector pane) which the This VI reference returns a generic ref. These seem to be incompatible in many cases and currently I have no idea how to reuse the reference I'm getting in the reentrant VI to restart the same instance again.

 

I hope this make sense, I'm somewhat struggling in verbalizing the problem.

 

Any thoughts would be appreciated.

0 Kudos
Message 1 of 10
(2,913 Views)

Right click the static reference, and select Strictly Typed VI Reference.

 

Not sure why you'd make a FGV to recycle the references. LabVIEW will handle that pretty efficient. I wouldn't bother until it proves to be a problem.

 

 

0 Kudos
Message 2 of 10
(2,890 Views)

A VI can have a strictly typed reference to itself.  Use that instead of This VI.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 3 of 10
(2,871 Views)

The 0x40 option is badly described in the help documentation and widely misunderstood.  It creates a reference to a pool of clones behaves exactly as you are trying to achieve, without you needing to do anything.  See this conversation.

0 Kudos
Message 4 of 10
(2,855 Views)

@paul_cardinale wrote:

A VI can have a strictly typed reference to itself.  Use that instead of This VI.


Yes, I can include a static reference of the given VI to its own block diagram, but that doesn't seem to refer to the instance itself.

0 Kudos
Message 5 of 10
(2,818 Views)

So whats happening is that we'd like display a given VI lets say 5 times to the user, so it is set to reentrant. The VIs are started asynchronously.  I can easily set an alias to the instances by using a string input terminal, so following the example I can assign aliases like "setup1", "setup2" ... "setup5", where each alias is assigned to a given reentrant instance.

 

The VIs are initialized by using a "first call" node and use FGVs to store data. The user can interact with the instances and can make them disappear from the screen. But when the user wants to display "setup1" again I must display the already existing instance.

 

I hope this clarifies the problem more than the original post.

 

Let me know your thoughts.

0 Kudos
Message 6 of 10
(2,808 Views)

If "let's say 5" means 5, then why start them dynamically at all?

 

Simply put the VI 5 times on the diagram of the calling VI, and you'll have 5 clones. Each can get it's own string input, simply wired to the instance as constant. Use events (or GFV, queue's, control refs) to let the instances show\hide themselves.

 

You'll need a way to stop them, but that's also the case when you dynamically call them.

 

Dynamically calling things does complicate things (management, debugging, the concept).

0 Kudos
Message 7 of 10
(2,800 Views)

That would be way too simple. The "setup" example was really an example only, I may need to open LOTs of instances and the instances may need to be recalled at various places of the project. As I mentioned it in the original post this is already a rather HUGE project and I need a solution to the problem I have (tried) to describe and not a workaround. (Its also a  possible scenario that the reentrant VI does not display the user interface.) 

0 Kudos
Message 8 of 10
(2,797 Views)

It's not a workaround. There's no such thing as 'too simple'. If it suffices, it's the simplest solution to the problem. The only reason it won't suffice, is if the maximum number of instances is unknown at compile time. I use it all the time, and it's a lot easier then VI Server.

 

So you know how to start VIs dynamically, and you know how to pass parameters to it... What exactly is the problem?

 

Why do you need to use This VI, and then convert it to a strictly typed reference? Perhaps you should post some code?

 


@1984 wrote:

The problem I'm facing is that the code operates with Static VI references (the one shows the connector pane) which the This VI reference returns a generic ref. These seem to be incompatible in many cases and currently I have no idea how to reuse the reference I'm getting in the reentrant VI to restart the same instance again.


E.g. Show where this is incompatible, and why you need a This VI here...

0 Kudos
Message 9 of 10
(2,788 Views)

It sounds like it could be as simple (hopefully not too simple) as this:

Strict Typed Ref To This VI.PNG

But do set the appropriate 0x80\0x40 etc. input...

0 Kudos
Message 10 of 10
(2,784 Views)