LabVIEW Real-Time Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

I use "Set System Image" to set an image on freshly manufactured units. Every now and then, the imaging process fails for one reason or another (possibly a hardware/networking failure). I know that the image process in my case usually takes about 4 minutes. Unfortunately when the imaging process fails, there's no way for the application to gracefully stop "Set System Image". The only option is to wait a really long time or use the task manager to force-quit the application. The abort button on the VI doesn't work

 

So, I'd like one of two things. Either, an input so I can adjust the timeout based on my application or some way to let "Set System Image" know that the application would like to stop if possible (maybe nothing had been written yet). For example, it could take in a DVR and the application could feed it a "true".

System Image Escape.png

64bit has been the dominant architecture for a decade; any computer with more than ~2.5GB of RAM must use it after all. It is inevitable that 32-bit machines will cease to be made - maybe not tomorrow, but let's be realistic. Let's get ahead of the times and convert modules to support 64 bit support. Please!

 

 

It is really useful to be able to edit text files through the web based file explorer.

 

As it stands only certain file extensions are editable. (.conf, .txt, .ini). It would be great if all files were editable by default to handle custom extensions used on our applications.

We have the ability to get memory usage and cpu use. I'd also like to also monitor network usage to see if my application is getting close to the point where it would have to either buffer or drop messages.

The Set System Image VI (and by extension, the Replication and Deployment Tool) have a deployment blacklist. Currently, files on that list are never deployed. It would be helpful if instead, those files, if they exist in the image, were deployed only if they do not already exist on the target. That would make it easier to create a single image that could be used for both an upgrade, where you do not want to overwrite existing configuration files, and for initial setup, where you want to install a default configuration file.

 

Did I misunderstand something about the way the deployment blacklist works? The documentation says "Files on the blacklist will not be copied from the image to the target" which makes me wonder why you would ever want to include those files in the image at all.

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.

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.

 

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.

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

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.

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

 

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

 

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

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.

Many measurement and process control application run at relatively slow rates (<100Hz). Using SCAN Engine on the CompacRIO for data acquisition is ideal for these applications because you don't need to program the FPGA and all the measurement and control logic can be implemented on the Real-Time controller.

 

 

In many cases you want to process your data before you analize it. Currently you only have the ability to get the raw measurement data from the AI modules, so you need to add the data processing code to your existing LabVIEW program. It would be helpful if the SCAN engine could offload some of the data processing (ex. lowpass filter or sample average) to the FPGA and provide the user with already processed data. For example, this functionality can be added to the module configuration page:

 

SCAN Engine.png   

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