LabVIEW Idea Exchange

I think it is very difficult to make a UI that runs on Windows and interacts with targets. Here are two suggestions to improve this:

1. We currently can't have \c\ format style in a file path control on windows. It would be nice to allow user to specify the OS syntax to use instead of assuming it should always be the local sytax.

2. The icing on the cake would be to have the File Path Control support a property node for an IP Address so when the user clicks on the browse button, it automatically browses the target (this is already an idea mentioned in the link below) and uses the syntax of the target. This becomes especially useful as we start to have targets that may have an alternative way of browsing files besides FTP. It would be a pain to figure out which SW is installed on the target and use the correct method to enumerate files/folders.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Path-control-of-VI-under-real-time-target-should-brows...

These two features could be implemented by having an enum property node for the File Path Control called Syntax which include options like: Local, Various OSes (Windows, Linux, Mac, etc), or IP Address. If IP Address is specified, another property Node called IP Address will be used to determine what target's OS to use (if it's not specified or invalid, we default to Local).

According to the increasing number of questions about this communication protocol, it would be time to rewrite the MODBUS library. I also suggest to add it to the NI device drivers installer.

This could be the place to list the expected modifications. Some comments and bugs are already listed in above linked page.

The recently introduced Raspberry Pi is a 32 bit ARM based microcontroller board that is very popular. It would be great if we could programme it in LabVIEW. This product could leverage off the already available LabVIEW Embedded for ARM and the LabVIEW Microcontroller SDK (or other methods of getting LabVIEW to run on it).

The Raspberry Pi is a $35 (with Ethernet) credit card sized computer that is open hardware. The ARM chip is an Atmel ARM11 running at 700 MHz resulting in 875 MIPS of performance. By way of comparison, the current LabVIEW Embedded for ARM Tier 1 (out-of-the-box experience) boards have only 60 MIPS of processing power. So, about 15 times the processing power!

Wouldn’t it be great to programme the Raspberry Pi in LabVIEW?

taking ideas like that seen here  , I got this idea: 

When working with "Path Constant", which works with a path too long, we observe look like this:

Would be much nicer if we could double-click the “Path Constant” for us to see something like this:

The idea is this.

Hi Guys!

My idea is quite simple. What I would like to do is to use DAQmx Read and Write to accept a DVR as input so that I can read/write data directly to memory. This would be really appriciated if it could be applied on a TDMS read/write also (i know that there is a feature like this in TDMS now but it is only applicable on external dvrs).

Pros: Everything

Cons: None

Sincerely,

Andreas

I have used labview for a long time and avid user.  One issue I have been hitting lately is the "LabVIEW everywhere" slogan never really panned out, it has become LabVIEW everywhere NI allows it to be.  I am getting jealous of the Arduino and Rasberry Pi and hundreds of PICS and ARMs not avaliable to me (Yes I have the pro liscence but not embedded).  I wish Labview pro opened up the toolchain and started porting to many other platforms by default.  I am seeing jobs that labview is loosing ot to where it should be much more competetive like the embedded market. 

Essentially I am looking to see the Labview development environment easily work with toolchains for the most popular processors and also open up a simple standard to add targets to projects. 

Wouldnt it be nice to program a $25 ardunio dirrectly from labview (NO THIS IS NOT WHAT THE TOOLKIT IS DOING).  Add a Ardunio target file (maps the io memory to variables and throw down a loop, boolean shift register, a wait and a digital line variable, download to the micro and the blink led example is done.  Really open up the doors for LabVIEW everywhere.

The Arduino Due is a 32 bit ARM based microcontroller board that is destined to be very popular. It would be great if we could programme it in LabVIEW. This product could leverage off the already available LabVIEW Embedded for ARM and the LabVIEW Microcontroller SDK.

The Arduino Due is currently in developer trials and is due out later this year. It is expected to be about $50 and is open hardware. The ARM chip is an Atmel SAM3X8E ARM Cortex M3 running at 84 MHz resulting in 100 MIPS of performance. By way of comparison, the current LabVIEW Embedded for ARM Tier 1 (out-of-the-box experience) boards have only 60 MIPS of processing power.

The Arduino brand has an enormous following and Google has selected the Arduino Due for their recently introduced (28 June 2012) Accessory Development Kit for Android mobile phones and tablets (the ADK2012).

(By the way, the currently-available LabVIEW Arduino toolkit does not target the Arduino (and couldn’t since the Arduino Uno uses only an 8 bit microcontroller). Instead there is fixed C code running on the Arduino to transfer peripheral information to the serial port and back. That is, none of the LabVIEW target code executes on the Arduino. This idea is for LabVIEW code developed on a desktop to be transferred and execute on the target Arduino Due.)

Wouldn’t it be great to programme the Arduino Due in LabVIEW?

The BeagleBoard xM is a 32 bit ARM based microcontroller board that is very popular. It would be great if we could programme it in LabVIEW. This product could leverage off the already available LabVIEW Embedded for ARM and the LabVIEW Microcontroller SDK (or other methods of getting LabVIEW to run on it).

The BeagleBoard xM is $149 and is open hardware. The BeagleBoard xM uses an ARM Cortex A8 running at 1,000 MHz resulting in 2,000 MIPS of performance. By way of comparison, the current LabVIEW Embedded for ARM Tier 1 (out-of-the-box experience) boards have only 60 MIPS of processing power. So, about 33 times the processing power!

Wouldn’t it be great to programme the BeagleBoard xM in LabVIEW?

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 distribuute a lot of code, and sometimes it's difficult to tell my users what they need to install in order to run that code.  It would be nice if I (or a user) could run a built in LabVIEW utility that tells me what a given VI needs to run.

For example, do I need DAQmx, Mathscript, Robotics?

I’ve already put up ideas, about 7 weeks ago, for four development boards that could be LabVIEW targets:

1)  LabVIEW for Raspberry Pi (current kudos 139)

