Home Community Idea Exchange LabVIEW Real-Time Ideas : New Ideas

LabVIEW Real-Time Idea Exchange

Community Browser
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Post an idea
8 Kudos
chyparo

USB Support for RT

Status: New Submitted by Member on 01-09-2011 07:01 AM 3 Comment

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. 

View All (5)
1 Kudos
ErnieH

Real time display

Status: New Submitted by Active Participant on 12-17-2010 07:31 AM 2 Comment

Ability to create a GUI (with touchscreens) using the graphics capability on desktop PC's. Maybe something like PEG (portable embedded GUI). For small testers, I don't necessarily want a PC or touchscreen PC running CE or XPE. The PC's involve a lot of setup, virus concerns, etc that I don't need on some testers. Support would be much easier also. Plus, in a lot of organizations, they don't understand the difference between PC's for desktops and PC's for production stands. You end up getting a "standard" PC with a lot of restrictions on it that requires several different groups to support when it fails.

2 Kudos
Logan_H.

Real-Time Clock configuration in Measurement & Automation Explorer

Status: New Submitted by on 12-15-2010 11:50 AM 1 Comment

A number of times, I have found the Real-Time Clock configuration screen in Measurement & Automation Explorer to be very limited. With only the options to set the Time-Zone/Daylight Savings Time/UTC, I feel like there could and should be more!

 

Adding a feedback to show what the current RTC is set to similar to the Windows Clock configuration would be GREAT! Additionally, add the functionality of the RT Set Date/Time VI to Measurement & Automation Explorer.

 

We frequently run into issues where the Daylight Saving Time value is different between the US and the rest of the world (frequently=twice a year).

 

I believe all of this can be resolved by adding 1 layer of abstraction to translate a base RT system clock to the user-specified specifications to be added to timestamp data, schedule tasks, and so-forth.

 

View All (7)
1 Kudos
herbrand

Support events for graphic objects in RT target VIs

Status: New Submitted by Member on 12-06-2010 07:34 AM 4 Comment

If you use a VI to control a RT target via Web browser then only polling is possible to register user actions. Since: "RT targets support the Event Structure only with dynamic events." (LabVIEW Help 2010) You can program such graphic object events but they doesn't work.

 

The support of graphical object events would improve the capabilities for applications with cRIO and sbRIO without a LabVIEW-Host.

Labels:
View All (6)
2 Kudos
westgate

Filesystem Rights in Web-based configuration and monitoring

Status: New Submitted by Member on 11-22-2010 08:31 AM Comment

Hello,

 

it would be very nice if i could give users in the Web-based configuration more specialized filesystems rights.

In the moment i only can give the user the right to write on the whole filesystem or on nothing.

In my case i would like to sent our customers updates of the startup.exe, which they can install their self via ftp. Without them having access to everything on the filesystem.

Please vote if you would like to have this option,

Cu

Westgate

 

 

3 Kudos
manu.NET

CAN low level Toolkit ...

Status: New Submitted by Active Participant on 11-09-2010 08:07 AM 3 Comment

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)
17 Kudos
Norbert_B

Add RAID support to LabVIEW Real Time

Status: New Submitted by Proven Zealot on 10-19-2010 02:11 AM 1 Comment

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)
10 Kudos
DiscoBall

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

Status: New Submitted by on 10-13-2010 04:30 PM 1 Comment

I frequently use the RT Debug String VI to add useful comments about the health of my application. Sometimes, I believe it would be nice to indicator error/danger conditions with a different color of text.


Do you feel it would be useful to have the ability to change the color of the string? If so, vote me up.

1 Kudos
twopac

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

Status: New Submitted by Member on 09-09-2010 11:15 AM 9 Comment

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
5 Kudos
JoeC

Distributed System Manager Display Cluster Values

Status: New Submitted by Member on 08-12-2010 10:27 AM 4 Comment

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.

Labels:
29 Kudos
JackDunaway

Don't force a "Save All" prior to RT Deployment

Status: New Submitted by Trusted Enthusiast on 08-09-2010 12:29 PM 1 Comment

When running a VI in development mode while targeting an RT device, you must "Save All" prior to deployment. This is annoying, especially when using SCC. I'm sure that SourceOnly will minimize this effect in LV2010, but the concept still remains: I don't want to be forced to Save All when I don't want my edits (or automatic linking edits) to persist.

View All (3)
6 Kudos
cagell

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

Status: New Submitted by Member on 05-20-2010 05:10 PM 1 Comment

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)
13 Kudos
sgregor249

Get RT FIFO Status

Status: New Submitted by Member on 04-16-2010 08:04 AM Comment

Create an RT FIFO Primative similar to the Get Queue Status VI that returns the number of elements in the RT FIFO. Currently RT FIFO Read and RT FIFO Write return the number of elements in the RT FIFO, but calling these VIs will affect the contents of RT FIFO.

 

A workaround for this would be to maintain a count on a shift register and increment/decrement it each time the RT FIFO Write/RT FIFO Read VIs are called. This solution does not work when trying to monitor the size of an RT FIFO in a running VI in another VI that is used to detect memory leaks.

1 Kudos
dwisti

Get the VI Name in a subroutine

Status: New Submitted by Member on 04-08-2010 10:49 AM Comment
VI Server nodes are asynchronous nodes.  I would like to be able to get the VI Name in a subroutine.  This could be done now with an XNode. Or, it could be a compiler optimization.  Since VI Server nodes are a shared resource, they can cause a priority inversion.
11 Kudos
viScience

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

Status: New Submitted by Active Participant on 02-25-2010 02:37 PM Comment
Start including the Ethercat industrial communication drivers in the device driver DVD. 
6 Kudos
The_Seeker

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

Status: New Submitted by Member on 02-19-2010 02:46 PM 1 Comment

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.

 

 

 

 

 

8 Kudos
MathieuSteiner

Allow the deploy libraries method to work in RT OS

Status: New Submitted by Active Participant on 02-10-2010 09:49 AM 4 Comment

It would allow an RT executable to deploy shared variable automatically

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

4 Kudos
Manzolli

Fixed-Point With Variable Memory Allocation

Status: New Submitted by Active Participant on 02-09-2010 10:11 AM 3 Comment

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)
25 Kudos
swenp

Native XML support on Real-Time targets

Status: New Submitted by Member on 01-21-2010 04:19 AM 4 Comment

Wouldn't it be nice to have a native LabVIEW XML parser available on real-time targets? Storing your config data in XML rather than in Config-ini files is more flexible, techniques like XMLRPC would be easier to implement etc.
Yes I  know about the third party EasyXML library, but I don't want to spend extra money as we are already paying for LabVIEW 😉

2 Kudos
viScience

Allow RT Scan Engine Fault Events to optionally include string data

Status: New Submitted by Active Participant on 12-04-2009 12:57 PM 3 Comment

I understand that the FE vi's needed to be optimized for speed so that they could be put inline without disturbing RT timing.  But it would be nice to be able to send a string description

with the fault so that it would show up in the DSM.  An example would be a fault due to trying to send an invalid remote message.  It would be nice if the invalid message string could be logged with the fault event.

I think making it optional would still preserve the determinism when needed.