a suggestion

[StevenD]

I am currently working on a program that has a lot of peer-to-peer TCP functions going on. This program handles all the TCP functions and front panel in the same main VI. The problem is that there are several sub vi's the user can use to change some settings. However if the user enters a sub vi, and a peer tries to contact the local machine, they will get a timeout error if the user doesn't finish before the timeout limit on the TCP function. There are several options to deal with this, but none of them are very practical for my situation. I could handle the TCP commands in a sub called with the Invoke Node Run VI, Wait Until Done set to false. But there is so much information that needs to be sent back and forth that I would have to use a lot of Globals or FGv's and run the risk of overwriting data before it is read. I could use notifiers or queues, but again so much information is going both ways I would have to set up at least 2 queues (1 for sending, 1 for recieving) and I would have to constantly check to see if there is something in a queue that needs to be dealt with before continuing normal execution.

Someone correct me if Im wrong please, but...

As far as I know, the only way to call a sub-vi while not caring about when it finishes AND passing values to it can only be done by using the Invoke node Set Command, or a Globals/ FGVs. I have problems with both methods though. The Invoke node method can consume quite a bit of block diagram space when passing multiple values. And the Global/FGV method runs the risk of losing data if the value is updated before the Sub reads it.

Could it be possible to have a sub-vi node setup to have an option to not wait until done? This would probably have to be done with sub's that have no outputs on their connector pane for obvious reasons, but small subs that maybe have a queue passed to it would be awesome.

[tst]

What you want sounds like a reasonable usage for OOP.

Essentially, you can create a cluster of all the data needed for the subVI and then create set methods for it. That way, you can set each of the cluster elements and when you're ready pass the entire cluster using a queue (this can also be a method).

This can be done either using LVOOP or GOOP, since each will allow you to create any number of clusters.

In GOOP, it can look something like this (from here😞

The VI on the left creates a new cluster which is then refered to by its reference. If you want another cluster, you just call the VI again. The cluster is guaranteed not to have race conditions by the framework.

You can see some more details if you follow the link.

In LVOOP, you will either need to make sure you don't split the object wire (because that creates a new cluster) or use a wrapper to get the reference behavior you see above.

Incidentally, using more than one queue for communication is a perfectly valid method and in fact you can use any number of dynamically generated queues just as you can use any number of TCP connections.

[StevenD]

Thanks for the info and links. Looking into LVOOP now. I have done a little bit with classes, but it's very hard for me to get used to. Also downloaded the GOOP installer and will look at that later.