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!
I can currently write code that uses the SysConfig Restart VI to run some cleanup operations and then shutdown a cRIO.
However, if I rebuild my startup application in LabVIEW, and then want to deploy it (or want to restart from MAX) then I have no easy way to call this code when restarting - the cRIO restarts and any handles are left open/half-open until the other end clears them up.
Could we have the ability to register a shutdown VI that is called whenever the target is programmatically restarted (e.g. by LabVIEW's Project Explorer or MAX)?
I understand that in the case of failure and a hard reset via the Reset button then probably this is impossible/implausible, but in the "normal" workflow, this would be a useful addition.
Currently, non default map constants (like the one shown below) are detected as fatal insanities when deploying to Real-Time targets and crash the LabVIEW development environment.
There is a workaround, which is to build the map from other data structure constants. The map constant above was built from the code below. However, it takes longer to execute, and it takes more code. That is okay in some cases, but it would be better if there was an option to simply use the map constant above.
Could we have SSL on by default in the standard software sets for RT targets? It is not like there is much security in the default setup anyway, so having SSL active as well as the web interface with default passwords is just more practical (if that is the rationale for not having it on...(?)).
Background: Whenever I have loaded a default software package onto an RT target using NI MAX, I run into this little snag; I try to log onto it using SFTP or PuttY - only to rediscover that this is disabled. So then I have to go to the web interface or NI MAX to enable it. Most of the time we use RAD to replicate PACs anyway, but this is still another little thing we have to remember every time when dealing with the very first setup.
cRIO with embedded UI enabled allows us RTEXE front panel interactivity, with the ability of front panel objects' properties being changed programmatically. However, when connected with PC via Remote Panel, only object values are updated, but not the objects property (for example: table headers string arrays). This could lead to miscommunication of information as the Front Panel from embedded UI differed from the Remote Panel.
I was informed though, if we looped the write property node continuously, the property can be updated from the Remote Panel end. This, however is counter-intuitive as we usually initialize the GUI objects programmatically once at the beginning (or if necessary due to change) and not continuously. Nevertheless, if Remote Panel can update the front panel objects during first launch and property change, similar to "Is Value Changed.vim", that would be great feature to have.
Based on the discussion in this thread I would like to propose the following:
My suggestion is to open support for execution of python nodes on Labview Real-Time targets. This is currently not supported by LabVIEW 2018 Current Gen, even though this version supports executing a python node using the new "Connectivity -> Python"-support.
This should be possible to do on the targets using NI Linux Realtime as the operating system, since Linux treats python as a native application language.
I understand that the execution of Python scripts are not deterministic, which will prevent an implementation in time critical code. That I can follow, but it should be possible to use the python node in lower priority threads or non real-time code, for communication with a REST-API, downloading/uploading files, connectivity to online services and so on.
Therefore I propose to simplify this implementation and open the support for Python3.
Some additional implementations are essential for the success:
Selection of Python runtime should be fixed to python3, since python 2 will be without further support or active development from 2020-01-01 going forward.
It would gain the best momentum if it was possible to deploy python from the Device Software installation as part of the build specification of the real-time application.
Python developers can specify their external requirements for additional code by defining a "requirements.txt" or "pipfile.lock" depending on the virtualization method and choice of development style. If the project manager or build specification could read/parse this for the starting point of the application to prevent manual labour and possible errors.
Support for this should be from LabVIEW 2018 and forward, since these have support for the python nodes.
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".
64bit has been the dominant architecture for a decade; any computer with more than ~2.5GB of RAM must use it after all. It is inevitable that 32-bit machines will cease to be made - maybe not tomorrow, but let's be realistic. Let's get ahead of the times and convert modules to support 64 bit support. Please!
We have the ability to get memory usage and cpu use. I'd also like to also monitor network usage to see if my application is getting close to the point where it would have to either buffer or drop messages.
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 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.