LabVIEW Idea Exchange

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?

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?

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?

Hello,

It should be nice to improve the standard LabVIEW TCP/IP VI library in order to include a way to test if data can be read on a connection.

=> Data available VI ... something like ByteAtPort for serial interface.

Having such a VI could help to create TCP/IP applications without having to hang and wait for timeouts !

Thanks.

Manu.

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?

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?

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 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?

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.