LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Idea Exchange for NXG!

NXG needs an Idea Exchange. The feedback button is a lame excuse for a replacement. Why?

I can't tell if my idea has been suggested before. (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
Many ideas start out as unfocused concepts that are honed razor sharp by the community.
This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

View All (2)

For ethernet and GPIB communication I have the choice between the LabVIEW "native" drivers (residing in function palettes "Instrument I/O" and "Data Communication") and VISA. LabVIEW 6.1 was the latest version which also supports "native" drivers for serial interface. In LabVIEW 7.0 and later you are forced to use VISA.

Besides all advantages of VISA - the biggest disadvantage of it is its HUGE communication overhead it produces. If you use interface sniffer like PortMon, you will see that VISA heavily communicates with the interface chip (requesting its status etc.). So for sending a simple "Hello" over RS232 you don't have only four actions (configure port, open port, sending "Hello", close port), but ten and more.

As consequence VISA often lockes out if you have heavy traffic on your serial interface (e.g. if you have to send data every 250ms over the interface) - and if VISA lockes out, you have a serious problem...

So PLEASE, give us the native driver for serial interfaces back!

I know this is another Raspberry Pi idea, but hopefully the answer is simpler than some of the past requests (maybe as simple as "no"). I am wondering if it would be possible to run a simple labVIEW executable on a Raspberry Pi with the sole purpose of viewing network published shared variables. This could provide a low cost UI terminal for distributed hardware. My hope is that the required drivers are minimal in that only a network connection is required and no hardware drivers for the NI products would be required. Basically, it would be similar to the data dash board app but would allow much more customization by the developer for software based analysis and display.

View All (3)

How is NI-MAX still so bad after all these years? It goes completely unresponsive and crashes at the slightest provocation. This feels like it should be NI's bread-and-butter.

Every LabVIEW team ends up recreating so much of the functionality that NI-MAX is supposed to offer out of the box. Maybe with the discontinuation of NXG, some resources should be allocated to making this product usable.

KB articles like this and this probably shouldn't need to exist.

View All (3)

XNet Log to TDMS (similar to DAQmx)

What I propose is to have functionality built into the XNet API that is similar to the DAQmx API. I'd want a separate subpalette where functions like Start, and Stop logging can be invoked which will log the raw data from an XNet interface into a TDMS file. Maybe even some other functions like forcing a new file, or forcing a new file after the current file is so old, or of a certain file size. On buses that are heavily loaded, reading every frame, and then logging it can be use a non-trivial amount of resources, and having this built into the API would likely be more efficient.

XNet already has a standard for how to read and write raw frames into a TDMS file that is compatible with DIAdem, and has several shipping examples with LabVIEW to log into this format.

XNet Hold Single Point Property

When performing a single point read on an XNet session, you will receive the value of the signal that was last read, or the Default value as defined by the database if it has never been read.

This type of functionality is sometimes useful, but more often I'm interesting in knowing what the last reading was, if the reading is relatively recent. The problem with the NI implementation is that you have no way of knowing (with this one session type) if the device is still broadcasting data or not. I think a useful property might be to have a way of specifying an amount of time, that a signal's value is still valid. If I haven't seen an update to a signal in 2 seconds for example, I can likely assume my device is no longer communicating and the reading I get back from the XNet read should return NaN.

I had a small discussion on this topic and posted a solution using an XY session type here, which demonstrates the functionality I am talking about. I'd like this to be built into the API.

One of my planned projects is to write home automation software for my new house. I already have three iPads installed in the wall (kitchen, theatre and upstairs), all my awning windows are motorised, I have a solar powered hydronic in-slab heating system that needs the right type of control, earth tubes, a whole-house fan, solar chimneys, many other passive climate control features and plenty of data cabling throughout the house. User interface access would also be via iPhone, which I carry in my pocket at all times, and mobile iPads.

The intention is to automate the house for climate control, lighting, theatre control, security, monitoring electricity usage, monitoring phone costs, controlling the hot water system, seeing who’s at the front door and letting them in (even if I'm not home), setting up a in-house phone/intercom system, limiting phone use, changing TV channels, looking at weather forecasts for activating systems in anticipation of tomorrow’s weather, remotely viewing the inside of the house, and plenty more. You could call it a life-long project!

I’d like to use LabVIEW for programming since it’s the most fun language I know. The only problem is that when it comes to easily programming a great user interface, I can’t find the way.

1) Data Dashboard for LabVIEW is too limiting with only 6 indicators and no controls (and needs work at the iPad end?)

2) Web UI builder is way too expensive (I need a free solution) and cumbersome

What’s also important is that different rooms can have different user interfaces. Perhaps each can reflect the front panel of a sub-VI.

There are plenty of examples on the web of great looking Home Automation iPad user interfaces. Apart form the example shown above, http://a2.mzstatic.com/us/r1000/089/Purple/v4/d9/23/ec/d923ec9c-0a31-6a62-cb7c-e74a4f8feecc/mzl.uayvvtoo.480x480-75.jpg looks good. Such great user interfaces and there is no way (or I don’t know how) to make them happen using LabVIEW.

This may not need to be a product development, per se, but may actually just turn out to be a step by step set of instructions on how to achieve the outcome using existing tools and an example application. Given what I imagine as a wide appeal for such a LabVIEW user interface, I think it’s worth the effort and could be used for many other application such as process control.

