viSci

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.

In case anyone besides myself is still using the Excel GOOP toolkit by Martin Vernhout from Philips Research, you will find that it no longer works in LV 8.6. Apparently LV 8.6 rejects depricated activex properties that were working just fine in LV 8.5. I am attaching the fixed version. Also, LV 8.6 no longer installs the old _goopsup.llb files so you will need to install them yourself.

Pretty cool... I wonder if it has the resolution to capture a camera image, it might be kind of scary to have your face liquified.

I have been investigating the new RT Scan Engine and would like to compare notes. I have been testing the Forced I/O vi's and have found them to be very slow (~500ms/call) Anyone else tried this yet? Also, am curious to know what the plans are to extend the I/O Variable API so that we can programmatically create and/or rename Variables and modify scaling properties. It seems that the dll's under the hood have the hooks to do these things but the function prototypes are not published or wrapped yet.

Ok, the problem with 'scan from string' is that it cannot be used when trying to transfer an enum into a subvi. The only way to do that is with a variant. So how about adding some goodies to the scan function to scan a variant and we could have it do all sorts of cool lvdata parsing including obtaining the enum string.

I should have explained my application... I would like to create a generic CVT (Current Value Table) for cRIO applications. Instead of strings, I would like to use typedef'd enums as the tag key on my diagram. The generic interface for a CVT read or write would have a variant input for the enum key and a DBL,STR, or BOOL as the data input. I need to convert the enum to a string and use it as the key of a variant attribute which is used to strore all the CVT data. I thought it would be nice if the enum could be automatically converted to a string at the vi interface (I am sure NI could do it more efficiently than I can). I am currently preprocessing the enum typedef to extract all the strings and then use the enum cast to a I32 to index out the string. Overall, on the cRIO, it turns out that working with variant attributes is quite costly in performance so I may have to rethink the whole approach.

I was wondering why LabVIEW does not automatically convert enum's to strings on subvi inputs. The information is available on the wire so why not just offer this as a convenience instead of having to send it in as a variant and doing the conversion manually inside the subvi. I think it would promote the idea of using typedef'd enum's as diagram tags instead of having to use strings which cannot be 're-applied' when the typedef changes.

Here is a multichannel boxcar filter with individual filter orders. Originally wrote it as a LVOOP class (my first!) but then tried to deploy to my cRIO and felt really dumb since LVOOP does not run on LVRT!!??