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
zyl7

Add console to Linux based cRIO

Status: New
by Active Participant zyl7 ‎06-03-2014 03:10 AM - edited ‎06-03-2014 03:23 AM

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' !! :smileyhappy:

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

 

 

0 Kudos
schddc

New LabWindows/CVI editor based on eclipse

Status: New
by Member schddc on ‎03-05-2014 07:52 AM

It seems making plugins to Visual Studio has been abandon but it wouldnt matter if we were able to use a modern and full featured IDE.  Use eclipse as a base IDE and develop features on top of it including the ability to downlod and execute code to real time targets.  Developing an IDE based on eclipse isnt unhead of this is vxworks does with wind river workbench.

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.

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

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!

At any one time, we have several complex LabVIEW-RT projects that run behavior experiments for us, taking multiple channels of analog and digital data while providing a complex series of audio and visual stimuli.  For each project, there is an RT part that "runs" the Experiment and a tailored Host part that runs the UI, handles an Excel Workbook that specifies the various trials being performed, displays the data, and saves the sampled results to disk.

 

Each of these projects are developed using LabVIEW Project, and each LV Project has its own, unique name.  When we build UI and RT executables, we would like an "automatic" way to associate them with each other.  A "natural" way would be to use the "shared" information of their joint Project.  There are ways to get the Project name in the Host UI code, both in Development mode and from an Executable.

 

I would like to propose that NI provide a Property or something similar for the RT side so that the RT code, at Run Time, could determine the Project from which it came.  With both sets of code knowing their shared "ancestor", they could use this information to ensure they are talking to their proper counterpart.  They could also use it to "mark" data structures (such as Files or Folders) that belong to them.  For example, there could be multiple configuration files, one for each Project, but they could be uniquely identified as "<Project> Config.xml" (where "<Project>" is the name of the Project containing the VI, allowing the appropriate Configuration file to unambiguously be chosen at Run Time).

 

Bob Schor

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?

0 Kudos
vaguy

rt strings

Status: New
by Member vaguy on ‎06-08-2013 06:45 PM

I would like a new string data type - a "rt string". There would be a property of the variable that would set the max. string size, and allocate memory at once for that size, similar to the way it would work in C. Additionally, there would be rt equivalents of most of the string functions, that would function just as in C, and would not result in memory allocations. This would allow (at least some!) string functionality in deterministic loops.

BSI

Sleep Mode/ low power mode for RT Controllers

Status: New
by Active Participant 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.

 

 

 

 

 

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.

0 Kudos
jgillerm

Support for OPC UA NodeSet files

Status: New
by Member jgillerm on ‎04-09-2013 01:26 PM

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.  

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.

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.

We use cRIO's in industrial deployments all the time.

While a lot can be done to work around the lack of security offered by the built in FTP server, it would be much preferred if NI would add FTPS (and possibly SFTP) support, or at the very least, modify the existing FTP server solution to expose/support the following functionality:

 

* define users (currently, only the "password" field is used by the cRIO FTP server, the user name is ignored (or limited to the "admin" name only).

* define folder access rules on a "by user" level

 

Ideally, the current FTP server would be expanded further to include:

* secured file transfers via built in FTPS support, (or by adding FTPS VI's to the existing FTP toolkit)

* (secure binary transfers via built in SFTP server)

* open up and/or document how the current web configuration tool does the HTTPS file transfer interface

 

Currently, there are no easy way to allow our end customers to securely pull data log files remotely, and no way to prevent end customer from accidentally accessing or modifying sensitive parts of the application. 

It would be possible to build a custom HTTPS file server on the cRIO, but I have several issues with this approach: it adds development and maintenance of another module to our code, it would most likely require another client side application for the customer to use, and most importantly: a lot of our customers have data collection servers set up to pull data over standard FTPS directly into their historians and their database systems.

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

Given a project topology like this:

 

Windows PC Host  <-> cRIO-9024 <-> NI-9114 backplane <-> NI-9144 EtherCAT #1 <-> NI-9144 EtherCAT #2   which is run in hybrid scan mode,   during development I wish that it were possible to, for example, tell the project to run without EtherCAT #2 being physically connected, instead using virtual/simulated IO. As things stand now, when I try to switch from Configuration to Active mode, I get an error saying that "the slave device cannot be found".

 

More generally, I often find myself thinking that the project explorer needs a good way to "comment out" various pieces of the project without having to resort to "Remove From Project".

Mads

Build on deploy, if necessary

Status: New
by Active Participant Mads on ‎12-18-2012 03:25 AM

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

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.

Hello,

 

I have recently to work with a RT application.

 

In this application, i used a property node in order to get all values of an ENUM.

 

 

=> This feature works fine when you debug your application using LabVIEW on the host ! :smileywink:

 

=> But the same code doesn't work in real RT execution. :smileysad:

 

I know very well that some property nodes doesn't work in RT programming, but when you have to go from windows application, to FPGA, to Crio, ... you often forgot this point ! LabVIEW should help us to limit this kind of mistakes !

 

It would be nice, if LabVIEW could break RT VI's, or generate a list of warning during RT application build, when an application is using non RT compatible property nodes !

 

It would be nice to get this warning during the compilation time, and not only at runtime ! 

It would also be nice, if the LabView RT debug tool could generates the same errors than a real RT target.

 

Thanks for help.

 

Manu.net

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