Custom Controls

Custom buttons in a user interface can make the interface more appealing and easier to navigate. They generally don't require much effort as long as you have reasonable image editing software.

First pick the image you wish to use for the button (This one is courtesy of the gnome user interface and comes under the GNU license be careful with licensing) and ensure it is the required size. This will be the off state image.

Make sure the background is set to be transparent, then save the image as a PNG.

Next copy the image and edit the copy, Create a new layer identical to the bottom layer directly over the top. Fill the top layer foreground with an on/off colour and then blend the images together.

This image will be the on state for the button.

In LabVIEW drop a classic square flat button and right click advanced customize.

In the control front panel click on the spanner to change it to tweezers, then right click on the image import from file and choose your off state image.

Right click the control and select copy the to clipboard.

Right click the control select picture item then the third picture, right click and select import from clipboard. The image is now complete in the off state.

Repeat the process for picture item 2 and 4 with the on state image.

Click the tweezers to switch back to control mode and the custom button is finished.

ni.com/community

I've recently come across a few features on the NI website, that can all be found at ni.com/community. If you look at the right-hand side of the community webpage, there are a list of really useful links which I’ll summarise here:

1) Blogs
Here you can browse through all the blogs hosted on the NI webpage. Our LabVIEW Downunder blog has a place mark here, we’re just yet to figure out the best way of linking it to our google blog.

2) LabVIEW Ideas
This is like a suggestion box for LabVIEW. So, every time you think “wouldn’t it be great if LabVIEW could......”, just go to the LabVIEW ideas and type it in! People who like your idea will give it “kudos”, and those ideas with the most kudos end up as a high priority enhancements for the NI R&D Team. Examples that have made it into LV already are the ability to delete an object from wires and auto-reconnect the wires, and the new and improved icon editor.

3) Discussion Forums
This is where you can chat with others about specific NI questions or problems. Often, this is a great way to get support as it is monitored by lots more people, many of whom are NI employees!

4) Example Code
Got a case of “Blank VI Syndrome”? head to the example code section to see if someone has written something similar. This is a great way to get started on a project or code module quickly and save development time. You can search for specific topics or browse by product, manufacturer, application area, Industry and more.

5) Tutorials
Learn about a wide variety of topics such as issues you may face when upgrading existing code to LV 2009 (http://decibel.ni.com/content/docs/DOC-6141), How to use VI scripting (http://decibel.ni.com/content/docs/DOC-4973), and even how to interface to your Wii with LabVIEW (http://decibel.ni.com/content/docs/DOC-1353)!

6) Groups
Join groups so you can get the latest info from engineers tackling similar problems to you.

Happy Learning,

Porting DAQmx Task Configurations

Ever wondered what's the best way to port DAQmx task and channel configurations from one PC to another with minimal fuss? It is a problem we are faced as intergrators every day - how do we make the application easy for our client to install and maintain well into the future? We always need to have some sort of hardware configuration in our applications, but is it best to:

a) store that configuration information as an extra file, or should it be

b) integrated into the software application to minimise the number of files required on each target PC, making the installation process quicker and simpler for the client?

I like the idea of option b, however it seems a lot more work and therefore cost to code the hardware configuration into LabVIEW, rather than simply exporting the Measurement and Automation Explorer (MAX) configuration file to the target machine.

Something I have been using for a long time, which seems to be a little known feature of LabVIEW, is automatic code generation for DAQmx tasks. This feature makes it a breeze to convert your MAX task configurations into code. Using this, you can easily deploy hardware configurations inside your executables, and it is simple to add or modify those configurations in LabVIEW later.

Here is the trick....

1) Create and configure your DAQmx task in MAX

2) In LabVIEW, place a DAQmx task name constant on your block diagram

3) Pull down on the task constant and select the saved MAX task (just as if you were going to use the saved MAX configuration to run the hardware I/O functionality)

4) Right-click the task constant and select "Generate Code".

Here you have a number of options, the most usefull of which are "Configuration" and "Configuration and Example". If you have blank VI the "Configuration and Example" option is gold, as it automatically generates your while loop, stop button, graph and all those other little VIs that I always forget to include when developing DAQmx code, such as start task and stop task. It also generates a subVI, inside of which you will find all of your task configuration code. once this subVI is built, you can forget about your MAX configuration files as all the configuration information is now in your code - brilliant!

If you have already written your data acquisition code, and simply need to generate your MAX configuration code, use the "Configuration" option. This will automagtically generate a neat little subVI with a task and error output.

Go on, give it a go!

Updating the User Interface

Have you ever had trouble updating a chart when using a slider to control the axis?

I have tried using event cases that run on:

• value change - updates but in a clunky manner
• mouse up - you don't always mouse up over the slide after dragging it
• drag end - does not update on the fly, so there is no feedback

The solution I have started using requires an event driven producer consumer. It was suggested to me by one of the LabVIEW architects at my company (CPE Systems)

The trick here is to enqueue the update case only if it is not already in the queue. If the case already exists in the queue nothing is added to the queue. When the consumer handles the case it takes the latest value from the slide itself. Providing smooth, live updates. This trick also works for other complicated user interface redraws.

Have you got any neat tricks you use to enhance the look or feel of your software?