The new web interface offered when you install a system image to an RT target is very rudimentary, it offers almost none of the configuration options that we had in the Silverlight-based version. You cannot edit the network card settings, you cannot change the date and time etc. All it does is refer you to use NI Max, which kind of defeats the point of having access to basic config without the need for anything but the web browser.
Are there any plans of an update to the web interface any time soon?
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.
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, 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.
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.
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.
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...
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.
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.
A recent forum post discussed possibilities for "Securing a cRIO": Securing CompactRIO, and identified that LabVIEW project access allows the project to upload new rtexes without a password.
You are then prompted for a password to reset the cRIO, but this can be somewhat similarly achieved with a screwdriver and the reset button... (of course, this assumes physical access to the cRIO, whereas project access does not - but I suspect in the forum users' case, the two were approximately equivalent).
Would it be possible to move the login prompt before the new rtexe and accompanying files are uploaded, rather than for the restart?
If you get errors when deploying your real-time VI, you have to scroll through a small window and many many lines of messages to find the error that's in bold text... often only to find that it's just the "startup application is missing" error. It would be better to have a separate box where the errors are summarized for you.
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.
When running a VI in development mode while targeting an RT device, you must "Save All" prior to deployment. This is annoying, especially when using SCC. I'm sure that SourceOnly will minimize this effect in LV2010, but the concept still remains: I don't want to be forced to Save All when I don't want my edits (or automatic linking edits) to persist.
When I choose to "Stop waiting and disconnect" from an RT system that is unresponsive, suppress the dialog box that fires immediately afterward saying that the connection has been lost.....I already know that, I am the one who asked for the disconnection.