The new embedded GUI option on the new LinuxRT based cRIOs is great. It would
a) be nice to be able to access it remotely, and
b) with remote access *all* LinuxRT targets could support it, even the ones without a display port...I would love to use that on our new sbRIO-9651 instead of going back typing in the Bash shell...
c) Perhaps the GUI could even be embedded into the web interface as well :-O
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' !!
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).
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.
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 !
You may say WTF !!!! The manu has so curious ideas !!!!
My need is for example to had 2 configurations for 1 only RT CRio.
Or an other way to use multiples targets ...
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.
Thanks for reading.
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.
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.
I think that the usability of the targets manipulations should be improved.
Thanks for help.
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 ...
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 ...
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.
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.
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.
It would be very convenient if we could format and install the OS/RTE on a target directly from the project window.
Currently, if I'm about to deploy a new application I typically format the target, install the OS software on it, then I deploy the application onto it...and finally I make an image of it that will serve as a way for others to deploy the application to production targets.
This involves use of NI MAX (format and install OS), LabVIEW (deply app) and RAD (make image). Doing all these operations (image-making as well would be great) from LabVIEW would make the workflow much nicer.
PS. In the project window today you have Utilities>>System Manager. The described operations should be available directly from the menu, but it would also feel natural to have these options from the system manager.
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.
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.
(Note: cRIO safety and security IS covered in pretty good detail in the article series starting with Overview of Best Practices for Security on RIO Systems and the linked 3 articles.)
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.
Today we have to remember to build the application prior to deploying it. Instead of just throwing an error if we choose to deploy without having built first; either automatically run a build if necessary, or offer to do so.
Very often it would also be nice to just be able to select "Run as startup", and get all 3 stages done automatically (build, deploy, run as startup).
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).
Sometimes, you really just want a RT front panel. Of course, there is no real front panel, but when you run in interactive mode Labview is automatically setting up network communication to pull data from the RT target and push data to the RT target. Wouldn't it be great if you could just convert that whole front panel into a basic host VI? Right now, you have to manually convert all controls and indicators to shared variables. Granted, this does force you to be very careful about limiting the number of network-shared items that you have, but sometimes you really just want to run the VI in interactive mode...but deployed.
Or, better than that, convert everything into a web service and automatically build a silverlight UI (using Web UI Builder) which is hosted on the cRIO. Anything that provides you with a quick and easy way to convert from the rt debugging UI to a basic host VI would be great.