Application load/launch time issue

[AristosQueue (NI)]

Although I do appreciate you doing as much work as you wish to do to pare your application down, I don't want you to forego submitting the bug just because you cannot isolate it in a smaller example. If it is our bug, it shouldn't be your job to create a minimal configuration to reproduce. Put that burden on us. If your VI hierarchy is distributable and shows the bug at 3000+ VIs, then send us 3000+ VIs and tell us to do the leg work to pare it down.

[Fire]

Hello
I think I've got it. A SharedVariable.lvlib seems to cause the problem!

Following sequence was performed to isolate the cause of the problem.
0. Check starting times of the "CS++.lvproj:Launch CS++StartActor.vi": ~60s
1. Make a copy of the "CS++.lvproj" to "SRQ1403066.lvproj" (SRQ: ServiceReQuest)
2. Remove all items from the copied project, "SRQ1403066.lvproj", except the "Monitored Actor" and the CS++ base classes derived from the "Monitored Actor" and clean the included Content.vi's.
3. Close and reopen the project; check the dependencies: no unexpected dependencies werer found.
4. Start the "SRQ1403066.lvproj:Launch CS++StartActor.vi"
4.1. The Run-Button changes instantanous to run-mode. It takes about 1s to display the frontpanel of "CS++StartActor". Stop the app.
4.2. When starting the second time the frontpanel of "CS++StartActor" is displayed almost instantanous.
5. Add more actor class library packages successivly for device base classes, IVI class implemetations and actors for NI Hypertrend as well as Alarm and Event Display.
5.1. With each package added the LV project was closed, reopened and checked for unexpected dependencies.
5.2. With each added package it took more time until the frontpanel of "CS++StartActor" became visible. The second time it did not took longer than 1s.
5.3. Following the starting times for the first start:
5.3.1. CS++DeviceBase-Content: ~7s
5.3.1. CS++IVI-Content: ~9s
5.3.1. CS++Example-Content: ~10s
5.3.1. CS++DSC-Content: ~10s
5.3.1. STF-Content: ~12s (some more project specific actors and libraries)

This sounds all reasonable. LV IDE has to perform a lot of things, compiling etc., for the first time and time depends on number of classes and VIs.

This results I would have expected also for the "CS++.lvproj:Launch CS++StartActor.vi". What is the difference?

The difference is: The "CS++.lvproj" contains a shared variable library: "CS++Core-ExampleSV.lvlib", the "SRQ1403066.lvproj" not!
Device base classes are opening connections to the SVs programmatically, to publish the device state.
There is no statically linked SV in the class VIs. Actor objects using such SV are not instanciated during the time measurements above.
When instantiating a device object, e.g. IVI-DMM with the nisDmm simulation driver, the actor can successfully connect to SV in the deployed "CS++Core-ExampleSV" process.

When I added the "CS++Core-ExampleSV.lvlib" to the "SRQ1403066.lvproj" the start delay problem reappeared!

Maybe the LV-IDE compares the SV.lvlib in the project with the contents of the deployed process and this causes the delay? The "CS++Core-ExampleSV.lvlib" is NOT set to autodeploy.

Maybe other users concerned with this problem can check whether SV.lvlibs are used and may cause the problem?

Summary: From my point of view we are not facing an Actor Framework problem, but something else concerned with Shared Variable Deployment/Checking.

Best regards Holger

[AristosQueue (NI)]

Fire wrote:

Summary: From my point of view we are not facing an Actor Framework problem, but something else concerned with Shared Variable Deployment/Checking.

Ah. Thank you. I don't know if that's the same for the others on this thread, but I'm pleased that turns out to be your issue. Not because I want you to have that issue, but because it means my faith in my knowledge of LabVIEW is restored. Shared variables have to do a lot of things outside of LabVIEW and are subject to network traffic and a host of other issues. It doesn't surprise me that they have significant deployment overhead. Ok, I guess 60 seconds is excessive, but that just suggests that something is pinging a network address that isn't working and waiting for a timeout. 60 seconds is a pretty precise time... it could easily be a hardcoded timeout value.

[Ben_Phillips]

WOW.

I like your style, Fire.

Removing a shared var LVLIB from my project completely erased the slow start when running from LV IDE.  That was only there for reference, it's not even called in the code, verified with 'find callers' on that library.  Never would have guessed that was it, thanks!

[wirebirdlabs]

Ben_Phillips wrote:

WOW.... I like your style, Fire.

I know, right?! Capturing this on the forum helps everyone.

[AristosQueue (NI)]

Ben_Phillips wrote:

Never would have guessed that was it, thanks!

I *always* guess that the bug is shared variables if I hear they are in a hierarchy. I hate those buggers. What's worse than a global variable available to every module in your program? A universal variable available to every module in EVERY program everywhere on the network!

It's just a bias of mine. Pay no attention to the ranting of the LabVIEW idealist.

[testingHotAir]

Ah ah!  I'm using SV libraries the same way you are, Fire.  Actually I built the whole application around the idea of using shared variables for communicating across abstractions.  Maybe I need to look for a better way...

Thank you all!

[Jed394]

testingHotAir wrote:

Ah ah!  I'm using SV libraries the same way you are, Fire.  Actually I built the whole application around the idea of using shared variables for communicating across abstractions.  Maybe I need to look for a better way...

Thank you all!

Same here

[MattP]

I'm curious to know how you're combining shared variables and actor framework in your applications.  Yes, there are better ways, but more system knowledge is necessary to say which way is most appropriate for what you're trying to accomplish.

[Jed394]

MattP wrote:

I'm curious to know how you're combining shared variables and actor framework in your applications.  Yes, there are better ways, but more system knowledge is necessary to say which way is most appropriate for what you're trying to accomplish.

I personally use the shared variable engine to programatically access I/O channels on a CRIO and expansion chassis.  This isn't used for actor to actor communication. 

In my current setup, each piece of hardware is its own actor and has access to a range of I/O channels on the RIO depending on its functions.  This is the lowest level of my actor hierarchy and messages are passed up and down the hierarchy using traditional methods but shared variables are not used for this communication.  I'm currently using 2 crios and 2 expansions chassis.  I'm not aware of a way to access I/O on the expansion chassis without using the shared variable engine or the FPGA.