Tag Archives: programming

LabVIEW: Using the Mouse Scroll Wheel

Lately I’ve been doing a lot of work on a fairly complex LabVIEW application.   It utilizes a number of controls and indicators which have vertical scrollbars (e.g. text boxes and arrays).  This gives users access to a great deal of data without over-crowding the front panel.  Unfortunately, LabVIEW does not natively support scrolling via the mouse wheel.  Well, I happen to like the scroll wheel, and so do many of my users.  So this week I finally went online and found a fairly straight-forward means of implementing this functionality.  You don’t need any crazy DLL calls or APIs; LabVIEW’s “Input Device Control” palette offers this functionality (located under the “Connectivity” section).  I found this particular example very helpful.

I did run into one rather odd problem though.  On my computer, the “Scrolling” value I get using the “Acquire Input Data” block is differential, not absolute.  In other words, when I move the wheel one step, the value of “Scrolling” is 120.  If I scroll no further and poll again, “Scrolling” is back to 0.  However, on the second computer I used to test this function, I received an absolute value.  In other words, if I move the wheel one step, the value of “Scrolling” is 120, but then it remains at 120 until I move the wheel again.  For instance, if I move the wheel by one additional step, “Scrolling” is now 240; the overall value is cumulative (an absolute position).

To combat this problem, I came up with a fairly simple (but not exactly elegant) algorithm that attempts to detect the mouse type based on the first few values of “Scrolling.”  If the absolute value of this parameter ever exceeds 3000, we assume the mouse is of the “absolute” variety.  Otherwise, if we’ve seen this value change more than 10 times without exceeding 3000, we assume it is of the “incremental” variety.  Until these 10 changes are seen, all scroll input is ignored.  This can be a bit frustrating, since the first time a user attempts to scroll something, they’ll have to move the wheel for a second or two before the GUI responds.  However, in the case of my application, I then store the mouse type in the registry, so that the next time the program is launched, the scroll wheel is immediately functional.  No big deal.  If anyone out there has better ideas though, feel free to let me know!

Anyway, you can click on the block diagram below to get a larger view of a quick demo application I built.  This demo shows how you might use the scroll wheel to control text boxes, arrays, sliders, and even graph axis scaling.  You can also download the example ZIP file below.  Feel free to leave comments or questions below.  Thanks!

LabVIEW Scroll Wheel Example - Block Diagram

LabVIEW Scroll Wheel Example - Front Panel

Download: scrollwheel_example.zip (85KB)

LabVIEW: Storing Diverse Data

Well it’s hard for me to believe, but I’ve now been using National Instruments LabVIEW for six years.  I started off with LabVIEW v7.1 and have used every version since (it’s now called LabVIEW 2010).  So I’m definitely a fan.  And yet, I’m still discovering new and more useful features on a fairly routine basis.

Just the other day I was looking for a convenient means to save a ton of front panel control values to a file (to allow the user to save their current program setup for later use).  In the past, when saving program settings, I’ve used the Configuration File VIs, which make saving simple parameters very easy and neat (think header-based *.ini files).  However, in this case I needed to save an obscenely large quantity of very variable data (numerics, strings, booleans, arrays, clusters, clusters of arrays, arrays of clusters, etc…).  After a bit of Googling I found my answer, the magical Datalog VIs (located on the Programming → File I/O → Adv File Funcs → Datalog palette):

The Datalog Palette

The Datalog VIs allow you to save clusters of any sort to a compact, record-based file.  Of course, you aren’t required to make use of the record functionality, you can just store everything in a single record and then recall that record later.  For instance, I packed the following mass of controls into a single datalog file with just a few simple blocks:

Datalog VIs In Action

Reading from a datalog file is just as simple, you need only swap in a read block in place of the write block.  Here’s a bit more on the Datalog blocks, taken from NI’s website:

A datalog file stores data as a sequence of identically structured records, similar to a spreadsheet, where each row represents a record. Each record in a datalog file must have the same data types associated with it. LabVIEW writes each record to the file as a cluster containing the data to store. However, the components of a datalog record can be any data type, which you determine when you create the file.

For example, you can create a datalog whose record data type is a cluster of a string and a number. Then, each record of the datalog is a cluster of a string and a number. However, the first record could be (“abc”,1), while the second record could be (“xyz”,7).

Using datalog files requires little manipulation, which makes writing and reading much faster. It also simplifies data retrieval because you can read the original blocks of data back as a record without having to read all records that precede it in the file. Random access is fast and easy with datalog files because all you need to access the record is the record number. LabVIEW sequentially assigns the record number to each record when it creates the datalog file.

So there you have it!  If you’re looking for an easy way to store diverse data, the Datalog VIs may be your answer.  Oh, and if you’ve got no clue what graphical programming with LabVIEW is all about, check out NI’s free 30-Day LabVIEW Trial.  The trial is full-featured; the only catch is a small watermark placed in the lower right-hand corner of your VIs.  But give it a shot!  It takes a little getting used to if you’re a die-hard C programmer, but once you understand the basics, you’ll be churning out sophisticated programs in a fraction of the time required to type code.