LabVIEW Real-Time Idea Exchange

Community Browser
About LabVIEW Real-Time Idea Exchange

Have a LabVIEW Real-Time Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. 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!
  3. 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.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Hi !

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' !! Smiley Happy

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 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 ...

 

  1. Launching the installer
  2. The installer lists all available (and compatible) targets
  3. The user has to choose a target
  4. After target selection, the installer should view the target configuration ( as defined in the Labview project Build specification properties )
  5. The user could then modify some parameters (like IP address)
  6. After validating the configuration, the installer should
  7. Install the drivers ... and perhaps the OS itself (as required by the project)
  8. Modify the target parameters 
  9. Install the application
  10. Set Time/hour according to host target
  11. Download custom files and directories ..
  12. ...
  13. 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.

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.

 

Hello,

 

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.Smiley Sad

 

I think that the usability of the targets manipulations should be improved. Smiley Wink

 

Thanks for help.

 

Manu.net 

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.RT Target Properties Window.PNG

Message Edited by Hueter on 10-29-2009 11:58 AM
Message Edited by Hueter on 10-29-2009 11:58 AM

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.

Message Edited by Laura F. on 10-09-2009 09:01 AM

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.

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.

Changing the IP setup currently requires a restart. It is now possible to change the configuration of all network interfaces programmatically using the System Configuration API, but it's not possible to put such changes into effect on the fly, so you actually have to shut down your application to put the changes into effect, something that might not be allowable.

 

So let's say e.g. that I have a controller with dual network interfaces and I want to reconfigure one of the network interfaces (turn on DHCP e.g.) - but I do NOT want to stop the RT application, because it controlls processes via other interfaces, and those processes must be kept alive. If it was a Windows PC, I could have done it. On an NI controller, which is ironically then typically used for more critical tasks, I cannot.

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

 

I have just gone through a somewhat painful support process to figure out how to adjust something as simple as the analog channel scaling on a NI-9203 module installed in a cRIO rack.  Why there is no external way to adjust those properties, besides having a development system hooked up and accessing them through the Project Explorer, is a little baffling.  After going a little round and round on the support call, it came down to this:  modify your embedded program to include property references, where you can adjust the scaling programmatically.  That means I need to modify my code, rebuild the executable, email it to the customer, get them to shut their entire line down, put the cRIO in the "don't run your startup VI" mode, upload the new program, restart, then finally get their entire line back up and running.  All because they need to change the scaling on one 4-20mA analog channel from 0-400 to 0-500 units to match their PLC control system changes.

 

Seems like there should be a way to get into that configuration, maybe in MAX?  We can see the cRIO processor, but can't get individual module or channel configurations.  Distributed System Manager might be another place that properties could be adjusted.  Anything to make the cRIO simpler to support in the field!

0 Kudos

For the use of a variator that generates his own clock and distributes it on EtherCAT, I need to make the RT loop synchronous with clock posted on EtherCAT by the variator.

So would require the scan engine parameter is in receipt of the EtherCAT clock.

This function is imperative on Labview-RT to be compatible with ability to manage EtherCAT variators ( Beckhoff).

0 Kudos

Creating an OPC UA address space by hand is very tedious.  It would be easier if you could import an OPC UA NodeSet XML file and map OPC UA variables to measurments.