LabVIEW Real-Time Idea Exchange

Post an idea

Update the CMake version in OPKG

right now version 3.10 of CMake is available in the OPKG, but some libraries need CMake 3.12 or higher to build. The current version of CMake is 3.21

The way to update CMake is to follow this short tutorial

1. Make sure you have you device prepped with the following commands:

opkg install packagegroup-core-buildessential
opkg install cmake
opkg install openssl-dev

2. After this we're going to download the latest version of cmake from their download page: https://cmake.org/download/

Select the Unix/Linux source and copy the url

3. Create a build folder on your home directory and move into that folder to download the cmake source and unpack it there

mkdir build
cd build
wget https://github.com/Kitware/CMake/releases/download/v3.21.1/cmake-3.21.1.tar.gz
tar -xf cmake-3.21.1.tar.gz

4. Go into the source folder and run the bootstrap file

cd cmake-3.21.1
./bootstrap

5. After completion you can run make

make

6. After compiling you can install it

make install

7. Check the correct version by executing

cmake -version

A recent forum post discussed possibilities for "Securing a cRIO": Securing CompactRIO, and identified that LabVIEW project access allows the project to upload new rtexes without a password.

You are then prompted for a password to reset the cRIO, but this can be somewhat similarly achieved with a screwdriver and the reset button... (of course, this assumes physical access to the cRIO, whereas project access does not - but I suspect in the forum users' case, the two were approximately equivalent).

Would it be possible to move the login prompt before the new rtexe and accompanying files are uploaded, rather than for the restart?

View All (4)

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.

If you right-click on the RT target in the project and select Utilities you can:

-View in system manager

-View in browser

-etc...

It would be useful to have a View in FTP Client there as well. I seldom need to access the web interface, but I often want to delete files prior to a new deployment e.g. and this would be a quick way to do it.

Yes, you can use the web interface to access the files as well, but that's much more cumbersome than to just open an ftp connection.

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)

When creating an image of an RT target e.g. we currently rely on it to be able to store a temporary copy of the image prior to transfering it to the host PC. This can often cause the operation to fail (especially now that system images are way bigger than before) because the target does not have sufficient storage. If you have an application/config that is large too and you want that included in the image this requirement can mess thing up too.

This could have been avoided by streaming the image data to the host instead, with little or no intermediate storage.

Add ability to monitor network usage

View All (7)

Support for OPC UA NodeSet files

View All (1)

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)

CAN low level Toolkit ...

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)

Reboot RT into Safe Mode from MAX

Make Redis available via opkg

View All (1)

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)

LabVIEW Real-Time Idea Exchange

Update the CMake version in OPKG

Require password to upload RT application rather than to restart

Support newer hardware devices for ETS Real-time targets using Desktop PC

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

Don't Break VIs with Menu Reference Wires

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

Fixed-Point With Variable Memory Allocation

Getting the BIOS Version programmatically

Streaming image data (Image creation without the need for space for a local copy)

Add ability to monitor network usage

SDXC card support for cRIO 9031 Linux Real Time

Support for OPC UA NodeSet files

LabVIEW RT - Improved Debug Output

Windows 7 64-bit Driver for Reliance File System

CAN low level Toolkit ...

Reboot RT into Safe Mode from MAX

Make Redis available via opkg

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