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

Currently, on the cRIO-903x series controllers, the Chassis Temperature and the USER1 push button are only available on the FPGA http://digital.ni.com/public.nsf/allkb/75E039282A8B691886257E450049C7B6 and require the chassis to operate in a Hybrid Mode in order to use both the Scan interface and those chassis I/O options.

 

The cRIO-902x series allowed for both of these I/O options to be accessed in the real-time OS directly. This small feature would add convenience on the cRIO-903x series controllers.

0 Kudos

I think it would be a solid improvement in LabVIEW if the real-time development module and other modules available to the Windows OS are available to the Mac OS.

 

Some of these modules that are needed are the real time development module, vision development module and CVI.

 

Thanks 

The SVE on a windows based platform acts as a OPC-DA server. Due to the requirements for DCOM, this is not possible on real-time target. However, as OPC-UA is gaining traction, I would find it very useful to have the SVE act as an OPC-UA server for integration with 3rd party systems (SCADA, IIoT).

 

I know that there is the OPC-UA API palette, however, this takes more time to setup than creating a shared variable (i.e. a tag) and moving on with the application development. If update rates are slow enough (500-1000ms), I have found the shared variable to be more than adequate for my applications (500-800 NSVs), so I'm not looking for granular control over how I send data out of the cRIO system. Ease of use is my primary concern.

Currently viewing, testing or configuring NI-9862 Modules in a cRIO using NI-MAX needs a lot of effort. It requires:

- Installation of the complete Labview Realtime and FPGA development suite on the connected PC

- Setting up a Labview project including the NI-9862 Modules and an empty FPGA VI

- Compiling the emty FPGA VI to a FPGA bitmap file

- Starting the FPGA VI

Without these steps the NI-9862 Modules are invisible in NI-MAX

 

Proposed improvement:

- NI-MAX should include a default FPGA bitmap file that includes the communication with NI-9862 modules

- When the user connects to the cRIO with NI-MAX, the current cRIO configuation should be automatically saved to a backup and the default bitmap file should be activated

- When the user disconnects, the backup should be restored

 

Advantage:

- viewing, testing or configuring NI-9862 Modules in a cRIO could be possible just by starting the NI-MAX and connecting to the cRIO, as simple as with any standard I/O modules.

Currently a VI running in a Real Time environment does not support run time menus.  I understand the restriction, but what I find odd is VIs that have the menu reference wire cannot compile for RT targets.  This may seem like no big deal, because why would you have a menu reference wire, but not use it?  But I have come to find two examples that make RT code a bit more difficult due to this issue.

 

If I have a polymorphic VI, and one of the polymorphic types has a menu reference terminal, then I can't use that polymorphic VI in an RT VI, even if the instance that is being used doesn't use the menu reference.  One work around for this is to wrap the entire VI that does use the menu reference (terminals and all) in a conditional disable structure so that it does nothing on RT.

 

Another issue comes in the form of templates.  I have various temples to get code started, and most of it can run on RT or other targets without any need to change the code, just place conditional disable structures where needed.  But I found one issue where I can't have an event structure on RT, that has the Shortcut Menu Activation? event, because it generates a menu reference wire. Ideally this event just can't be generated on RT, so the compiler would know to not include it, and it would allow the VI to run on RT.  Same for polymorphic VIs that have a menu reference in one of its instances.

 

A better solution might be to lift all restrictions of using the menu reference wire on RT, and just assume that using the menu reference on RT does nothing, like a No-Op.  Optionally an error could be generated if one of the menu reference functions are used, but for the sake of simplicity I'm not sure that is needed.  What I'm really looking for, is a way to allow VIs to run on RT, that have menu reference wires types, but aren't used.  Note the VI below which can't run on RT and the reason given is that the menu reference can't be used on RT, but it isn't being used, it is just wired to a disabled case.

 

0 Kudos

The RAD tool is not a perfect fit for all cRIO deployments.  If you are unable to use the RAD utility to deploy a new version of drivers to the cRIO the process to get the Network Variable Engine onto the cRIO goes something like this:  Install LabVIEW and LabVIEW Real-Time, install NI CompactRIO drivers, install NVE and other driver software to the cRIO and then uninstall the LabVIEW components from the host PC.  This assumes that an executable will be installed to the host computer as the UI to the cRIO.  Seems like a lot of work for something most people would be using on the majority of cRIO deployments and might assume is a part of the CompactRIO drivers.

 

At the very least it would be great if the documentation found on the website were explicit as to what software needs to be installed for each of the install options available to install on to the cRIO.

0 Kudos

When using the "Open FPGA VI Reference" function you can configure it to reference the FPGA build/bitfile in three different ways:

- Build specification

- VI

- Bitfile

 

In development mode I often use "Build spec", for deployment I switch to "Bitfile". When using this function it behaves different, depending in which mode it is configured! This makes for a bad "User eXperience"…

 

In "Build spec" mode:

- when double clicking the pink border of the function it opens the referenced FPGA VI

