Unexpected numbers of VI instances deploy

[jtay]

Below are some snippets from the deployment messages that I get when I deploy my application to my PC RT. My application is too large to post (and is proprietary), but I'm wondering if someone can tell me what might cause these sorts of messages. I'm not sure if this is causing problems, but it is concerning:

Deploying Transfer Read and Write Arrays.vi:Instance:Instance           1 38Saved   Transfer Read and Write Arrays .vi

I am thoroughly confused by this message, and it is always the same. Is there an instance of an instance? 38 what?  What was saved? Someone is going to have to break this one down for me.

Deploying PID Channels - Main RT.vi:Instance:1
Deploying PID Channels - Main RT.vi:Instance:0
Waiting for the target (RT-ShopCell-1) to respond
Deploying PID Channels - Main RT.vi (274.12 K)
Deploying INCA Read Write.vi:Instance:0
Deploying INCA Read Write.vi:Instance:1
Deploying INCA Read Write.vi (128.94 K)
Deploying Formula Channels - Main RT.vi:Instance:0
Deploying Formula Channels - Main RT.vi (50.10 K)
Deploying Trigger Channels - Main RT.vi:Instance:0
Deploying Trigger Channels - Main RT.vi (76.79 K)
Deploying Differential Channels - Main RT.vi:Instance:2
Deploying Differential Channels - Main RT.vi:Instance:1
Deploying Differential Channels - Main RT.vi:Instance:0
Deploying Differential Channels - Main RT.vi:Instance:3
Deploying Differential Channels - Main RT.vi (40.43 K)
Deploying Waveform Channels - Main RT.vi:Instance:2
Deploying Waveform Channels - Main RT.vi:Instance:0
Deploying Waveform Channels - Main RT.vi:Instance:1
Deploying Waveform Channels - Main RT.vi (54.66 K)
Deploying Create System Hardware Values with Timed Loop.vi:Instance:1
Deploying Create System Hardware Values with Timed Loop.vi:Instance:0
Deploying Create System Hardware Values with Timed Loop.vi:Instance:2
Waiting for the target (RT-ShopCell-1) to respond
Deploying Create System Hardware Values with Timed Loop.vi (289.90 K)
Deploying Filter Channels - Main RT (Bessel).vi:Instance:0
Deploying Filter Channels - Main RT (Bessel).vi (43.07 K)
Deploying Playback RT.vi:Instance:0
Deploying Playback RT.vi (3263.53 K)
Deploying Profile - Main RT.vi:Instance:0
Deploying Profile - Main RT.vi (142.05 K)
Deploying Run Test Series RT.vi (88.52 K)
Deploying Integration Channels - Main RT.vi:Instance:1
Deploying Integration Channels - Main RT.vi:Instance:3
Deploying Integration Channels - Main RT.vi:Instance:2
Deploying Integration Channels - Main RT.vi:Instance:7
Deploying Integration Channels - Main RT.vi:Instance:0
Deploying Integration Channels - Main RT.vi (34.25 K)

 First of all, I don't think there is a reason for any of these VIs to be deploying multiple instances of themselves. They aren't re-entrant. What other reasons could cause multiple instances of a VI to deploy? Also, what could cause something to deploy instances 1, 3, 2, 7, and 0, but not the instances in between?

[Norbert_B]

I haven't seen this yet and i am not the RT guy, but i guess the following:

In order to improve execution speed and to prevent locks of parallel running threads, VIs can be set reentrant. The latter point is important for deterministic threads, so it makes sense on RT to set as many VIs to reentrant as possible (and reasonable. Setting each VI to reentrant is NOT reasonable!).

The preferred option for reentrancy on RT is "Preallocate clone", which will result in the fact that each call to this VI gets its own clone. I assume that in your case "instance" is a synonym to "clone".

When building an application (startup.exe), it also makes sense to put each instance into the exe file as separate file in order to prevent locking between the calls and reducing call overhead. Therefore, each call is redone to call its specific instance.

As said, all above is my assumption; but it explains why you see different instances of the same VI.

Norbert

PS: You can check if i am correct by counting the different calls and comparing to the number of instances. This is only valid for "preallocate" i assume.

[Jordan-G]

Hi jtay,

Does your RT application call any express VIs, such as Time Delay Express VI or others? It is expected behavior for every instance of an express VI to be deployed to the target. To see if an express VI is causing multiple instances of a VI to be deployed to the RT PC, I would recommend either diagram disabling the section of code with an express VI or replacing the express VIs with primitives.

Do you see any unexpected behavior when multiple instances of VIs are called? 

Regards,

Jordan G.

[jtay]

Yes, it appears that there were RT Timing express VIs that were causing the mulitple instances. That unusual message that I mentioned in the original post was caused by a VI containing three parallel loops, one of which had an RT timing express VI while the other two had regular timing VIs. I'm not sure if any problems are caused by this.

[Jordan-G]

Hi jtay,

Any express VIs that are used within RT applications will cause the deployment window to list multiple instances of the VI in which the express VI is used. Since the deployment window output is misleading, a Corrective Action Request has been filed to resolve this behavior in future versions of LabVIEW.

It should be noted that the listing of multiple instances of a VI due to the presense of express VIs should not have any effect on deployment or code execution.

Regards,

Jordan G.

[SKauth]

Hi,

just wondering: Is that CAR still open? Seems it wasn't fixed up to LV 2017. Just wondered about multiple instances with express VIs as I am currently debugging some strange behaviour with my cRIO application. But it seems that this is not the issue...

Simo