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!
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.
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!
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".
When developing RT code (especially system upgrades) it would be truly helpful to have a virtual machine (VMware, MS Virtual PC, Sun Virtual box, etc....) that would allow us to run the actual VxWorks OS and LVRT in it's native environment, within the Windows OS. This would allow the code to run on the actual RTOS (I realize that determinism would be scacrificed) and provide the ability to actually test the functionality of the code in the actual environment to ensure that it runs as it should. It would also preclude the need to have a bunch of RT controllers sitting on the shelf in the event that you might need them.
There is and emulator for PDA module, why not for RT.
Currently, if you have hardware in a LabVIEW project (e.g. a cRIO controller, cRIO chassis, or R-Series PXI card), the only way that you can change this to another product is by adding a new one to the project and deleting the old one. It would be nice to be able to use a configuration window to change the model number of a piece of hardware to a different, but similar one. For example, if you have a 9072 in the project but wanted to change it to a 9073. Another example would be the ability to change, via menus, a PXI 7813R to a 7854R. Of course the user would have to update any code written to account for changes due to the new hardware. This is especially convenient when you are simulating and configuring test systems but aren't quite sure exactly what hardware you need. Currently, for each new piece of hardware (similar or not) you have to create a new device and copy all of the IO, VIs, libraries, etc. under the new device in the project.
Inspired by this post, and my own experience trying to debug a problem that only appeared when I compiled an RT executable, LabVIEW should warn the user when compiling a real-time application that contains property nodes that require access to the front panel, since those property nodes will not execute properly in an RT application and it can be very difficult to find the source of the problem if you don't know this.
Right now, you can simulate the I/O from an FPGA target. Timing features and other hardware-specific VIs are not executed, but the code still functions and allows you to debug certain aspects of it without working through the compile process. It would be similarly helpful if you could simulate the real-time controller, or a cRIO in scan mode, with simulated IO. Again, the resultant VI will not be truly realtime, but it would allow useful development without having constant access to the cRIO.
With the linux-based cRIOs the console ("Write To Monitor" ; as intended before working with VxWorks/PharLaps OS) disappeared.
It's only possible to have strings pushed to the RS ports or in a (not managed) file.
As many cRIOs are connected to the network, it would be nice to have the "Write To Monitor" console access through Ethernet port.
The idea would be also to keep the global functionnalities of this console : see the strings in the cRIO webpage (of course), but also keep strings in a managed file (max number of logs in a file, ...) to have a 'buffered' access to strings sent to the console...
I noticed there seem to be no way to guarantee the state of an output module controlled by a scan engine in case the RT Application (or the Host Application, depending who is controlling the chassis) crashs. With FPGA one can program some kind of watchdog setting back the output values of a module in case the RT Exe fails. With Scan there just seem to be no possibility.
This is why I think adding a FailSafe Value for a Scan I/O node could be a creat idea. in ase the RT application got aborted or stops without cleanup, the output value would not be random no more but set back to their FailSafe value. I imagine it could look like that:
When working in the Windows development environment the application builder has the ability to implement a version number for the built executable. Additionally LabVIEW has the ability to querry this version number through a property node. I would like to see this feature carried over to RT systems as well. It would be very helpful in determining what particular build of the startup.rtexe file is running on the target.
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.
Currently, you can view the console from MAX, but if you don't know what buttons to press... lets just say it's in there somewhere. My idea is to make it more accessible, such as a right mouse button feature off the RT Target.
The real-time controllers have a "Time server" IP input in their setup. That is great, but it is not great that the time server has to be a piece of NI software (Logos). If it was possible to specify an NTP server for example (and/or other standard protocols), this feature would be much more useful.
Most of the time we need the PACs to be synced with a third party system.
Many measurement and process control application run at relatively slow rates (<100Hz). Using SCAN Engine on the CompacRIO for data acquisition is ideal for these applications because you don't need to program the FPGA and all the measurement and control logic can be implemented on the Real-Time controller.
In many cases you want to process your data before you analize it. Currently you only have the ability to get the raw measurement data from the AI modules, so you need to add the data processing code to your existing LabVIEW program. It would be helpful if the SCAN engine could offload some of the data processing (ex. lowpass filter or sample average) to the FPGA and provide the user with already processed data. For example, this functionality can be added to the module configuration page:
I am often working with a compact RIO and I need to change the IP configuration or the software settings. Currently I have to open up MAX refresh my target list (which can sometime take a minute or two since we have so many targets). Then open up the RT target settings.
I think the IP address and software settings should be accessible from the project window by right-clicking on the target and selecting properties.
The MAX settings page could be reproduced in the general settings section that all ready has a limited ability to edit the IP.
You could also add a software category, so you could update the version of RIO or install scan engine.
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.