LabVIEW Real-Time Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Sorry if this is a duplicate idea I searched and couldn't believe it hasn't been posted.

 

This idea is to add Linux RT deployment support for desktop PCs.  NI in the past has had a process for purchasing an Phar Lap RT license, then deploying it to a normal x86 based PC.  Here are the System Requirements, and a manual.

 

This opened up the door for desktop PCs to become embedded PCs, controlling NI hardware, but allowing for an upgrade path where embedded cDAQ devices, and even PXI controllers don't have many options.

 

At the moment there are unofficial ways to get Linux RT on an x86 based desktop with limited success, but no support.  These options are outlines in the comments of an idea to allow for a VM of the Linux RT environment.  NI could go with a similar route to Phar Lap and sell a license with a list of supported hardware.  

I use "Set System Image" to set an image on freshly manufactured units. Every now and then, the imaging process fails for one reason or another (possibly a hardware/networking failure). I know that the image process in my case usually takes about 4 minutes. Unfortunately when the imaging process fails, there's no way for the application to gracefully stop "Set System Image". The only option is to wait a really long time or use the task manager to force-quit the application. The abort button on the VI doesn't work

 

So, I'd like one of two things. Either, an input so I can adjust the timeout based on my application or some way to let "Set System Image" know that the application would like to stop if possible (maybe nothing had been written yet). For example, it could take in a DVR and the application could feed it a "true".

System Image Escape.png

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.

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.

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!

QFang 

It is really useful to be able to edit text files through the web based file explorer.

 

As it stands only certain file extensions are editable. (.conf, .txt, .ini). It would be great if all files were editable by default to handle custom extensions used on our applications.

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

Hello,

 

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,

Cu

Westgate

 

 

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.

The Set System Image VI (and by extension, the Replication and Deployment Tool) have a deployment blacklist. Currently, files on that list are never deployed. It would be helpful if instead, those files, if they exist in the image, were deployed only if they do not already exist on the target. That would make it easier to create a single image that could be used for both an upgrade, where you do not want to overwrite existing configuration files, and for initial setup, where you want to install a default configuration file.

 

Did I misunderstand something about the way the deployment blacklist works? The documentation says "Files on the blacklist will not be copied from the image to the target" which makes me wonder why you would ever want to include those files in the image at all.

The RAD tool is not a perfect fit for all cRIO deployments.  If you are unable to use the RAD utility to deploy a new version of drivers to the cRIO the process to get the Network Variable Engine onto the cRIO goes something like this:  Install LabVIEW and LabVIEW Real-Time, install NI CompactRIO drivers, install NVE and other driver software to the cRIO and then uninstall the LabVIEW components from the host PC.  This assumes that an executable will be installed to the host computer as the UI to the cRIO.  Seems like a lot of work for something most people would be using on the majority of cRIO deployments and might assume is a part of the CompactRIO drivers.

 

At the very least it would be great if the documentation found on the website were explicit as to what software needs to be installed for each of the install options available to install on to the cRIO.