The basic criteria are:

1) Must work with iPhone, iPad (and Android devices)

2) All programming at the desktop (I don’t want to stand in front of multiple iPads setting them up/updating)

3) User interfaces must look as good as the examples on the web (and sampled here)

4) No additional cost

Wouldn’t it be great to have a LabVIEW based Home Automation user interface that is versatile, easy to use and free?

View All (1)

Currently the only way to set/modify Tcp socket options is by directly calling some system library, as done for example in this post.

This not only causes code difficult to understand ("what does that library call do again?") but also poses problems when you want to use your code on different operating systems: Currently the only way to do this is using "conditional disable structures", and then Labview still tries to load the code used for a different operating system...

Labview should have a standard way to set socket options within Labview code, at least for the most important options (Nagle algorithm leaps to mind...). This could either be done as additional inputs to the "Tcp open connection"-VI, or (much better) using property nodes for Tcp connections.

View All (1)

I posted this in the discussion forums here, but after forming my thoughts, I realize that it is really a suggestion for product improvement, so I'm cross posting here.

In short, I would like the ADCS toolkit to use Frame In/Out Queue Sessions instead of Frame In/Out Stream Sessions when running on XNET hardware (or at least make that an option). This would enable the separate use of a Frame In Stream Session to log all of the CAN traffic on a port.

This was recently made possible for the ECU M&C toolkit in version 2.3, and I think the same concept should be extended to the ADCS toolkit.

A cursory test of ADCS 1.1.1 suggests that this may already be an undocumented feature of the toolkit, but there are some subtle bugs that may need to be worked out for this to be fully supported.

Data Dashboard Direction

Data Dashboard for LabVIEW (https://decibel.ni.com/content/docs/DOC-19387 ) is an exciting and interesting product. I like the idea of using my iPad or iPhone to interface to my LabVIEW application remotely. Of course, the Android platform is also catered for. It’s early days for Data Dashboard, but it is currently very limiting with just 6 indicators for tablet devices and 1 indicator for phone devices and no controls. So, Data Dashboard has a long way to go. The images presented here is the capability I’d like to see from Data Dashboard for LabVIEW.

Wouldn’t it be great to have a remote LabVIEW user interface that looks like the images here?

View All (2)

Labview embedded everywhere

Would like to target Labview embedded on a host of platforms. Specifically x86, lynuxworks, Vxworks and xilinx platforms - boards, SBCs, COMs, stacks, PC/104... Like PXI, the way to get the users onboard is to show that the industry supports this direction and you are not tied to one vendor. It would be expensive if in an iterative learning process (necessary but collaboration is also necessary with well established & matured platforms/standards) the users one chosen platform vanishes (maybe like fieldpoint?). Packaging options is also very important to achieve something like Adlink's MilSystem 800 that the application demands.

Pavan Bathla

View All (5)

View All (1)

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 (2)

Packed project libraries are new with LV 2010 and seem to be a great way to share code. One idea to make them more user friendly for the end user of the library would be something that would give the project library developer the ability to specify driver dependencies for their library.

If the end user of the library did not have the right drivers installed, they would receive a warning or maybe a broken run arrow if they tried to use it. The warning could be very descriptive by telling them exactly what drivers they are missing. This seems like a better solution that just getting all these arbitrary errors because LabVIEW can't find subvis called by the packed project library.

Here's a mockup of what the window for this might look like in the packed project library build specifications (borrowed from the additional installers window).

Allow Custom Properties for VISA

So one can set many of the standard properties for VISA connections. However the serial port latency setting is not one of these. It can easily be set by a standard POSIX ioctl call for both linux and MacOS (who the heck knows how Windows does it). Many character based devices can be manipulated through these ioctl calls.

To be specific, the FTDI USB-Serial port driver chips used in MANY devices as a USB interface or just as a serial port have a slow default latency that is fine for preserving CPU cycles but not great for modern high speed custom communication.

1. Just add a a property that sets the serial port latency using an ioctl IOSSDATALAT property configuration.

2. More generally allow an interface that will call ioctl with a supplied property and the LV programmer can pass the correct property configuration.

3. Less satisfying but possibly easier to implement is to have the VISA property be the file descriptor number. This simplifies the programming where one has to now get the "Name" property and then search the process information table for that "Name" (or really path) and then extract the file descriptor. Only then can one set the latency for that device.

LabVIEW Idea Exchange

Proper Smith Chart

Idea Exchange for NXG!

Native drivers for serial interface (RS232 etc.)

Develop software to allow porting of LabVIEW executables to Raspberry Pi to enable reading and graphical display of Network Published Shared Variables

Byte at port or Data available for TCP/IP VIs library ...

Ground-up rewrite of NI-MAX so that it is actually usable

XNet Log to TDMS (similar to DAQmx)

XNet Hold Single Point Property

LabVIEW Home Automation User Interface

Add better support for Tcp socket options

Use Frame Sessions for Automotive Diagnostic Command Set (ADCS) on XNET hardware

Data Dashboard Direction

Labview embedded everywhere

Allow VISA to have a separate read and write timeout

Improvements to the "NI Update Service" (shut down the system, when you finish the download.)

Card specific DAQmx/LabVIEW Property Nodes

LabVIEW RT - Improved Debug Output

Driver Dependencies for Packed Project Libraries

Allow Custom Properties for VISA

PPL for multiple target