LabVIEW Real-Time Idea Exchange

Post an idea

It would be nice if attaching a thumbdrive to a cRIO / RT usb port triggered a "mounted" event or interrupt in the RT OS. Currently the only way to discover if a thumbdrive has been connected is to periodically run a file/folder info VI and see if one is present. It would be nicer if we could register a dynamic event and wait for it using an event structure, or similarily register for an interrupt event would work as well.

In my case, the use-scenario is a field maintenance person going out and manually plugging in a thumb-drive about once every 4 weeks to get the stored log files off of the controller. (No, we cannot use remote access in this case due to customer network restrictions.) So, in my case, I can easily use the polling solution, but if there is one thing I don't like to do, its to write polling code of any sort. It seems so wasteful. Other possible use cases could be to detect the presence of a thumb-drive and check for patch/updates, copy over new configuration files, etc.

Dual network interfaces is often part of the requirements for redundancy, however in such cases it is also very common to specify that the behaviour of borth of these should be identical. You see it in subsea control systems where they have an "A" and "B" channel, you see it topside where the device might need to be on two networks etc.

Unfortunately this is not the case for any of the dual port RT targets from NI. The secondary port is really a second class NIC. It has limited configuration options. It does not support DHCP, you cannot specify a gateway for it - and the code to do programmatic changes to its configuration is not easily available.

Please make the two ports fully interchangable. Port 1 or 2? It should not really matter which one you use.

View All (5)

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)

Streaming data is an important part for many applications. If the amount of data is very large, a RAID can improve system performance significantly.

Sadly, RAID is currently not supported for RT so Real Time Applications cannot use this valuable tool for enhancing streaming performance.

On Hypervisor systems, RAIDs can be used, but data has to be passed from the RT to Windows first. So streaming does not work like/with DMA but it uses CPU load which is in fact a waste of resources.

Norbert

View All (4)

At the moment Labview RT does not support high speed USB 2.0 (EHCI) functionality on PXI-8xxx controllers even if the controller has supporting hardware. We implemented a copy operation to transfer data files from a harddrive on the PXI chassis to an external USB connected flash drive using the copy VI, and only obtained speeds at USB 1.1 (OHCI) levels. We also tried a move version using the Move VI with similar results. The controller used in our tests was a PXI-8186, which has USB 2.0 ports.

My discussions with NI Support and the R&D team indicate this a limitation imposed by the ETS RTOS from Phar Lap that Labivew RT runs on. This is inline with the fact that VxWorks supported controllers have access to EHCI speeds as per this faq:

http://digital.ni.com/public.nsf/allkb/BE80D012BB933B54862572D6004FE5F9

Could we get high speed USB support implemented in Labview RT/ETS?

Here are some benchmarks that we obtained:

	Size (kB)	Time	MB/sec
Laptop to USB	55,535	14	3.97
Labview Copy VI Laptop to USB	55,535	14	3.97
Laptop FTP to RT	55,535	17	3.27
Labview Copy VI RT to USB	55,535	73	0.76

View All (2)

I was replying to a message thread someone had about question marks showing up for the times in the I/O channels for a compact Fieldpoint system. While investigating, I notice on my system that I had timestamps for data that occurred later in the day than the current time. So I know those timestamps were from a day prior than the current day. Actually, the test stand had been idle for quite a few days, so I pretty much know those I/O channels had not been updated for a while. But I could not tell from the timestamp when exactly that data was from.

In the attached screenshot, the current time was about 1:44 pm. Some data shows it had just been timestampled. Some data was from 7am, other data from 2:19 pm or 4:19 pm. I know that that data had to have been from yesterday or older. The 7am could be from today or older, but there was no way to tell. Based on my usage of that test stand, I'm pretty sure all of that data is at least 3 days old, and perhaps 6 or 7 days old. That is okay and not a problem. But there is no way of knowing how old that data actually is based on this screenshot.

I think MAX should show the date as part of the timestamp when looking at the I/O data.

Message Edited by Ravens Fan on 10-20-2009 11:48 AM

Message Edited by Laura F. on 10-22-2009 01:32 PM

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

"USB mount" programatic event on RT

Dual ethernet ports should have identical features

USB Support for RT

CAN low level Toolkit ...

Add RAID support to LabVIEW Real Time

Improve performance of Copy/Move VIs in Labview RT on PXI-8xxx controllers

Getting the BIOS Version programmatically

Improve Distributed System Manager Hypertrend Cursors

Can MAX show date as well as time in the timestamp for I/O channels?