NI Home > Community > NI Discussion Forums

LabVIEW Real-Time Idea Exchange

Announcements
The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea

Hello,

 

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.

 

Manu.

Naity

Scan Engine: FailSafe value for output nodes

Status: New
by Active Participant Naity on ‎06-13-2013 04:46 AM

Hi,

 

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:

 

failsafe.png

 

What do you think about it?

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.

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.

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

 

I think that the usability of the targets manipulations should be improved. :smileywink:

 

Thanks for help.

 

Manu.net 

Broken_Arrow

Make the RT Console Easier to View from MAX

Status: New
by Active Participant Broken_Arrow on ‎08-15-2012 12:56 PM

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.

 

View Console.png

jarcTek

Allow RT FIFOs to be of type LV Class

Status: New
by Member jarcTek on ‎08-29-2013 03:25 PM

I had posted this idea to the LabVIEW idea exchange before, but it makes more sense to have it here.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-RT-FIFOs-to-be-of-type-LV-Class/idi-p/2426726

 

It would be very useful that RT FIFOs could be of type lvclass as long as the class' private members are of static types (perform the same check that is done for clusters when you try to use them as the type for RT FIFOs).

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.

 

Thanks,

Sebastian

Mads

Support industry standard time server (NTP e.g.)

Status: New
by Active Participant Mads on ‎03-07-2013 02:49 AM

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.

manu.NET

Complete installer for Labview RT Targets ...

Status: New
by Member manu.NET on ‎02-10-2010 11:15 AM

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.

 

 

 

 

 

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.

 

1.png

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.

gsussman

Field installed RT target

Status: New
by Active Participant gsussman on ‎03-25-2013 05:30 PM

Any controller that contains either a USB or SDIO card would have a bootstrap loader, available when the controller is in safe mode, that would allow the controller to be loaded up to operational status (OS, Drivers, RTEXE, etc...) from a deployment image contained on the removeable media. This would allow a replacement controller to be unboxed and installed in a stand alone system without the need to install software from a development computer.

 

This is one of those things that sort of bridges between a hardware and software request.

gsussman

Add a version number to RT EXE files

Status: New
by Active Participant gsussman on ‎02-10-2010 11:16 AM

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.

 

Intaris

Allow ip address sharing within a project

Status: New
by Trusted Enthusiast on ‎05-02-2013 06:33 AM

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

 

Shane.

Mads

Format and install OS on target from LabVIEW project

Status: New
by Active Participant Mads on ‎12-18-2012 03:19 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.

Mads

Make it possible to change IP configuration on the fly

Status: New
by Active Participant Mads on ‎04-12-2012 04:22 AM

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.

QFang

SFTP support for Real Time Targets?

Status: New
by Active Participant QFang on ‎02-19-2013 09:11 AM

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!? :smileywink: :smileylol:

 

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

dwisti

Setting the time and date with MAX

Status: Completed
by Member dwisti on ‎03-09-2010 08:42 AM
Allow MAX to set the time and date to RT targets
Status: Completed
BSI

Sleep Mode/ low power mode for RT Controllers

Status: New
by Member BSI on ‎05-24-2013 09:05 PM

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

 

Thx.

L.

 

 

 

 

 

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!
Idea Statuses
Top Kudoed Authors