LV Alpha - Interface with the Wolfram Alpha Computational Knowledge Engine through the cloud

[Darin.K]

First Round:

Summary:

This example shows how to interface with the Wolfram Alpha Computational Knowledge Engine, a relatively new and extremely interesting tool.  The capabilities go far beyond a simple Google search, as the tool tries to interpret the meaning behind the query.  Using this tool you can add power to LV applications, including symbolic differentiation and integration, and access to a growing number of curated data sources (weather, financial, astronomical,...).

Function:

The "real" uses of the Alpha Engine would be the automatic generation of queries and parsing of results to be used in your LV application.  For this example I have simply created an interface which lets you enter a query and view the results as images as well as text.  The images are mostly "eye candy" so I have used .NET functions to convert the GIF files returned from Alpha to the more LV friendly PNG format.  An all-native version requires GIF conversion code which would overshadow the main code, but an excellent source for Mac users is this post.  The main functions of submitting a query and retrieving the results is all done using data sockets.  The API returns an XML document which is parsed using a variety of simple XPath expressions.  If you use XML and are unfamiliar with XPath, I suggest you do something about it, and a good beginning reference is here.

Second Round:

Summary:

For the second round I have unleashed LabVIEW over the internet using cloud storage.  Utilizing a .NET FileSystemWatcher and my DropBox account LabVIEW can perform numerous tasks no matter where I am, or what type of machine I am using (Mac, PC, iPad).  The server code I use is PC only since it uses .NET functionality, but I can interact with this PC from any device with DropBox access. The Round 2 code utilizes some of the usual VI to VI communication methods (normal and single-element queues and user events) to implement a different form of communication which I call "file to VI" for lack of a better term.  The server is minimized to the system tray during normal operation.

Function:

In my world, LabVIEW does not exist in a vacuum and must interact with numerous different programs (graphics converters, LaTeX, Mathematica...).  Inevitably I never have all of the code I need on all of the machines I use.  Enter FolderWatch combined with DropBox.  My FolderWatch program will monitor a directory on my machine (typically a directory of my DropBox) and will fire events when files are created, changed, renamed, deleted, etc.  Plugins can register for these events and spring into action when called upon.  For example, the plugin I have included will convert GIF files dropped in the 'Pictures' subfolder into a PNG file in the 'Converted' subfolder.  So, a client can drop a GIF file into the proper directory in my DropBox, and the plugin automatically creates the PNG file back in my DropBox.  If the client machine also runs FolderWatch, it can catch the creation of the new file to know when the operation is complete.  Otherwise, DropBox can provide notification.

This functionality is incorporated into LValpha via the code which converts the downloaded GIF file to a LV friendly PNG file.  Instead of doing the conversion directly, now I place the file into a watched folder, wait for the plugin to convert it, then retrieve the new PNG file.  In this example, the same FolderWatch server provides both the GIF file creation event and the PNG file completion, but the extension to multiple computers is very easy.  Run FolderWatch on two different machines with access to your DropBox, disable plugins on the client machine (right-click the icon in the system tray), and that's it.

The FolderWatch architecture while in its infancy (about two days old now), is very extensible.  To create a new plugin create a new VI from the template in the Plugins folder, modify the Event Filter control to match the file type you are going to operate on, and add the action to the proper location in the consumer loop of the VI.  Save with the new code and default values to the Plugins folder and that is it.

Different machines can have different plugins, just try to make sure that there is no conflicts (same plugin on multiple machines, or fighting over a given file).  As I improve things I'll add more complex error checking, but for now I am trying to keep it as simple as I can.  (That is codespeak for I have two kids and very little free time!)

VI to VI communication:

The main communication scheme is using files placed in specified locations, but behind the scenes are many other communication techniques.  As you may know, .NET events require callback VIs which are called when the event occurs.  I handle these by making very simple callbacks, I pass them a user event reference and the callback VI fires the event with the event data.  Now I can register for these events in an event structure and handle the .NET events like any other event.  The FolderWatch Main.vi is responsible for handling these events.

To handle the one-to-many communication of the file changing events from the FolderWatch Main.vi to the unknown plugins I use a combination of queues and user events.   To register for events from the server, a VI simply obtains the queue with two user event refnums, one for a file change event, and one for a server shutdown event.  The plugin's job is to respond to its chosen events, and close when the server is stopped.

Some VIs need to know which folder is being watched, this is communicated via a single element queue, a more powerful global variable.  A VI can obtain the queue which only contains the current watched path, if it doesn't exist you know the server is running.  If it does exist simply preview the queue (do not dequeue!) and you have the path.  This way plugins can always deal with relative paths and not have to find the watched folder.

Steps to execute code:

1. Download the software and extract the VIs to a folder on your computer.
2. Run FolderWatch Main.vi, you will be prompted for a folder to watch, you can use the included 'TestWatch' folder for testing without a DropBox.  A cloud storage location, or networked drive is only required for communication to multiple computers, all testing can be done locally.  If you hit the Close button, the window is minimized to the system tray, you will see the spiffy icon with a startup message when you run.  Right-click to change options or open the front panel of one of the listed plugins.
3. Run LValpha.vi, the first time you run this code it will ask for your AppID, simply press the button to go to the website to register for a free AppID.  Enter this value in the box and you are set, the value is stored in an .ini file.
4. Enter a search query, such as 'd/dx sin(x)' or 'National Instruments' or 'weather in Austin TX' and view the results.  For more examples, see here.
5. Use the pulldown menu to select the type of result you are interested in.
6. Images which appear are being converted via the GIF to PNG converter plugin, see details in the NewImageFromURL.vi subvi.
7. If you get tired of balloon popups you have the option to right-click the icon in the system tray to show or disable notifications
8. Double-click the FolderWatch icon to open the front panel and see an activity log
9. To Bypass LValpha and the registration just run the 'ImageFromURL.vi' in the Test Task1 folder, this will download and display the NI logo from the Web using FolderWatch, just make sure FolderWatch Main.vi is running.

Screenshots:

Main Front Panel:

Startup of FolderWatch, right-click the system tray icon for options, double-click to open the front panel.

Image on right shows a plugin notification, disable if you get tired of these

Main Block Diagram:

Simple Producer-Consumer Architecture

VI Snippet:

Simple VI which does the query formatting, note the [text] at the end of the URL, very important.

Future functionality:

This example may be a bit contrived for a simple conversion which can easily be done in LV directly, but it shows the power and flexibility of this architecture.  I have other plugins to do tasks such as convert a VI to a PDF report (I can then download and view vis from my iPad).  Another plugin will extract code from a snippet and downconvert to an earlier version.  This way, if I am working in LV9 on a machine and see a snippet on the forum in LV10 I do not have to open LV10, extract, and save for previous.  Instead I download the file to a folder in my DropBox, the plugin on my home computer springs into action, places the converted file back in my DropBox and in a few seconds I have a usable snippet.  Endless possibilities.

VI attached below

Round 1: LV Alpha_2009.zip

Round 2: LValpha Round2_LV9.zip

[G-Money]

Nice architecture! Could have used more documentation but I figured it out after 30 minutes of going through the code.