- you need to right-click the "Open FPGA VI reference" and select "Configure…" to open the configuration dialog

- when selecting the "Build Spec" radio button it opens a selection dialog (probably a listbox) but you can't double click the build spec you want to use, you need to select the build spec and then click on "OK" button

 

In "Bitfile" mode:

- when double clicking the pink border of the function it opens the configuration dialog, (you don't need to right-click the "Open FPGA VI reference" and select "Configure…" to open the configuration dialog)

- when selecting the "Bitfile" radio button it opens a file dialog and but you can double click the bitfile you want to use

 

(All this relates to LabVIEW2014SP1. Haven't tested this with LabVIEW2015 so far.)

 

I propose the idea to make this behaviour consistent, independent of the selected mode in the configuration dialog!

 

I wish this behaviour:

- double click on pink border of the functions opens the configuration dialog

- double click on the FPGA VI icon shown inside the "Open FPGA VI reference" function opens the FPGA VI

- double click on an item in the "Build spec" selection dialog selects the build spec

0 Kudos

Hola que tal

 

Propongo se actualice el vi "RT Ping Controllers" para  las últimas versiones de Labview, funciona muy bien en aplicaciones HOST que comunican a CRIO por ejemplo, he utilizado este  vi de la versión  8.6, sin embargo no sé hasta que versión pueda ser soportada.

 

Saludos. JZR

0 Kudos

Has anyone ported a real-time VI originally targetted to cFP to install on cRIO?

I have an older control program, main VI and subVIs built in LV 8.6 and run on a compact FieldPoint controller.

I would like to be able to use much of it on a cRIO-9036 or something similar.

I am wondering whether LabVIEW (2015 or so) will do the work for me.

 

Thanks in advance.

0 Kudos

Hi everyone , thanks for your time .

 

I have a text file with a table of data (text file example attached) , this file will be increasing with time , perhaps 500 lines per year , i want to read this file from labview and to be able to search a name (first field of the text file) and the data in the same line belongs to that name  , the idea is to read line by line and if the first field matches the name searched , then get all the data in that line as a string , the data types don't matter .

As well i have to be able to delete a complete line of the same text file if the name matches the one searched .

Any idea will be agreat , Thank you very much for your help and time !

 

0 Kudos

The cRIO9031 with Linux Real Time did not support SDXC cards. Only SDGC with a maximum of 32GB supported by cRIO.

For logging application their is a need for more than 32GB => use of SDXC cards with 128/256 GB

 

0 Kudos

Hello LabVIEW Users.

 

My name is Eisuke Ono, An Application Engineer at NI Japan.

 

One of our customer is requesting a function.

 

The function is to retrieve information of module fault from C Series I/O variable Node (Scan Interface).

 

I know that we can get the information of module fault through FPGA I/O node, but not through Scan Inteface mode.

 

The customer's application is embedded condition monitoring system. It runs 24/7.

 

So it is very convenient if he get information of module fault C Series I/O variable Node Error Output.

 

I agree his opinion.

 

What do you think?

 

Bestr regards.

Eisuke Ono

 

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

At my company for all of our real time work, we are starting to use Veristand a lot. It is great that there are so many already available primitives on the Veristand palette within labview which are very useful. However, there is currently no Veristand primitive in Labview, that actually starts the Veristand.exe program itself. You have to use the System Exec to do it. I think adding a Veristand primitive that performs this function would be great.

Thanks....  

0 Kudos

hello;

 

For the NI 6008 card sampling frequency equal to 10 kS / s and it has 8 analog inputs, but if I will use the 8 analog inputs simultaneously, what is the value of the new échantionnage frequency for each input analog obtained during an acquisition in labview?

To allow expansion of DAQ capabilities from a real time PXI Rack it would be nice to be able to add a Compact DAQ chassis to the ethernet port and address it like you can on a desktop. I understand this is possible for USB connected chassis but not ethernet. 

 

This would allow an existing RT DAQ system to be easily expanded, or to acquire data from remote points without the necessity of wiring every channel back to the main rack.

Many of the features that are not supported on LinuxRT are things that one would expect not to work (due to the underlying technologies), but why no menu and cursor functions? 

 

The lack of menu support in particular means that most GUIs have to be customized to run on the target....even though Xfce should be perfectly capable of handling them in their original design... I was really hoping we could port some of our GUIs straight to the embedded GUI and replace our  industrial computers immediately with cRIOs...(the differences in appearances are easier to handle, after all we use system controls and take cross-platform variations into consideration already).

 

Now we'll have to (decide if we want to) spend time on customizing the GUIs.Smiley Sad

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

 

It would be good to enhance access security to also include program-control of cRIO's. As it is now you can set user access for a cRIO in a project by opening the Real-Time CompactRIO properties and set Allow/Deny access by IP. However, this only limits access to deploying settings and eventual RT applications on the cRIO. You can still control the cRIO (e.g. set outputs and, as in my case, control servo motor drives connected to the cRIO) from a LabVIEW application on any PC on the LAN.

This added access control could eventually be set up in MAX.