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!
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.
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...
In brief, bring us back the 'Console' !! :smileyhappy:
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.
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:
What do you think about it?
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.
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:
It should be nice to add a new "Build specification" in Labview RT which could generated something like a RT Target installer. This installer could contain ... The application to download The drivers required Additionnal custom files and directories The default setting of the target ( Like the MAX target configuration) When the installer is executed, it should be nice to show all the available targets ( Like in Max ). The user should have to select the destination Target in this list. Then it should be nice to show the target configuration (like in Max), initialized with the setting contained in the installer. An installation could be like this ... Launching the installer The installer lists all available (and compatible) targets The user has to choose a target After target selection, the installer should view the target configuration ( as defined in the Labview project Build specification properties ) The user could then modify some parameters (like IP address) After validating the configuration, the installer should Install the drivers ... and perhaps the OS itself (as required by the project) Modify the target parameters Install the application Set Time/hour according to host target Download custom files and directories .. ... And restart the target This feature could be an easy way to deploy RT application without having a Labview RT installed on the host computer. A RT application could be installed completely by a final customer of the application, without having to install the Target, drivers ... This could also be nice to clone many times a RT application.
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, 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.
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.
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.
It should be nice to be abble to duplicate a CRio target easily.
=> Be abble to duplicate the Target
=> Be abble to duplicate the backplane configuration
=> Be abble to duplicate a FPGA target
It should also be nice to be able to change easily ...
=> The CRIo type
=> The CRio backplane type
Some commands to manipulate targets are missing ... or are hidden ...
For example the copy/paste commands are available by key stroke ... but are not visible thru the Labview project treeview context menu.:smileysad:
I think that the usability of the targets manipulations should be improved. :smileywink:
Thanks for help.
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.
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.
It would be nice to had the ability to create more than one RT target in a project with the same IP address.
For the moment, if you try to use 2 same IP address, The LabVIEW IDE don't let you save your modifications ! :smileysad:
You may say WTF !!!! The manu has so curious ideas !!!!
My need is for example to had 2 configurations for 1 only RT CRio.
1 configuration in Scan Interface
1 configuration in FPGA interface
Or an other way to use multiples targets ...
1 project linking to Version 1 sources
1 project linking to Version 2 sources
Yopu may say this can be done by using different build specifications.
I will say yes ... But my need is to separate the two versions of LabVIEW sources !
=> 1 project/target linked to an autopopulating folder in version a
=> 1 project/target linked to an autopopulating folder in version b
=> So my need is to be abble to use RT Targets as "Target versions"
=> To be abble to do this ... i need to create multiple targets with identical IP addresses. :smileywink:
Thanks for reading.
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. Message Edited by Hueter on 10-29-2009 11:58 AM Message Edited by Hueter on 10-29-2009 11:58 AM
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.
If you have an RT target set up with a startup application (ready to be deployed in the field), running a VI on it from the IDE should not change anything permanently.
Today (LabVIEW RT 2013), doing this will not just temporrarily stop the VIs running on the target (from the executable) - as you get warned about, but also cause the RTTarget.LaunchAppAtBoot=True line to be removed from the ni-rt.ini. So the startup application will not be launched the next time the device is started up, rendering your device useless in the field. Why?
- We had an incident where we narrowly escaped such a scenario. The RT target was embedded into a cannister that was about to be sealed, but an unforseen issue made it necessary to run a special test on it, with a VI from the IDE. The startup application in this case provides the only way into the system once the cannister is sealed (no Ethernet access, just RS485), so having it no longer start would be a catastrophy. No one expected running the VI would actually change anything permanently. We tested it of course, and saw that it stopped the startup application (and so we loaded an image of the correct setup afterwards to be sure all changes were removed), but it would be much better and more intuitive if no such permanent and fundamental changes occured (if actually possible to implement in a such a way).
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.:smileysad: