Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
Watch as the community gives your idea kudos and adds their input.
As NI R&D considers the idea, they will change the idea status.
Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
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.
When using the "Open FPGA VI Reference" function you can configure it to reference the FPGA build/bitfile in three different ways:
- Build specification
In development mode I often use "Build spec", for deployment I switch to "Bitfile". When using this function it behaves different, depending in which mode it is configured! This makes for a bad "User eXperience"…
In "Build spec" mode:
- when double clicking the pink border of the function it opens the referenced FPGA VI
- you need to right-click the "Open FPGA VI reference" and select "Configure…" to open the configuration dialog
- when selecting the "Build Spec" radio button it opens a selection dialog (probably a listbox) but you can't double click the build spec you want to use, you need to select the build spec and then click on "OK" button
In "Bitfile" mode:
- when double clicking the pink border of the function it opens the configuration dialog, (you don't need to right-click the "Open FPGA VI reference" and select "Configure…" to open the configuration dialog)
- when selecting the "Bitfile" radio button it opens a file dialog and but you can double click the bitfile you want to use
(All this relates to LabVIEW2014SP1. Haven't tested this with LabVIEW2015 so far.)
I propose the idea to make this behaviour consistent, independent of the selected mode in the configuration dialog!
I wish this behaviour:
- double click on pink border of the functions opens the configuration dialog
- double click on the FPGA VI icon shown inside the "Open FPGA VI reference" function opens the FPGA VI
- double click on an item in the "Build spec" selection dialog selects the build spec
It seems making plugins to Visual Studio has been abandon but it wouldnt matter if we were able to use a modern and full featured IDE. Use eclipse as a base IDE and develop features on top of it including the ability to downlod and execute code to real time targets. Developing an IDE based on eclipse isnt unhead of this is vxworks does with wind river workbench.
I would like a new string data type - a "rt string". There would be a property of the variable that would set the max. string size, and allocate memory at once for that size, similar to the way it would work in C. Additionally, there would be rt equivalents of most of the string functions, that would function just as in C, and would not result in memory allocations. This would allow (at least some!) string functionality in deterministic loops.
When I could run (and debug) my RT application from Development environment then I should be able to Build this application for my RT target without problem = without Error no. 1502 = LabVIEW: Cannot save a bad VI without its block diagram.
In this discussion I could see that this problem is not new and NI know about it. For hits how to solve this problem, please, follow same link.
I have to generate and store the jpg file in crio. The code works on my local PC. When I deploying the same in crio, it didn't work. It returns zero. Also I tried the paths like c:\test.jpg or /c/test.jpg; both didn't work. We are using Labview 2011 full professional development system.
I don't know really it is possible or not in analog domain but I am bit confident about this in digital domain.
I am facing this problem in my current work. Why not, we implement this as mentioned in the below picture in labview. If I am wrong with anything, please let me know.
I am just using labview from 2 months and I am not sure this is possible or not. I guess I can not use any filter here for separating exactly those peaks. May be in some systems, peaks shouldn't place always at the same frequency.
I hope you will understand after a look at picture. I just have taken that picture from my notebook. If it is not clear, I will try to give much clear picture.
LabVIEW provides an interactive front panel when running an RT application in the LabVIEW development environment. However, once you deploy this front panel is no longer available. I think it would be helpful to make the front panel look differently or somehow give a visual warning/indication that this is a debug feature and will not be available at deployment. (This could be something as simple as a watermark, similar to the evaluation watermark that LV employs). Many new users get confused and run into problems by using lots of front panel controls/indicators and then finding out later these are not applicable at deployment.
I have been recently tasked with porting a Windows DLL to Phar Lap. So, code is not my own, there's a lot of it, and the DLL is crashing with stack overflows. Recursion is not a problem here, so it's obvously a local variable space. The default thread stack size is 128k, which is a bit on the low side. An ini setting that would allow to increase this would be most welcome. Especially if you're not getting errors in your own thread, but in the LabVIEW ones.
RT Engine it does not include the front panel in built executables, see link. Control references are only supported when the development system is connected to the RT target. It would be nice if there was an option to keep the front panel in some of my VIs when built into an executable and run without a user interface. This can be a powerful tool. One could parse a cluster and creating files based on properties of controls.
If you use a VI to control a RT target via Web browser then only polling is possible to register user actions. Since: "RT targets support the Event Structure only with dynamic events." (LabVIEW Help 2010) You can program such graphic object events but they doesn't work.
The support of graphical object events would improve the capabilities for applications with cRIO and sbRIO without a LabVIEW-Host.
VI Server nodes are asynchronous nodes. I would like to be able to get the VI Name in a subroutine. This could be done now with an XNode. Or, it could be a compiler optimization. Since VI Server nodes are a shared resource, they can cause a priority inversion.