viSci

I am trying to optimize my cRIO -> PC remote call performance.

Does anyone know what is going on under the hood when a remote call is executed.

Here are some things I am wondering about:

1. How is connector data bundled up and converted to a TCP/IP payload

2. What is the structure of the VI Server Protocol

3. What is the threading model of the VI Server

4. What would a transaction timeline look like

TIA

I am trying to optimize my cRIO -> PC remote call performance.

Does anyone know what is going on under the hood when a remote call is executed.

Here are some things I am wondering about:

1. How is connector data bundled up and converted to a TCP/IP payload

2. What is the structure of the VI Server Protocol

3. What is the threading model of the VI Server

4. What would a transaction timeline look like

TIA

You should be able to change the scaling of your NSV's deployed on your RT target using the SV property nodes. You will also have the option to keep the change in memory or commit it to the SVE on your target.

Just noticed that all of my post history beyond last month is gone. Is there a way to recover this information?

Here is an example of the code I wrote to do alpha blending

From my cRIO I need to call a vi on a networked PC. I currently have to open a reference to this vi (which is kept in memory for this purpose)

then make the call and then close the reference. I was thinking of caching the references but this could be dangerous if the PC restarts in which case I suppose

the original references would be invalid. Just wondering if anyone could think of a more clever way to do this to avoid the time penalty of opening the reference.

Thanks

I recall that we used to just place such a vi in a the non-executing state of a True/False case structure, but LV seems bent on optimizing

out this 'non-running' code. I had to be creative to fool it. Just curious what others have found.

As many know, LV will autoupdate a typedef'd combo box control but not a diagram constant.

There is a very interesting and useful class of applications that would greatly benefit

from the use of typedef'd combo box constants that autoupdate. Consider the use of Current Valve Tables

in distributed systems. The CVT's are actually a form of keyed memory that is used to

store data values that can be dynamically created, updated and read. NI's System Group has a

version of the CVT that uses block diagram strings as variable names. This approach is cumbersome

in that if a name is changed you have to find all instances on the diagram and change

them manually. Also you have to cut and paste them in the first place. Another possibility is typedef'd enum's which will autoupdate

on the diagram, but unfortunately the enum datatype cannot be passed into subvi's without converting to a variant or string. It is also rather inefficient if your CVT is large

and you have 100's of variable names that would have to be passed around inside of the enum constant attributes.

An alternative and elegant solution is the use of typedef'd combobox constants that will autoupdate. I would like to argue that the change in behavior is really only a

development environment change, not really a fundamental change to the underlying wire type characteristics as it has been argued by NI.

The constant itself already has an attribute that links it to the typedef, so why inhibit the autoupdating?

Any Comments?

The problem with Get Strings from Enum__ogtk.vi is that it is way too slow to be used in a CVT implementation on an embedded target.

I agree that a smaller version of the format into string would be nice and could be called enum->string.

One thing I noticed when first trying to debug my remote VI Server calls is that each target within a project has individual VI Server configurations. Furthermore, you can have

multiple VI SERVERS at a single IP address only differentiated by the 'Service Name'. I also found out that you can remotely call reentrant vi's but it turns out I did not need that feature.

Here is an example of the NSVQ.

Greetings all,

I have created my own version of the network queue using Buffered Network Shared Variables. It seems to work quite well. NSV's can have any data type, I have a flexible payload structure that also incorporates return notification. The sender generates the notification, which is sent along with the message to the receiver. The receiver can elect to respond back by using the IP address of the sender along with a VI name that

is to be called remotely by the receiver which will send the notification locally in the LabVIEW application where the sender resides. It seems like it would be useful if VI Server had an application method that

could send a remote notification. Any ideas? I would like to get away from having to use a proxy vi on the senders file system. I have tried to use a reentrant proxy vi that is the same as the vi that wraps

the NSVQ functions but could not get it to work. The idea was to remotely open up a reentrant clone of the calling vi which has a method to generate/send the notification. I am not sure why this would not be possible but am unfamiliar with the capabilities of VI Server to remotely open up a reentrant clone.

Just in case anyone is interested... The problem is related to a known CAR which will be fixed in LV 8.6.1

The problem occurs when closing DS references in a vi that has NSV's for multiple targets, which was my case.

Yes, I think that is a great idea. In my case I have 6 distributed PC's as well as 6 cRIO in my system and it would be very nice to be able to deploy from the project explorer.

Greetings,

I have an LV 8.6 HMI that performs Data Socket reads from Network Shared Variables. I am finding that it works well until I try to shut down and close all the DS references. I can usually get away with this

once, but if I try to restart the application I often will not be able to reopen the DS reference and it will always crash when I try to shutdown again. I have narrowed it down to just DS opens and closes

and the problem persists. Attached is the error message that pops up when LV crashes, not much to go on but any ideas would be greatly appreciated.

After sitting through another safety meeting this morning I thought I would post this helpful information to the general community.

A XControl has both a Label and a Caption but it is not apparant which control reference it is attached to. Perhaps there is a Hidden subpanel, hmmm... I will take a look and get back to this thread.

Yes, I would like to read the xcontrol's label from within the xcontrol event structure. My goal is to be able to allow the label to be modified at edit time and have the text label

used as a basis for a Network Shared Variable data binding URL.

Does anyone know if it is possible to programatically access a xcontrols label text property. I have looked far and wide but cannot

seem to find out how it is stored.

Thanks,

Yes, I think you are right about that but it does not seem to make any difference in my case.

I would like to programmatically bind front panel controls to Network Shared Variables. For some reason I keep getting this mysterious error

Error 1522 occurred at Property Node (arg 2) in NSV Binding Test.vi

Possible reason(s):

LabVIEW: (Hex 0x5F2) The BindingPath property can only be written when the control is already bound to a PSP URL.

Property Name: Data Binding:Path

I find that I can set some binding properties such as the binding mode, but cannot

seems to be able to set the binding path. I can however set the binding path manually in the controls properties.

This seems like very basic functionality that should work right out of the box, any ideas?

Yes, I could add an input to my NSV wrapper vi but it seems messy to have to add that information to each use on my diagrams (which will be very plentiful).

I guess my question could be distilled down to:

How can a subvi discern the identity of a cloned parent vi instance without having to open up a reference to that parent vi. Opening and closing a vi reference

every time I need to access a NSV seems very wasteful. For example if the call chain indicates the subpanel instance number then it could be done.

Greetings All,

I have a vi that has n subpanels that each contain a instance of a reentrant vi. Each instance is given an identity by preloading a front panel control or the vi description with a unique identifier.

Each instance will need to call a vi that provides Network Shared Variable R/W access. Since this vi is used across all subpanel instances, the vi must know which of n NSV processes is associated

with the calling vi instance. So far the only way I have been able to do this is by using the call chain vi and then reading the top level vi description or 'identifier

control' that contains the correct NSV process name. Just curious to know if anyone might have thought of a better way to do this.

If you use the fixed point acquisition then calibration is included in the measurements.

Whoops! Forgot to make a few more changes, make sure you have the latest upload.