VI Server 'RUN VI' method execution time seems excessive

[exch&mart]

I am using VI server to run multiple instances of a common VI that logs data into a remote device. The top level VI operates as follows, I open a reference to the VIT, modify the controls and then run the VIT. All VI references are closed on completion of the top level VI. 

However when I time the execution duration for the Invoke node "Run VI method" it takes 1.2 seconds for one instance of the VIT and 3.5 seconds for two instances of the VIT. So for a 2 seconds log it takes longer to execute the invoke node property than it takes to log the data.

[LuI]

exch&mart,

maybe your VIT needs some ressources, say a port or queue or cable? This can even happen indirectly, so you might not recognize it.

I use this technique with instantiated executions to run up to 8 instances of a VIT and have not seen such a behaviour..
You might as well use the invoke node and have it not waiting for the executed process to finish.

HTH   and    Greetings from Germany!<br>-- <br>Uwe

[shoneill]

If you're actually changing the controls as you describe, then the VIT maybe needs to recompile at run-time, thus leading to a possible delay.

If, however, you are only changing the values of the controls, then I don't get it.

Are you sure it's the "run VI" part which takes so long, or is it the setting of the controls via VI server?

Hope this helps

Shane

[exch&amp;mart]

I only modify the values for the controls. I failed to mention that it takes approx 12 seconds to load the VIT into memory and update the control values. Then the Invoke node 'Run VI' executes.

I time the VI via the error cluster, using the tick counter placed in a sequence.

[shoneill]

It's taking 12 seconds to load the VIT?

Do you have an array with lots of old data floating around somewhere in the VIT?  12 seconds sounds like an awful lot of time.

If you've got a lot of dead space being used by a "lost" array which isn't empty (You can see if the VIT file itself is large), this might be causing your problems.

Similarly, if the VIT takes so long to load because of data, then memory allocation when running may be delaying the execution.

Check out your VIT to make sure it's not bloated with uneccessary data.

Otherwise, try posting pictures of your code so that we can debug a bit more efficiently.

Hope this helps

Shane.

[exch&amp;mart]

All my sub VI's are re - enterant and this seems to cause the long loading time. However, removing the re-entrancy means the parallelism is lost. I've found by making certain sub VI's re-enterant the code appears to operate in parallel but not for all the actions I'm trying to execute, in particular transfering data over the serial comms ports.

If i make all the subVI's VIT's will this improve the parallelism of the code or do I have to use the re-entrant function??

[LuI]

Reentrancy is a very powerfull but also dangerous tool. My impression is to avoid this whenever possibel, cause it  can give very unexpected behaviour. I'd use instanciated VITs instead.

Transferring data via serial ports and VISA is probably be operated in parallel per se. The VISA_write or -_read part is very short, compared with the actual transfer, which is usually be done asynchrounously using system ressources. AND those exist in parallel.

Once I had a quite large project that involved serial transfer vis 230kbaud with 13 µCs in parallel. Was afraid of paralelism etc, but finally I could just use a for-loop that called those VISA  functions  for all the ports one after the other.. Due to calling overhead I did not achieve the full data transfer rate of about 23 kB/s, but reached about 17..18.

To answer your last Q: VITs need to be instantiated to execute.  This is done by opening a ref to the vit and using VI server to set controls and to execute this instance. If you just have your Main.vi as a VIT, this means all the called  VIs are called from all those instances and do NOTexecute in parallel.  But cause those subVIS are already in memory after the first instance has been loaded, the following instanciations are much faster.

BTW,  I do not know if it is possibel to make VISA functuion reentrant. AND I'd suspect this would not improve anything, but cause problems.

Just my € 0.02!
Greetings from Germany!<br>-- <br>Uwe