LabVIEW Real-Time Idea Exchange

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

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

 

 

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

We could solve a lot of our designs with sbRIO and LabVIEW RT if the sbRIOs' CAN interface was designed to be a slave, and there was a DS301 compliant CANOpen slave API available for LabVIEW RT.

 

I'm a bit surprised that only the master side is covered today, as I'm sure a lot of people will utilize sbRIOs in devices that are more natural to define as slaves, not masters.

 

Throw in a dual set of equivalent network interfaces and the sbRIO platform and RT is an ideal platform for subsea instrumentation, with SIIS Level 2 (CANOpen) and SIIS Level 3 (Ethernet) communication capabilities, at least as long as the power requirements are kept low.

The only functionality of RT USB is mass storage. It would be helpful to add at least RAW Data USB support to use USB port for connecting i.e. USB / RS232 adapter. Many analyzers use integrated serial/USB converter chips to transfer data to PC, because no need of specialized driver (you get the driver with the chip). The ability of RAW USB support allows to connect these analyzers to cRIOs and RT PC Targets. 

It would allow an RT executable to deploy shared variable automatically

(and not from the project explorer or the host computer as mentionned here)

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

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.

I think this would be a good option since I have run into the problem during debug where a previously used Network Stream did not get destroyed and then when the code tries to reopen the stream you get an error that the stream is still in use.  Since the refnum is lost there is no way around this dilemma.

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.

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.

 

 

 

 

 

At the moment, there is a small development problem with dynamically launched VIs (via the Asynchronous Call method). They are not recognised as dependencies during the deployment process, so the code can't be run effectively in development mode via the run arrow (those VI's will return File Not Found errors).


A simple fix for this would be to be able to mark VI's as "always deploy" in the project window.

I am using the AF-1501 Frame Grabber Module from MoviMED. Right now I am able to capture and store images in BMP and TIFF formats at the RT level but I would like to be able to create AVI videos at the RT level.

The idea is to be able to record videos and then store them (either in the internal memory of the RIO or in an SD card using the NI-9802). 

 

The problem is that the RT processor does not run windows and has no cocdecs. Therefore the AVI generation VI's from the vision palet do not work. Even if it is tight to a particular codec, it would be great to be able to create AVI's on the RT target.

 

 

The development environment for RT is really a great, integrated system. It's so convenient to develp on a regular PC and deploy the VIs for testing. The real-time UI feedback during development is a boon to productivity. It's difficult to imagine a useful RT workflow that doesn't include a live panel in the development mode -- it's an idea that is both powerful and intuitive.

 

What I would really like to see next is similar RT panel interactivity in a deployed run-time system.

 

At the moment, I am using a 'remote panels' implementation to stream an interactive panel view back to the PC. (I assume that this is similar to how things are managed by the development environment itself.) The problem with this approach is that the Remote Panels API seems a bit flakey at times. I don't always seem to get a reliable connection. What's worse is the programming overhead associated with setting up the remote panels connection, and the sometimes fickle behavior of Windows in allowing a remote PC to connect.

 

Since the RT development environment already has the capability of seamlessly displaying an interactive UI on the Windows client, would it be that difficult to add UI panel feedback into the run-time executable environment?

 

I realize that, at first glance, this may seem to defeat the whole purpose of an RT system. However, I have built a few different Vision RT systems over the last few years, and the same challenge always seems to come up in every project. When I need to implement a calibration, focus and/or alignment mode on the RT target, I find myself performing all kinds of contortions to retrofit a simple interactive RT utility for use in the deployable application.

 

If I could simply implement an RT VI that presents an interactive UI on the Windows client (just like when you are in the LV Development mode), perhaps I could eliminate the complexity of my current strategies: Either 1) developing an elaborate case structure and messaging system on both sides of the network connection to pass images and parameters across the network in real-time, or 2) implementing a (hit-or-miss) remote panel linkage to a self-contained RT configuration VI over a remote panel connection that isn't always as robust as I wish it would be.

 

If the heavy liting has already been done for the Development system, surely it wouldn't be too much of a stretch to enable similar functionality in the run-time environment..?

 

Anyway, that's my wish for today.

 

 

 

 

 

There are 2 LabVIEW libraries available to create HDF5 files, the problem is, there is no version of the HDF5 library available for NI Linux RT systems, so everyone that wants to use this, and doesn't have enough experience to build the HDF5 library on their own can't use this.

Could we have SSL on by default in the standard software sets for RT targets? It is not like there is much security in the default setup anyway, so having SSL active as well as the web interface with default passwords is just more practical (if that is the rationale for not having it on...(?)).

Background:
Whenever I have loaded a default software package onto an RT target using NI MAX, I run into this little snag; I try to log onto it using SFTP or PuttY - only to rediscover that this is disabled. So then I have to go to the web interface or NI MAX to enable it. Most of the time we use RAD to replicate PACs anyway, but this is still another little thing we have to remember every time when dealing with the very first setup.

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

In lack of a hardware idea exchange I'll post this here. I know composite ideas are not ideal either, but my main point is to voice the wish for a different kind of RT controller:

 

The "sb-cFP":

 

We basically use cFP-2220s as small, low power, rugged embedded computers in our systems. We've looked at sbRIOs, especially the newer ones like the 9606, but they do not have dual networking, nor the 4 in-built serial ports (yes you can use the mezzanine, but the power consumption, size etc. goes up). No FPGA is needed, nor any IO other than communication ports like Ethernet/Serial (USB and CANbus is nice though).

 

In an ideal world we would have a sbcFP version of the 2220, designed for embedded use, and at the price of a sbRIO withoyt an FPGA.Smiley Happy The only thing we would miss then is lower power consumption. The cFP-2220 is specified to use around 6W. In real stand-alone use it typically draws around 3.2W (other applications might push that though), but that's still a lot for many types of embedded use.

 

Underclocking

Perhaps underclocking could be a solution to lower the power consumption of NIs controllers, when customers need a less power consuming device? Imagine beeing able to adjust this dynamically from the System Configuration API / NI MAX...An sb-cFP with 1-2W consumption would remove any reason to abandon LabVIEW RT and NI-hardware in favour of controllers running micro-linux e.g.

 

Similar to NI's Visual Studio 2008 support, it would be great if NI installed the Visual Studio 2010 run time to the Real-Time target and supported it officially with tools such as the DLL checker.

 

I know that currently, I can statically link in the 2010 run time to my built libraries if I want to run them on RT... but it would be nice to not have to. This would also enable products like LabVIEW Simulation Interface Toolkit and NI VeriStand to officially claim 2010 support on their readme's... as by default the make files used by these NI products do not statitcally link in the run time and I have to hack the make file to enable support.

The Distributed System Manager does not allow one to see the values for a cluster in a deployed process.  It would be nice to view and edit values in the cluster.