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 SVE on a windows based platform acts as a OPC-DA server. Due to the requirements for DCOM, this is not possible on real-time target. However, as OPC-UA is gaining traction, I would find it very useful to have the SVE act as an OPC-UA server for integration with 3rd party systems (SCADA, IIoT).
I know that there is the OPC-UA API palette, however, this takes more time to setup than creating a shared variable (i.e. a tag) and moving on with the application development. If update rates are slow enough (500-1000ms), I have found the shared variable to be more than adequate for my applications (500-800 NSVs), so I'm not looking for granular control over how I send data out of the cRIO system. Ease of use is my primary concern.
Currently a VI running in a Real Time environment does not support run time menus. I understand the restriction, but what I find odd is VIs that have the menu reference wire cannot compile for RT targets. This may seem like no big deal, because why would you have a menu reference wire, but not use it? But I have come to find two examples that make RT code a bit more difficult due to this issue.
If I have a polymorphic VI, and one of the polymorphic types has a menu reference terminal, then I can't use that polymorphic VI in an RT VI, even if the instance that is being used doesn't use the menu reference. One work around for this is to wrap the entire VI that does use the menu reference (terminals and all) in a conditional disable structure so that it does nothing on RT.
Another issue comes in the form of templates. I have various temples to get code started, and most of it can run on RT or other targets without any need to change the code, just place conditional disable structures where needed. But I found one issue where I can't have an event structure on RT, that has the Shortcut Menu Activation? event, because it generates a menu reference wire. Ideally this event just can't be generated on RT, so the compiler would know to not include it, and it would allow the VI to run on RT. Same for polymorphic VIs that have a menu reference in one of its instances.
A better solution might be to lift all restrictions of using the menu reference wire on RT, and just assume that using the menu reference on RT does nothing, like a No-Op. Optionally an error could be generated if one of the menu reference functions are used, but for the sake of simplicity I'm not sure that is needed. What I'm really looking for, is a way to allow VIs to run on RT, that have menu reference wires types, but aren't used. Note the VI below which can't run on RT and the reason given is that the menu reference can't be used on RT, but it isn't being used, it is just wired to a disabled case.
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
Propongo se actualice el vi "RT Ping Controllers" para las últimas versiones de Labview, funciona muy bien en aplicaciones HOST que comunican a CRIO por ejemplo,he utilizado este vi de la versión 8.6, sin embargo no sé hasta que versión pueda ser soportada.
I have a text file with a table of data (text file example attached) , this file will be increasing with time , perhaps 500 lines per year , i want to read this file from labview and to be able to search a name (first field of the text file) and the data in the same line belongs to that name , the idea is to read line by line and if the first field matches the name searched , then get all the data in that line as a string , the data types don't matter .
As well i have to be able to delete a complete line of the same text file if the name matches the one searched .
Any idea will be agreat , Thank you very much for your help and time !
At my company for all of our real time work, we are starting to use Veristand a lot. It is great that there are so many already available primitives on the Veristand palette within labview which are very useful. However, there is currently no Veristand primitive in Labview, that actually starts the Veristand.exe program itself. You have to use the System Exec to do it. I think adding a Veristand primitive that performs this function would be great.
For the NI 6008 card sampling frequency equal to 10 kS / s and it has 8 analog inputs, but if I will use the 8 analog inputs simultaneously, what is the value of the new échantionnage frequency for each input analog obtained during an acquisition in labview?
To allow expansion of DAQ capabilities from a real time PXI Rack it would be nice to be able to add a Compact DAQ chassis to the ethernet port and address it like you can on a desktop. I understand this is possible for USB connected chassis but not ethernet.
This would allow an existing RT DAQ system to be easily expanded, or to acquire data from remote points without the necessity of wiring every channel back to the main rack.
Many of the features that are not supported on LinuxRT are things that one would expect not to work (due to the underlying technologies), but why no menu and cursor functions?
The lack of menu support in particular means that most GUIs have to be customized to run on the target....even though Xfce should be perfectly capable of handling them in their original design... I was really hoping we could port some of our GUIs straight to the embedded GUI and replace our industrial computers immediately with cRIOs...(the differences in appearances are easier to handle, after all we use system controls and take cross-platform variations into consideration already).
Now we'll have to (decide if we want to) spend time on customizing the GUIs.
It would be good to enhance access security to also include program-control of cRIO's. As it is now you can set user access for a cRIO in a project by opening the Real-Time CompactRIO properties and set Allow/Deny access by IP. However, this only limits access to deploying settings and eventual RT applications on the cRIO. You can still control the cRIO (e.g. set outputs and, as in my case, control servo motor drives connected to the cRIO) from a LabVIEW application on any PC on the LAN.
This added access control could eventually be set up in MAX.