LabVIEW Real-Time Idea Exchange

Post an idea

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.

As far as I know, a thumb-drive or hdd that you connect to a cRIO USB port has to be formated using FAT. It would be very handy if NI would support attaching drives formated with the Reliance NITRO file-format. This could in some cases also lessen the pain of being stuck with Reliance (old version) on the cRIO main drive. It would also ensure deterministic file IO on the USB drives in case of power failure, un-expected device disconnection etc.

Thanks for reading and hope for your vote!

QFang

View All (1)

View All (4)

The best thing about Pharlap is that it will run dll's like Windows.

Making shared libraries for VxWorks (*.out files) is quite an arduous process if you don't have Wind River software. The GNU toolchain, that used to be the free alternative, does not work on Windows Vista or 7, leaving those of use who have chosen to upgrade out of luck.

It would be great is LabVIEW could provide a way to compile *.out files from the Application Builder and thereby provide more complete support for development on the CompactRIO platform.

View All (4)

Currently many controllers from NI only have one way to deal with a failure to contact a DHCP server - they will try to use a link local address (APIPA). If this too fails (due to Proxy ARP e.g.) the controller will not even start the RT Application (which might have other tasks to do regardless of the lack of netorking and/or might run code that will remedy the IP problem), but go into Safe Mode. This in itself is bad enough and should be changed to allow the application to be run, however the main request / idea I have will fix this indirectly:

- It should be an option to not fall back to APIPA, but to use the last known configuration (as long as the lease time is still valid). If the DHCP server is down the controller will have the IP-configuration it received the last time the server was up, and will use that configuration.

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.

I know there has been some discussion in other areas about an "Android build" of LabVIEW, but I am thinking specifically about the Touch Panel Module. An option to target and deploy an HMI onto a low-cost, readily available Android tablet would be tremendous for RT projects, in my opinion. I've got 2 different projects right now that require expensive Win7 tablet PCs, but all they are doing is running a custom LV application to be used as a basic HMI, which is complete overkill. I know the webserver is an option, but it has some limits, and I'd like to have multiple varieties of HMIs available to show varying degrees of system data and performance, which gets dicey with a webserver situation (at least, in my experiences so far).

It just seems like expanding the TPM so that it's keeping up with the times (Android and iOS dominance) seems like a win/win for NI and developers.

View All (3)

View All (4)

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.

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.

View All (4)

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.

View All (5)

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.

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Real-Time Idea Exchange

Support for menu and cursor functions on embedded GUI (Xfce)

Allow USB hard-drive or stick to be formated with Reliance NITRO instead of FAT

Add Reliance NITRO to the list of supported file systems

Allow RT FIFOs to be of type LV Class

Support for Building VxWorks Shared Libraries (*.out files)

Fallback to last known IP if DHCP fails

Start including the Ethercat industrial communication drivers in the device driver DVD.

CAN slave interface - with CANOpen Slave API

Add ability to change text color on the RT Debug String VI

RT target with C-module in Scan Engine mode to include hi & low pass filters as property by default

Android target option for TPM

Allow RT FIFOs to be of type LV Class

Add LabVIEW UNZIP to the RT target

Allow ip address sharing within a project

Allow Shared Variable Engine on RT target to act as OPC-UA server

Don't Break VIs with Menu Reference Wires

Add ability to monitor network usage

USB Support for RT

Sleep Mode/ low power mode for RT Controllers

Allow Create Network Stream to reopen a existing reference.