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!
In some critical installations, it is absolutely unacceptable for the cRIO to be able to "go to sleep" (as it can do now) and be unreachable via its Ethernet connection, especially when it runs out of real-time in the software. Currently when a cRIO becomes unresponsive, it requires manual intervention to kill power, push buttons, and/or set DIP switches, etc. to bring it back to life. Our company is dealing with cRIOs that are located in places that are very difficult, expensive and time consuming to reach.
I strongly recommend that NI add, Ethernet accessible, hardware based reset/restart functions to the cRIO. These functions should be completely separate from current cRIO software and hardware and should allow remote control of the cRIO power supply, and setting of the dip switches and reset buttons mounted on the cRIO front panel. NI-MAX should be enhanced to allow a user to remotely control cRIO reboots via these functions.
As far as I know, a thumb-drive or hdd that you connect to a cRIO USB port has to be formated using FAT. It would be very handy if NI would support attaching drives formated with the Reliance NITRO file-format. This could in some cases also lessen the pain of being stuck with Reliance (old version) on the cRIO main drive. It would also ensure deterministic file IO on the USB drives in case of power failure, un-expected device disconnection etc.
As cRIO's are deployed in ever growing applications, it would sure be nice if there was an option to use SFTP (and disable FTP altogheter) on the controller. Ideally it would be supported at the OS level, i.e. the existing cRIO FTP server is upgraded or extended to include SFTP as well.
If this is already supported, try searching for "sftp" or "crio sftp" and you'll see only one 3rd party tool-kit, but I confirmed with that company (Labwerx.net) that it (labSSH) does not support cRIO/FPGA/RT targets and there are no concrete plans to add support to other targets.
NI: I call on you to either create the FTP toolkit I need to write my own SFTP server, or better yet, update the cRIO FTP server to include the "s". . . It is only one letter, how hard can that be!?
If this is already possible through some (obscure?) way, please update your site-search engine to reckognize sftp and/or crio sftp, and/or link to a KB or Whitepaper on the topic as I did not find any.
The best thing about Pharlap is that it will run dll's like Windows.
Making shared libraries for VxWorks (*.out files) is quite an arduous process if you don't have Wind River software. The GNU toolchain, that used to be the free alternative, does not work on Windows Vista or 7, leaving those of use who have chosen to upgrade out of luck.
It would be great is LabVIEW could provide a way to compile *.out files from the Application Builder and thereby provide more complete support for development on the CompactRIO platform.
I really miss the ability to debug reentrant VIs in LabVIEW real-time. Currently there is no way at all, short of indirect probing by programming your own debug functionality (logging of some sort).
I understand there are inherent difficulties in this, since LV RT systems are typically headless, and definitely GUI-less (except for maybe www-access).
But, maybe if we had a way to send a BD reference to a Host PC, the block diagram could be opened there? Something like an Open.BD method with a "destination" input on it? Then the reentrant VI could open its own BD on another LabVIEW instance running Desktop LV.
It has a number of improvements over the plain Reliance FS. One of them is, that there is no (less) preformance degradation when there are over x*100 files in one folder. One thing to note is that the system suffers even if you are not reading the files from the folder in question.
We have some software which runs in different versions on the same hardware and in testing, we often need to have the software running for benchmarking or debugging from the development environment.
A major pain is the inability for devices within a single project to share an IP address (when not connected). I would suggest that multiple targets within a single project should be allowed to have the same IP address set (although of course only one can be connected at a time).
I know there has been some discussion in other areas about an "Android build" of LabVIEW, but I am thinking specifically about the Touch Panel Module. An option to target and deploy an HMI onto a low-cost, readily available Android tablet would be tremendous for RT projects, in my opinion. I've got 2 different projects right now that require expensive Win7 tablet PCs, but all they are doing is running a custom LV application to be used as a basic HMI, which is complete overkill. I know the webserver is an option, but it has some limits, and I'd like to have multiple varieties of HMIs available to show varying degrees of system data and performance, which gets dicey with a webserver situation (at least, in my experiences so far).
It just seems like expanding the TPM so that it's keeping up with the times (Android and iOS dominance) seems like a win/win for NI and developers.
We could solve a lot of our designs with sbRIO and LabVIEW RT if the sbRIOs' CAN interface was designed to be a slave, and there was a DS301 compliant CANOpen slave API available for LabVIEW RT.
I'm a bit surprised that only the master side is covered today, as I'm sure a lot of people will utilize sbRIOs in devices that are more natural to define as slaves, not masters.
Throw in a dual set of equivalent network interfaces and the sbRIO platform and RT is an ideal platform for subsea instrumentation, with SIIS Level 2 (CANOpen) and SIIS Level 3 (Ethernet) communication capabilities, at least as long as the power requirements are kept low.
This would be implemented on RT Targets such as cRIO or WSN controllers. The purpose would be to significantly decrease the amount of power used by a controller when it is idling. A typical application would be remote field deployements of controllers programmed as either data loggers or WSN controller node. Competing products offer much lower power consumption than a cRIO or WSN controller. If the RT controller could be put to sleep, with a watchdog timer for instance to set the awake timing power could be conserved.
At the moment the only way around this is to have a third party device applying power to the controller...
Currently many controllers from NI only have one way to deal with a failure to contact a DHCP server - they will try to use a link local address (APIPA). If this too fails (due to Proxy ARP e.g.) the controller will not even start the RT Application (which might have other tasks to do regardless of the lack of netorking and/or might run code that will remedy the IP problem), but go into Safe Mode. This in itself is bad enough and should be changed to allow the application to be run, however the main request / idea I have will fix this indirectly:
- It should be an option to not fall back to APIPA, but to use the last known configuration (as long as the lease time is still valid). If the DHCP server is down the controller will have the IP-configuration it received the last time the server was up, and will use that configuration.
I do not know about most people use cases with RT system, but I have the reflex to click the run arrow to test all my VIs. When I am on site and I do have access to the hardware, everything is rosy. But, when I do not have access to the hardware, and depending on the system complexity, I now have to wait up to over a minutes before I can resume working. It would be nice if somehow once I realized my mistake I could notified LabVIEW (right away) to run my VI in the main application instance instead of attempting to deploy it on the missing target.
Alternatively, once I made the mistake once, LabVIEW could automatically run the VI in the main application instance.
I do not know what is the best approach to fix this, but I know that I am very annoyed every time I make that mistake.
Create an RT FIFO Primative similar to the Get Queue Status VI that returns the number of elements in the RT FIFO. Currently RT FIFO Read and RT FIFO Write return the number of elements in the RT FIFO, but calling these VIs will affect the contents of RT FIFO.
A workaround for this would be to maintain a count on a shift register and increment/decrement it each time the RT FIFO Write/RT FIFO Read VIs are called. This solution does not work when trying to monitor the size of an RT FIFO in a running VI in another VI that is used to detect memory leaks.
I frequently use the RT Debug String VI to add useful comments about the health of my application. Sometimes, I believe it would be nice to indicator error/danger conditions with a different color of text.
Do you feel it would be useful to have the ability to change the color of the string? If so, vote me up.
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.
At the moment, there is a small development problem with dynamically launched VIs (via the Asynchronous Call method). They are not recognised as dependencies during the deployment process, so the code can't be run effectively in development mode via the run arrow (those VI's will return File Not Found errors).
A simple fix for this would be to be able to mark VI's as "always deploy" in the project window.