Any controller that contains either a USB or SDIO card would have a bootstrap loader, available when the controller is in safe mode, that would allow the controller to be loaded up to operational status (OS, Drivers, RTEXE, etc...) from a deployment image contained on the removeable media. This would allow a replacement controller to be unboxed and installed in a stand alone system without the need to install software from a development computer.
This is one of those things that sort of bridges between a hardware and software request.
As cRIO's are deployed in ever growing applications, it would sure be nice if there was an option to use SFTP (and disable FTP altogheter) on the controller. Ideally it would be supported at the OS level, i.e. the existing cRIO FTP server is upgraded or extended to include SFTP as well.
If this is already supported, try searching for "sftp" or "crio sftp" and you'll see only one 3rd party tool-kit, but I confirmed with that company (Labwerx.net) that it (labSSH) does not support cRIO/FPGA/RT targets and there are no concrete plans to add support to other targets.
NI: I call on you to either create the FTP toolkit I need to write my own SFTP server, or better yet, update the cRIO FTP server to include the "s". . . It is only one letter, how hard can that be!?
If this is already possible through some (obscure?) way, please update your site-search engine to reckognize sftp and/or crio sftp, and/or link to a KB or Whitepaper on the topic as I did not find any.
(Note: cRIO safety and security IS covered in pretty good detail in the article series starting with Overview of Best Practices for Security on RIO Systems and the linked 3 articles.)
It would be very convenient if we could format and install the OS/RTE on a target directly from the project window.
Currently, if I'm about to deploy a new application I typically format the target, install the OS software on it, then I deploy the application onto it...and finally I make an image of it that will serve as a way for others to deploy the application to production targets.
This involves use of NI MAX (format and install OS), LabVIEW (deply app) and RAD (make image). Doing all these operations (image-making as well would be great) from LabVIEW would make the workflow much nicer.
PS. In the project window today you have Utilities>>System Manager. The described operations should be available directly from the menu, but it would also feel natural to have these options from the system manager.
Many developers have the primary ethernet port of their development computer reserved for the corporate intranet/internet access.
Unfortunately, MAX and other tools like RT System Deployment Utility expect the targets to be connected to the same primary port for initial configuration, because they do not allow the specification of a local IP on which to exchange the UDP configuration packets.
Being able to select the ethernet port on which the RT system is connected, e.g. through a ring control populated with all available NICs and their local IPs, would facilitate devolopment enormously in such constellations, because the developer would not need to switch cables and IP configurations every time he needs to reconfigure the RT system.
It should be nice to add a new "Build specification" in Labview RT which could generated something like a RT Target installer.
This installer could contain ...
When the installer is executed, it should be nice to show all the available targets ( Like in Max ).
The user should have to select the destination Target in this list.
Then it should be nice to show the target configuration (like in Max), initialized with the setting contained in the installer.
An installation could be like this ...
This feature could be an easy way to deploy RT application without having a Labview RT installed on the host computer.
A RT application could be installed completely by a final customer of the application, without having to install the Target, drivers ...
This could also be nice to clone many times a RT application.
As far as I know, a thumb-drive or hdd that you connect to a cRIO USB port has to be formated using FAT. It would be very handy if NI would support attaching drives formated with the Reliance NITRO file-format. This could in some cases also lessen the pain of being stuck with Reliance (old version) on the cRIO main drive. It would also ensure deterministic file IO on the USB drives in case of power failure, un-expected device disconnection etc.
Thanks for reading and hope for your vote!
I do not know about most people use cases with RT system, but I have the reflex to click the run arrow to test all my VIs. When I am on site and I do have access to the hardware, everything is rosy. But, when I do not have access to the hardware, and depending on the system complexity, I now have to wait up to over a minutes before I can resume working. It would be nice if somehow once I realized my mistake I could notified LabVIEW (right away) to run my VI in the main application instance instead of attempting to deploy it on the missing target.
Alternatively, once I made the mistake once, LabVIEW could automatically run the VI in the main application instance.
I do not know what is the best approach to fix this, but I know that I am very annoyed every time I make that mistake.
The Reliance FS used by Labview RT can be accessed in a Windows computer using the driver provided by Datalight. Unfortunately this driver is only for 32-bit windows systems (including Windows 7). It is getting harder and harder to find 32-bit windows computers as 64-bit processors are widespread.
Could we get a 64-bit Windows Driver for Reliance FS?
it would be very nice if i could give users in the Web-based configuration more specialized filesystems rights.
In the moment i only can give the user the right to write on the whole filesystem or on nothing.
In my case i would like to sent our customers updates of the startup.exe, which they can install their self via ftp. Without them having access to everything on the filesystem.
Please vote if you would like to have this option,
It would be nice if attaching a thumbdrive to a cRIO / RT usb port triggered a "mounted" event or interrupt in the RT OS. Currently the only way to discover if a thumbdrive has been connected is to periodically run a file/folder info VI and see if one is present. It would be nicer if we could register a dynamic event and wait for it using an event structure, or similarily register for an interrupt event would work as well.
In my case, the use-scenario is a field maintenance person going out and manually plugging in a thumb-drive about once every 4 weeks to get the stored log files off of the controller. (No, we cannot use remote access in this case due to customer network restrictions.) So, in my case, I can easily use the polling solution, but if there is one thing I don't like to do, its to write polling code of any sort. It seems so wasteful. Other possible use cases could be to detect the presence of a thumb-drive and check for patch/updates, copy over new configuration files, etc.
I did not see any options for this in labVIEW. I saw only you can play around writing and reading sound files and perform some manipulation to sound file.
Why not we compare two sound files extensively and indicate about similarities. For example, a system is running with constant sound(Motor is running in good case) and other hand the same system is running bad after some days or years(sound is different and louder with noise).
Second, if we can compare a sound with another sound, that would be interesting and possibly useful in applications. I know that many sensors out there for this operation but thought of interest to see it digitally in labVIEW.
If any thing wrong with my idea, please let me know.