2)  LabVIEW for Arduino Due (current kudos 74)

3)  LabVIEW for BeagleBoard (current kudos 49)

4)  LabVIEW for LM3S9D96 Development Kit (current kudos 15)

I wanted to leave it at that to gauge LabVIEW community/user interest, however an exciting new board has just been introduced, which is too good to leave out. It’s the Texas Instruments Stellaris Launchpad.

It’s very attractive for three main reasons:

1)    It is very easy to get LabVIEW Embedded for ARM to target this board (a Tier 1 port)

2)    The microcontroller is powerful with many useful on-chip peripherals

3)    The price is extraordinarily low.

The Stellaris Launchpad features are:

• ARM Cortex M4 with floating point unit running at 80 MHz (100 MIPS)
• 256 KB flash
• 32 KB SRAM
• USB device port (separate from the USB for programming/debugging)
• 8 UARTS
• 4 I2C
• 4 SSI/SPI
• 12 x 12 bit A/D channels
• 2 analog comparators
• 16 digital comparators
• Up to 49 GPIO
• and more

The most interesting feature is that it costs $4.99 including postage. Yep, just under five dollars!  Including postage!  I’ve already ordered two!

The Texas Instruments Stellaris Launchpad can be programmed using the free Code Composer Studio in C/C++ or the free Arduino IDE using Energia from github. Both great ways to program. It just needs LabVIEW as the third exciting programming option.

Wouldn’t it be great to program the Stellaris Launchpad in LabVIEW?

The LM3S9D96 Development Kit is a 32 bit ARM based microcontroller board that is popular and has several plug in boards. It would be great if we could programme it in LabVIEW. This product could leverage off the already available LabVIEW Embedded for ARM and the LabVIEW Microcontroller SDK.

The LM3S9D96 Development Kit costs $425 and is open hardware. The LM3S9D96 is an ARM Cortex M3 running at 80 MHz resulting in 96 MIPS of performance. By way of comparison, the current LabVIEW Embedded for ARM Tier 1 (out-of-the-box experience) boards have only 60 MIPS of processing power.

The LM3S9B96 Development Kit brochure (http://www.ti.com/lit/ml/spmt158e/spmt158e.pdf) already states, “The LM3S9B96 development board is also a useful development vehicle for systems programmed using tools such as Microsoft’s .NET Micro Framework and Embedded LabView from National Instruments”. So, the brochure already states that the board can be programmed using LabVIEW. Unfortunately, this is not so - not without a few months work. No one has done the Tier 2 to Tier 1 port and it would make the most sense for National Instruments to do this once for the benefit of all. Relatively little work to enable this interesting development board. And the marketing is already done!

Wouldn’t it be great to programme the LM3S9D96 Development Kit in LabVIEW?

This is something a few power users have asked me about. There's no Instrument Driver or VIPM Idea Exchange, so I thought I would post it here.

What if VIPM could manage Instrument Drivers from IDNet?
There are a few key benefits this would offer us...

• download IDNet drivers directly from VIPM 
• track which version of a driver you are using for different projects and revert when necessary 
• wrap up ID dependencies in a VIPC file for use at a customer site

 

Currently the lvsound2 library -- the Sound Input and Sound Output VIs supported by lvsound2.llb and lvsound2.dll -- updates the audio device list from the operating system only when first being loaded into memory. If you change the device list (e.g.., pair/unpair a Bluetooth headset) the device IDs will not reflect the new configuration until all the lvsound2-dependent VIs have been unloaded from memory. After adding or removing a device, the VIs will generate error 4803 ("The sound driver or card does not support the desired operation.") for device IDs related to the new/removed device,  even if the ID is still actually valid and points to something else. This is extraordinarily inconvenient for test systems focused on audio device testing, but understandably a niche issue, which may be why it hasn't been caught before now.

In the interim, the workaround is to dynamically call any of the VIs you're interested in to force them to load/unload as necessary. There are two appropriate solutions I can think of:

1) Update the Sound X VIs to implement the dynamic call workaround (preferably directly around lvsound2.dll calls so we can still borrow other VIs in the LLB).

2) Update the DLL to support on-the-fly changes.

The latter solution is ideal, particularly for performance. This reads both as a suggestion and a bug report so that anyone else who has this problem can find a public forum documenting the issue.

Hi!

Since National Instruments offers support for programming ARM microcontrollers, I think it would be great to start supporting programming very popular recently BeagleBone development board made by Texas Instruments. You can find more information about this device there: http://beagleboard.org/bone . Please kudo it

If I "create constant" from a path input, and start typing into the path, the control grows to the left, away from the function that accepts it as an input.

But for VISA and IVI, the name controls grow to the right as you type into them, covering up the icon of the function that accepts the input, along with the wire connecting them.  Let's make VISA and IVI behave better.

Are we far from it?

http://www.youtube.com/watch?v=mnKBchs3j2M

http://www.youtube.com/watch?v=dDRFlBCrOIs