LabVIEW Real-Time Idea Exchange

Hello,

It would be nice to add a filename Check in the Crio executable process generation, in order to detect accentuated characters !

When you use accentuated file names, the generated Crio Linux executable does not work ... it crashes without any message !!! => NI Linux does not support accentuated file names !!!

=> The problem is that the Debug mode works fine, and doesn't work like the executable !

It should be nice to add a file name verification to the generation processus in order to highlight the problem .

Thank for your help.

Manu.

View All (3)

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

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.

View All (13)

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.

View All (7)

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.

View All (1)

Every Fixed-Point number allocates 64 bits (8 bytes) or 72 bits (9 bytes) if you include an overflow status. Working on a cRIO project that I need to acquire and save a large amount of data to process later when the RT CPU has free time to do it (is not acquiring more data nor transmitting data). Since the data is acquired in 12 channels, 51.2 kS/s, with 24 bit each point, the fixed-point allocates 64 bits but uses only 24, wasting 5 bytes (62,5%) for every single data point acquired.

As a workaround, I developed two VIs one to compact the data removing the 5 unused bytes of every Fixed-Point, number keeping the 3 bytes with the data. The second VI does the reverse job. With this I reduced the information to 37,5% of the original, saving space and time to save the information in non volatile memory. Maybe there's a way to do it directly, but I didn't figure it out.

My idea is to add, in some way, the possibility to use the minimum amount of bytes needed by the data, at least for storage purposes. It would be nice if NI add an option to have fixed point in two memory allocation modes:

Standard: the current way with 64 or 72 bits (probably faster)
Packed: the number of bytes allocated will be the minimum to hold all information. For a 16 bits data the each data will use only 2 bytes.

View All (3)

View All (2)

It would be nice if LabVIEW RT could give more output during the startup process of a LabVIEW real-time executable. For example if the rtexe is started at all or not, if there are missing dependencies during the loading process or other usable stats.

In my case I had problems with the German codepage. The build process was done without failure. But the rtexe didn’t start at all. I used special German characters like “öäü” in some VI names. And the rtexe couldn’t be loaded for that reason. But I didn’t get any message.

So please improve the debug output for LabVIEW RT.

View All (1)

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.

Hello,

It should be nice to create a low level CAN toolkit which could create or parse the 64 data bits of a CAN frame, without having to use the existing heavy tools.

What i would like to see is a list of low level VI's like readBoolean, readInteger, readFloat, readSingle ... writeBoolean, writeInteger ... with direct handling of the data coding (Intel / motorola)

These VI's could read/write channels directly to the 64 data bits of the frame.

These VI's are not very difficult to build ... and everyone who has already use the frame API, without DBC or NCD has done this work before.

My need is to create an official, validated list of low level channel read/write ... without having to use the channel API or CAN engine which ar not very powerfull.

For example :

ReadInteger ( in data, in startBit, in integerLength, in coding(Intel/motorola) , out integerValue )

ReadUInteger ( in data , in startBit, in integerLength, in coding(Intel/motorola) , out UIntegerValue )

readBoolean

ReadFloatCodedInteger( ........ offset, gain )

readFloat

ReadSingle

...

write....

When you speak with NI CAN users they all say ... NI CAN is too slow ... I think that this toolkit could help many CAN users to come back to NI CAN.

The top would be to create, using this low level API and a little bit scripting, a wizzard which could generate automaticaly the read and write VIs for selected frames of a DBC/NCD file. ( A frame = 1 read VI, One write VI and 1 cluster per frame containing the channels )

The generated result could be something like a polymorphic VI.

Manu.net

View All (1)

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

CRIO executable CRASH when using accentuated VIs or type file names ...

Allow the deploy libraries method to work in RT OS

Allow Dynamically Launched VIs to be marked as "Always Deploy"

sb-cFP

Make the AVI functions available at the RIO (RT) level

Visual Studio 2010 Support

SDXC card support for cRIO 9031 Linux Real Time

Seamless and integrated 'Remote Panels' for RT run-time applications.

Distributed System Manager Display Cluster Values

Make Auto-Assigned Names in Multiple Variable Editor Zero-Indexed

Build deployed RT Scan Engine IOV (Variable.XML) Parser and Editor into MAX or other standalone utility

Connect to FTP server option under Utilities

Support for OPC UA NodeSet files

Fixed-Point With Variable Memory Allocation

Getting the BIOS Version programmatically

LabVIEW RT - Improved Debug Output

enhance access security

Edit Unknown Files Through WIF

Windows 7 64-bit Driver for Reliance File System

CAN low level Toolkit ...