LabVIEW Real-Time Idea Exchange

Every Fixed-Point number allocates 64 bits (8 bytes) or 72 bits (9 bytes) if you include an overflow status. Working on a cRIO project that I need to acquire and save a large amount of data to process later when the RT CPU has free time to do it (is not acquiring more data nor transmitting data). Since the data is acquired in 12 channels, 51.2 kS/s, with 24 bit each point, the fixed-point allocates 64 bits but uses only 24, wasting 5 bytes (62,5%) for every single data point acquired.

As a workaround, I developed two VIs one to compact the data removing the 5 unused bytes of every Fixed-Point, number keeping the 3 bytes with the data. The second VI does the reverse job. With this I reduced the information to 37,5% of the original, saving space and time to save the information in non volatile memory. Maybe there's a way to do it directly, but I didn't figure it out.

My idea is to add, in some way, the possibility to use the minimum amount of bytes needed by the data, at least for storage purposes. It would be nice if NI add an option to have fixed point in two memory allocation modes:

• Standard: the current way with 64 or 72 bits (probably faster)
• Packed: the number of bytes allocated will be the minimum to hold all information. For a 16 bits data the each data will use only 2 bytes.

At any one time, we have several complex LabVIEW-RT projects that run behavior experiments for us, taking multiple channels of analog and digital data while providing a complex series of audio and visual stimuli.  For each project, there is an RT part that "runs" the Experiment and a tailored Host part that runs the UI, handles an Excel Workbook that specifies the various trials being performed, displays the data, and saves the sampled results to disk.

Each of these projects are developed using LabVIEW Project, and each LV Project has its own, unique name.  When we build UI and RT executables, we would like an "automatic" way to associate them with each other.  A "natural" way would be to use the "shared" information of their joint Project.  There are ways to get the Project name in the Host UI code, both in Development mode and from an Executable.

I would like to propose that NI provide a Property or something similar for the RT side so that the RT code, at Run Time, could determine the Project from which it came.  With both sets of code knowing their shared "ancestor", they could use this information to ensure they are talking to their proper counterpart.  They could also use it to "mark" data structures (such as Files or Folders) that belong to them.  For example, there could be multiple configuration files, one for each Project, but they could be uniquely identified as "<Project> Config.xml" (where "<Project>" is the name of the Project containing the VI, allowing the appropriate Configuration file to unambiguously be chosen at Run Time).

Bob Schor

We use cRIO's in industrial deployments all the time.

While a lot can be done to work around the lack of security offered by the built in FTP server, it would be much preferred if NI would add FTPS (and possibly SFTP) support, or at the very least, modify the existing FTP server solution to expose/support the following functionality:

* define users (currently, only the "password" field is used by the cRIO FTP server, the user name is ignored (or limited to the "admin" name only).

* define folder access rules on a "by user" level

Ideally, the current FTP server would be expanded further to include:

* secured file transfers via built in FTPS support, (or by adding FTPS VI's to the existing FTP toolkit)

* (secure binary transfers via built in SFTP server)

* open up and/or document how the current web configuration tool does the HTTPS file transfer interface

Currently, there are no easy way to allow our end customers to securely pull data log files remotely, and no way to prevent end customer from accidentally accessing or modifying sensitive parts of the application. 

It would be possible to build a custom HTTPS file server on the cRIO, but I have several issues with this approach: it adds development and maintenance of another module to our code, it would most likely require another client side application for the customer to use, and most importantly: a lot of our customers have data collection servers set up to pull data over standard FTPS directly into their historians and their database systems.