LabWindows/CVI Idea Exchange

We have a nice password control for user management. Alas, we are on our own when it comes to secure networking or saving/retrieving the data, passwords etc.

It would be nice to have some sort of cryptography.fp included. The simplest I found was the blowshish algorithm: it is fast and as far as I know, sound too. A crypto-module could be built around it. Moreover, it is available for Labview already...

Include a function to programmatically re-start the NI Variable Engine if it is found to be stopped.

Although the NV libraries include a function to detect whether the NI Varible Engine service is running, there is no function included in the library to facilitate re-starting the NI Variable Engine service. 

For those The method that I am aware of to restart this service is to use the ANSI C system() function with an embedded command line:

Index = 0;                                           

CNVVariableEngineIsRunning(&running);

while((!running) && (index++ < 5))

{

System(“net start \"NI Variable Engine\"");

                Delay(0.1);

                CNVVariableEngineIsRunning(&running);

}

if(!running) return -1;

Learning this required some time spent on the web, looking through old posts on how to solve the same problem in LabView.  Rather than spending that time, it would have been more productive to just pull it out of the library.

I discovered through trial and error that the CNVCreateBufferedWriter function, while it does provide buffering when necessary to preserve data until it can be written within a process, it does not provide for arbitration between writes originating from multiple processes.  Stated another way:  As far as I am aware, a single Network Variable process is not designed be written to by more than one application.

The documentation was not clear on this point.  It states “You can buffer data to be written to the network variable by calling CNVPutDataInBuffer. The system automatically writes the buffered data to the network variable.”  This suggested to me that arbitration of some kind existed to handle asynchronous writes by multiple applications.  I confess, my interpretation may have been driven by wishful thinking to support my application needs.

Nevertheless, my suggestion is that future versions of this library include a capability to arbitrate asynchronous writes from multiple applications to a single network variable.  i.e., that two, or three, or more applications can successfully connect to and write to the same network variable.

Add a function to the utilities library that can copy an entire folder along with all its files and sub folders.

Similar to what the command line xcopy can do.