Unexpected delay when dynamically called VI closes

[JB]

LV10.0 / WXP

A VI is called dynamically by Run VI Method (Wait Until Done = FALSE, Auto Dispose Ref = TRUE).

Queues are used to exchange data with the main VI.

When this VI closes ("stop" message from the main VI), LabVIEW hangs for about 25 seconds (!) with one of the CPUs of the dual core machine at 100%.

Has anyone else encountered this strange behaviour ? Any ideas ?

Many thanks in advance

[Norbert_B]

Since LV has to unload the VI and it's hierarchy, there should be some delay. But 25s seems way too long.

Could you break this down to a small example? Is it connected to certain functions (Queue, DLLs, VIs)?

Did you observe memory usage of the LabVIEW.exe-process during that time? Does it change a lot?

hope this helps,

Norbert

[JackDunaway]

25 seconds seems like a familiar figure... are you waiting for a timeout on some networking operation (e.g., does the VI or a dependency use FTP, UDP or TCP)?

[JB]

Hi Norbert,

Some more details and answers to your questions :

• The VI is quite a "big fish" with about 450 sub-VIs (more than 750 with vi.lib).
• It uses queues and calls a third party DLL (maxon EPOS2 driver). It also uses DAQmx and LIN hardware from NI.
• It is reentrant and many of its sub-VIs too.
• Normally, four instances of this VI are called. In this case, LV "freezes" for about 70 seconds when they close.
• The memory usage changes from about 687 to 676 MB when the four instances are closed. The number of handles decreases from about 272k to 61k.
• In opposite, LV needs "only" about 15 seconds to call the four instances and do some other tasks.
• Trying to locate the source of this very annoying delay, I used the Desktop Execution Trace Toolkit.

Many thanks in advance

[JB]

---

JackDunaway a écrit :

25 seconds seems like a familiar figure... are you waiting for a timeout on some networking operation (e.g., does the VI or a dependency use FTP, UDP or TCP)?

---

Hi Jack,

No. The application also communicates with a PLC through TCP/IP Modbus (NI Modbus library). But this task is handled by another dynamically called VI that is only closed when quiting the application. In additon to the annoying delay, the main problem is that during this time this VI stops his execution... causing the PLC to generate a timeout because the watchdog is no longer updated.

Many thanks for your help

[Norbert_B]

Can you give us a small picture of the way you are calling and releasing the subVIs?

If loading the VI takes only a short time but unloading takes long, it seems to me that those subVIs allocate many new handles/memory spaces during runtime. Is that the case?

---

@JB wrote:
[...] In additon to the annoying delay, the main problem is that during this time this VI stops his execution... causing the PLC to generate a timeout because the watchdog is no longer updated.

Many thanks for your help

---

This sounds like the whole application freezes for the time being. Is it a single loop architecture?

In addition: You call those subVIs dynamical with reentrant execution (at least some of them). So they should run in parallel. Did you configure different preferred execution systems for your different subVIs?

Did you check for reference leaks using the Execution Trace Toolkit?

Norbert

[Ben]

Hi Norbert,

THe Execution trace toolkit may help but I'll add a little bit that may be related.

I believe i read Stephen saying the LVOOP dynamic classes are not tossed once loaded. I have assumed this was performance reasons since cleaning up resources can take some time. The OS deallocating memory is also suspect since once the OS goes kernal everything stops.

another thought:

Anxious dealloation... you aren't using that are you?

Ben

[JB]

---

Norbert B a écrit :

Can you give us a small picture of the way you are calling and releasing the subVIs?

As mentionned in my first message : Run VI Method (Wait Until Done = FALSE, Auto Dispose Ref = TRUE) is used to call the VIs.

Release : after reception of a "close" message (queue), the dynamic VIs terminate their execution

If called with Auto Dispose Ref = FALSE, the freeze appears when Close Reference is executed in the calling VI (after reception of a "I'm closing" message from the dynamic called VI).

If loading the VI takes only a short time but unloading takes long, it seems to me that those subVIs allocate many new handles/memory spaces during runtime. Is that the case?

As mentionned in a previous message : The memory usage changes from about 687 to 676 MB when the four instances are closed. The number of handles decreases from about 272k to 61k.

This sounds like the whole application freezes for the time being. Is it a single loop architecture?

No. It is a rather big application with several VIs running independently and exchanging data through queues.

In addition: You call those subVIs dynamical with reentrant execution (at least some of them). So they should run in parallel.

Yes, they run in parallel.

Did you configure different preferred execution systems for your different subVIs?

Yes, I have tried several combinations and also changed the Priority. I also tried to replace the While Loop of the VI which communicates with the PLC by a Timed Loop in order to specify the processor. Unfortunately all my trials ended without any succes.

Did you check for reference leaks using the Execution Trace Toolkit?

Yes. There are none.

Norbert

---

Thank you very much for your help

[JB]

---

Ben a écrit :

another thought:

Anxious dealloation... you aren't using that are you?

Ben

---

No, I have never used it so far. Thank you for your thought.

[Norbert_B]

When asking about the memory and handles, i was up to the point: do you explicitly open them or do they open implicitly e.g. by using the DLL?

Do you unload components (e.g. DLL) on purpose before unloading the subVI?

Can you pinpoint the issue to a certain subvi used in your dynamical loaded vi?

thanks,

Norbert