Application load/launch time issue

[MattP]

Good to hear you're not circumventing the actor tree for messaging via shared variables - that would make me sad.

Wrt the expansion chassis, I assume we're talking about the Ethernet expansion chassis (9146/9148), in which case you're correct - going through the shared variable engine is the only way to go there.  The MXI expansion chassis permit usage of DMA FIFOs and other comm methods to the chassis - much better performance possible.

If you're not adding in an extra layer (such as a variable library hosted on the local system whose values are bound to those of the HW items on the expansion chassis), you shouldn't need a library that can be removed from the project.  I'll usually open dynamic connections to the IO variables on the expansion chassis based on a config file on the local system (sounds similar to what Fire is doing) and avoid having explicit dependencies on any IO variables in my project.

[AristosQueue (NI)]

Matt: Any idea where the 60 second delay is coming from? Is that a default timeout set somewhere that could be shortened? Or a bad network path that needs correcting?

[MattP]

Sounds like it's trying to communicate with a remote system to determine whether or not it needs to deploy variables to it.  60 seconds smells like a network timeout to me as well, but I don't know at which layer in the system it's coming from.  I've seen similar behaviors if I used static shared variable nodes linked to a remote system that no longer existed on my network, also seen it if the variable definition in the lvlib file has it aliased to a remote data item on a system that is unavailable, also seen it in some other more arcane scenarios.

If there's a reproducing case out there that I can run, I should be able to narrow it down more.  Can somebody send one my way?

[Dustin_D]

Matt,

To help identify what layer the problem is at you can perform some network voodoo and either aquit or convict the timeout theory:

Run the command:

netstat -o | find "[LV's PID]" | more

That will filter the results to only LV connections and if the SYN_SENT generally indicates your host has tried to initiate a connection it's waiting on.  the 123.33.63.3:400 is an imaginary addresss I attempted to open a connection to in LV.  6048 is LV's PID on my system.

I hope this helps!

[testingHotAir]

I use shared variables to provide live values with high refresh rates from the actors responsible for hardware to the rest of my system.  All of my hardware actors launch a shared variable library and check the variable url's into a lookup table in my controller.  When anything launches in the system that needs access to streaming data - like a user interface or logger - it requests a list of all the variable url's that have been checked in and pulls data from the ones it needs to do its task. 

My main goal here is flexibility.  For instance, my users often have to watch live data in a strip chart streaming from one or more input devices, which can't be identified prior to run time.  I provide a list of available variables next to the strip chart and poll whatever the user highlights to populate the chart.

I don't use the SVs to change the state of any actor; that's done through messages.

[Fire]

Shared Variabels are not used for Actor communication in my project(s), but for loose coupling of heterogenious systems.

In fact my SharedVariable-Connection-Class is derived from an abstract ProcessVariable-Connection-Class. So, other communication protocolls can easily be integrated.  (Actor-)Objects can publish their actual status to SVs in order to provide information to 3rd party or to subscribt to such data. 

• The main reason ist to monitor for alarm conditions and data logging to the historical database using the LV-DSC-Module.
• Make (Actor-)Object state available to other AF-apllication instances by using the Observer-Pattern, e.g. GUIs display the state of an device actor. An Observer-Actor registers for each PV an Actor-Message to an ProcesVariable-Monitor-Actor, which checks for PV changes either by polling PV/SV or event-driven using the event-Structure with DSC. By this means an Observer-Actor can subscribe to e.g. set-values provided by 3rd-party OPC-Server or other simple LV-VIs.
• 3rd-party could be OPC-clients or other simple LV-VIs of other groups not concerned with my software developments.

Regards Holger

[AristosQueue (NI)]

It sounds like a more-than-reasonable reason for using *some* "outside of system data transfer". Apparently shared variables are not a good choice.

[Jed394]

AristosQueue wrote:

It sounds like a more-than-reasonable reason for using *some* "outside of system data transfer". Apparently shared variables are not a good choice.

According to all the literature NI puts out Shared Variables are a good choice.   They've been around forever, you wouldn't think this would be an issue at this point still.  Same with IDE slowdown with large VI counts but that's another issue. 

Is this something that can be escalated with a CAR? 

[LuI]

I don't think this should be made into a CAR. Network transactions _can_ fail, at any time. For that reason there are timeouts etc.

What might help is to put at least the first connection (if not all transfers) into an asynchroneous extra thread, that wraps the shared variable and does not stop the whole application when the server with the shared variable is not reached. But than this becomes even more complicated than other methods of "outside of system data transfer". NI could consider adding this idea (optionally) into their implementation of shared variables, though.

Greetings from Germany!

--

LuI

[Fire]

AristosQueue schrieb:

It sounds like a more-than-reasonable reason for using *some* "outside of system data transfer". Apparently shared variables are not a good choice.

That's the reason why the SharedVariableConnection class is a derived class of the ProcessVariableConnection class.

One of the next planned steps is to create a DIMConnection class. I published a first trial using DIM with the NI Actor framework on https://github.com/HB-GSI/DIMActor