Launching an actor with shared variables in dependencies takes a lot of time

[p4keal]

May be this question is quite simple for everyone familiar with shared variables.

My problem is: in LV2014 the launch of any actor takes over 30 seconds if one of actors in project uses shared variables. This behaviour makes debug to a test of patience...

I have two actors A and B. The actor A use some SVs, they are defined in his actor library, and actor B don't use any SVs. But even when I launch only B LabVIEW deploys first the SVs from A and after this the actor B starts. If I remove all SVs or the whole A Library from the project the actor B starts without delay.

Exists another possibility to avoid SV deployment if they are not really used or to accelerate the deployment process?

[AristosQueue (NI)]

That is a question for shared variables users in the regular forums. There's nothing special about actors -- they're just VIs. You'd have the same problem with non-actor VIs using shared variables. I know nothing about shared variables and generally recommend not using them unless you absolutely have no other option because of their inherent nature as "worse than global variables" -- global variables are accessible anywhere in your application and tend to cause problems with modification, replication, etc. Shared variables are worse... universal variables, available even outside your application.

If you're using shared variables for communication from FPGA to desktop, that's reasonable -- they have some noted advantages for that particular type of communication. But if it is any other use case, personally, I would encourage you to find another communications tool.

But that's my personal recommendation, not the recommendation of National Instruments.

[p4keal]

---

But that's my personal recommendation, not the recommendation of National Instruments.

---

I fully agree with You. I have tried to use environment variables several times, but at the end have thrown them away every time. This is a pity, because they would be appropriate in my case. A single writer publishs values and some network distrubuted UIs subscribes them. Additionaly one have option to log them with DSC module or just to use Distrubuted System Manager for quick debug.

What is Your favorite method for network 1: N communication between Actors?

[AristosQueue (NI)]

For any type of network communication, actor or not, I like the Network Streams myself. I don't do very much of that sort of work, and the Network Streams hit the right balance of ease-of-use vs power for me. For 1 to N, I'd spin up N connections and have an array of them.

BUT!

If you have an Actor Framework actor on both sides of the communication, user justACS has developed a library that takes care of all the details for you:

http://forums.ni.com/t5/Actor-Framework-Documents/Network-Endpoint-Actors/ta-p/3525072

There's a presentation from NIWeek about this package on justACS' website:

allencsmith149.workfolio.com

Scroll down to the Files section, and look for "Inter-Target Communication in Actor Framework - Extended.pdf".

[p4keal]

I've experimented with LNA for quite a long time. But at least in LV2014 there was a pair of problems with reconnect when a network stream endpoint was disconnected unexpectedly, be it by crash of the application or by unpluging the network cable. Unfortunately, I'm out of office on the next two weeks, so I can not post the code examples. If I am back, I will test LNA with LV2016 and if the difficulties still exist, I post them in LNA thread.

Thank You very much!

[cbutcher]

I'm not sure if it's what you're looking for, but Piotr Kruczkowski has also recently (re)released the Event Source Actor package.

http://forums.ni.com/t5/Actor-Framework-Documents/Event-Source-Actor-Package/ta-p/3538542