Jump to content

viSci

Members
  • Posts

    456
  • Joined

  • Last visited

  • Days Won

    17

Posts posted by viSci

  1. 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.

  2. 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.

    post-162-1227217038.png?width=400

  3. 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.

  4. 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?

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.