Not looking at ActiveX and .Net since they both are Windows technologies only and are not really suited to integrate generic external code into LabVIEW, there remain two similar possibilities nowadays to integrate external code into LabVIEW. These are CINs and shared libraries through use of the Call Library Node. While CINs used to have certain advantages over shared libraries in the past this is basically since about LabVIEW 6 not true anymore and with LabVIEW 8.20 the Call Library Node got additional features that remove the last (esoteric) advantages CINs had over shared libraries. On the other side the use of shared libraries through the Call Library Node has quite a few advantages.

In this article I will try to compare the most important differences between these two thechnologies and try to make a point, why anyone should nowadays go for the Call Library Node with shared libraries instead of using CINs.

Let’s start with two features where CINs still had a slight advantage over shared libraries until the advent of LabVIEW 8.20. The previously mentioned “callback” functions introduced in LabVIEW 8.20 actually make the Call Library Node go on par with CINs in these aspects. I will investigate into the specifics of those callback functions in a later article in this series.

Advantages of CINs before LabVIEW 8.20

- Instance specific data storage

One advantage of CINs used to be the possibility of instance specific global data storage. If you don’t know what this could be and why you could use it, you most probably never will need it and you can skip this section.

Using the functions GetDSStorage() and SetDSStorage() one can use a single 4 byte location which LabVIEW manages on a per instance base. This means that unlike a global variable declared outside any function body in the CIN code, each instance of a CIN in a diagram using that particular CIN code resource gets its own 4 byte value, managed by LabVIEW. You could see this similar to an uninitialized shift register in a LabVIEW VI which has been set to be reentrant. While this feature could be powerful in some esoteric situations it is almost never used and its understanding is made even more complex by the fact that such a CIN located in a reentrant VI itself will actually maintain multiple instance specific data storages for each instance of that reentrant VI multiplied by the number of those CIN code resources located inside that VI. Once you continue this acrobatic brain exercise to include multiple levels of reentrant VIs, everything gets very soon very complicated for everybody not used to think in parallel realities in n-dimensional systems.

- More detailed control over initializing and unintializing of the code resource

While shared libraries only support initializing and unintializing of code on loading and unloading of the library through OS provided mechanisms such as DLLMain() in Windows or init() and fini() under ELF shared libraries, LabVIEW CINs separate these actions into load, init, uninit, and unload together with a save operation. The load and unload is called once for each CIN code resource and could be used to initialize and deallocate global data while the init and uninit is called once for each code resource instance and can be used to initialize and deallocate above mentioned instance specific data storage. The save routine doesn’t really make much sense for someone outside of NI as one needs to know about some undocumented parts in LabVIEW to properly make use of this.

Both these features are very rarely used and can be achieved through other means such as maintaining a pointer in the calling VI inside a shift register and passing this pointer to the function on every call or by using the platform specific shared library initialization and deinitialization methods in a smart way.

But shared libraries have a number of advantages which should make it easy for anybody to choose for them instead of trying to dig into the proprietary CIN technology.

Advantages of the use of the Call Library Node over CINs

- Parameter type support

With the new Adapt to Type parameter configuration since LabVIEW 5.1, a Call Library Node can pass any LabVIEW data type directly to a shared library without any translation or fiddling around. In this aspect the parameter support is now superior to CINs since the Call Library Function supports some additional configuration options as well, such as passing LabVIEW handles by reference whereas a CIN will always pass them by value. And the Call Library Node supports also other data types such as C string pointers or C arrays among others and LabVIEW will take care to pass the correct part of its own data type to the shared library so that the library can work on them with the standard C runtime routines. While it is not necessary to use these types for your own libraries it is an additional bonus which can sometimes be very handy.

- Accessing most shared libraries directly

With CINs you always have to write some intermediate C code to access already existing shared libraries. The Call Library Node can however interface with many shared libraries directly, making the creation of an intermediate wrapper DLL in many cases an optional step. This does not always work that way since LabVIEW arrays and strings are really dynamically resizeable while most standard C datatypes do not allow for easy dynamically resizable pointers. In a later article I will go into more depths about when you would need to create a wrapper for use with the Call Library Node, but in general many shared libraries can be interfaced directly without an intermediate wrapper shared library.

- Multiplattform support

With the current LabVIEW platforms there is no reason why maintaining a shared library source code for multiple platforms would be more difficult than doing the same for a CIN. On the other side if you take care to follow some recommendations in respect to calling and naming convention, mentioned in the next article, there is no reason why you would need one set of VIs for each platform you want to support. For CINs this is mandatory and can only be sort of circumvented with a technique invented by Christophe Salzmann which he called FatCIN. With this technique you create a VI for each platform you want to support and then you create another wrapper VI, which uses dynamic calls through VI server to load and execute the appropriate VI for the current platform. But this is a rather cumbersome technique as it will still require one VI for each platform for every CIN and an additional wrapper VI. Also the maintenance of the CIN VI itself will be cumbersome too since whenever you make a change to the CIN code no matter how small it is, you have to manually touch each platform VI to reload the new code resource.

- Multifunction support

If you happen to have a number of functions to support you can implement them all in a single shared library and create one VI for each function in that shared library. If you are using CINs instead, you either have to incorporate all the functions into a single CIN and create a CIN which takes a selector parameter for the function to execute. This VI also will require a more or less involved parameter list to support the most extended list of parameters of all the functions. Or you can create a CIN for each of those functions and wonder why a single change to some common parameter type will have you compile each of the source codes separately and then require you to go into each CIN (and in case of multiplatform support into each of those platform VIs too) and reload the code resource into the CIN. In the case of separate CINs for each function you also don’t have any means to store some global information inside the CIN to allow sharing that information among multiple functions.

For shared libraries you almost have to create a VI for each shared library function. But even when using the single CIN approach you still will also usually want to create one additional wrapper VI for every function selector value. This is because direct use of the single selector based CIN VI is not very user friendly. Imagine the many VI parameters on such a selector based CIN that will not have any effect for most of the selected functions.

- Compiler tools support

Shared libraries can be created in virtually any development environment which is able to create them. There is no need to use a specific C compiler unless you want to link with the labview.lib library to make use of the LabVIEW manager functions documented in the External Code Reference Manual. This limitation is because object libraries can come in a number of file formats and each compiler has its own preferred object file format and often no support for object file formats from other compilers. LabVIEW for Windows 32bit comes with a labview.lib file in COFF format which is the format used by Microsoft Visual C and a labview.sym.lib file in the OMF format used by the now discontinued Symantec C compiler. Borland C also uses some form of OMF format but it is not clear to me if the Symantec C provided library is compatible with any version of Borland C because object file formats can and will certainly come in various flavors.

As long as you do not want to link to labview.lib however there is really no limitation in what development environment you use to create a shared library, provided this development environment can create shared libraries usable by other development environments such as Visual Basic, Delphi or similar.

CINs on the other hand always will have to link to at least cin(.sym).lib and lvsb(.sym).lib and in most cases labview(.sym).lib too and therefore will always be limited to the LabVIEW supported compiler tool chains.

In fact Open source tool chains such as the GNU C Compiler can be used on all current platforms to create shared libraries callable by the Call Library Node, although for Windows I would recommend the use of some customized GNU tool chain such as the MingW compiler tool chain (http://www.mingw.org) possibly in connection with a development environment such as the Dev C++ application (http://www.bloodshed.net).

Conclusions

CINs should be considered legacy technology and should preferably not be used for new developments. CINs have basically not one single advantage anymore over the use of the Call Library Node but quite a few disadvantages, especially in terms of code maintenance both for the C code as well as for the LabVIEW part! This is already true since about LabVIEW 6.

To see where the future of CINs most probably will go you only have to investigate a current LabVIEW installation and try to find stock VIs, which still make use of CINs. They are virtually non-existent. National Instruments has ported all their LabVIEW interfaces such as NI-DAQ, NI-IMAQ, NI-CAN, etc and add-on tools like the Advanced Analysis library or IMAQ Vision to use shared libraries instead of CINs.

User interface may be the one most important part of your LabVIEW application. It’s the only part of the application the end-user is directly in contact with. Still user interface is often the part of a LabVIEW application developers spend the least time with in the development process. Does LabVIEW make creating decent user interfaces too easy to be ignored in the design phase?

User roles

Let’s concentrate on graphical user interfaces. What should a user interface design process be like? The user interface design shoud start with determinig the different user roles of your application. For example you may need to have a different kind of user interface for the end-users as you do for the administrators.

Views of your user interface

After you have indetified different user roles you should list the main tasks a users in different user roles uses your application. It’s important not to go into too much detail, just concentrate on the most important tasks. The number of main tasks depends on your application. Determine what kind of views do you need in your application to allow users to do these main taks you have identified. You may need multiple different views such as monitoring view and configuration view and visualization view. Depending on your application, these views may be separate parts of a single window, different states of a window or separate windows.

Paper mock-ups

Once you have determined the main views you’ll need in your application you should not hurry to your computer and start coding. Instead you should sit down, take you pen and paper and start drawing mock-ups of your user interface. A mock-up is a model of you user interface. With pen and paper it’s easy and fast to try different variations of component locations. Also the drawing process helps you to concentrate on the important parts and not to go into too much detail too soon. You identified different main tasks the users need to do with your application. Go trough these tasks with your paper mock-ups. If there are major state changes in your views, don’t spare the paper. Try to cover all important views of you application and all important states of different views. Play around, all time consumed in the paper user interface design phase is well spend.

Usability testing

Next you should grap a small group of potential users and show them the user interface mock-ups you have made. Users tend to think differently from what you expect so it’s important to get into direct contact with the potential users. Show them your user interface paper models and ask them to proceed with the important tasks. Don’t help them too much, let them figure out by them-selves what to do, which button to press. Simulate the user interface functionality by showing them different pieces of paper. Use your imagination to find a nice way to simulate your user interface without a computer. Again, don’t go into too much detail, concentrate on the most important parts. If your test users don’t behave the way you would expect them to, ask them what would be the intuitive way for them to proceed with the tasks.

Hand drawn paper user interface models are an excellent tool for the user testing. In computer graphics based user interface models, the tested users tend to concentrate too much on the details and on the lack of polishing. With hand drawn paper models it’s evident that they are only models and users don’t expect them to be polished. Instead they concentrate on the usability and that is exactly what you want to test with them.

Don’t be afraid with the user test phase. You can really often find suitable test persons from your work or from your friends. Testing your user interface doesn’t take a lot of time but you get plenty of valuable feedback. With this feedback you need to go back to your desk and start considering how to make your user interface better, how would it serve your users better.

Conclusions

User interface design is an iterative process. Depending on the complexity of your user interface you may need to iterate the process several times. Only after you are happy with your paper models, you should start working on real front panel implementations. There are many ways of designing user interfaces and this particular process I learnd from useability experts when working on a consumer product project.

Take a look at Jim Kring’s related post on Human Interface Guidelines on his blog Thinking in G.

Scala is my favorite non-visual or text-based programming language. Scala is a functional object-oriented programming language has succeeded to combine almost all features I’d like to see in a programming language except the visual way of coding. Scala compiles to Java Virtual Machine and is fully interoperable with Java code. There was a nice introductory article on Artima a few days ago First Steps to Scala by Bill Venners, Martin Odersky and Lex Spoon. If you are into text-based programming, you should seriously take a look at this article.

In my last virtualization article Streamlined Software Development with Virtualization I discussed about benefits of virtualization and virtual machines on software development process. In this article I present how to set up an excellent free PC virtualization software VMware server to Windows XP host computer and how to install Windows XP client system on it.

Setting up VMware Server

VMware Server is an excellent virtualization software for software development. It’s feature rich, easy to set up and completely free. VMware targets VMware Server for light duty server virtualization and targets non-free VMware Workstation for software developers. VMware Workstation should have some extra features but unless you really need these extra features there is not any need to pay for them.

VMware Server can be downloaded from product homepage. To install the product, you’ll need to gain serial numbers. The serial numbers can be requested from VMware for free by filling-up registration form. Installation of VMware is very straight forward. If you don’t have Microsoft web server IIS installed on your computer, the installer will complain of the lack of IIS. The IIS is only needed if you want to manage your virtual machines over the network and for local only installation you can safely ignore this complain and press Ok to continue.

Creating A New Virtual Machine

After you have installed VMware Server you need to create a new virtual machine. Virtual machine runs on top of host operating system. It uses a large file as file system image, shares the host computer keyboard, mouse, monitor and network connection. To create a new Windows XP virtual machine you’ll need a Windows XP installation CD and a Windows XP license.

Start VMware Server. From an appearing pop-up window select local host to indicate VMware Server that you want to manage the virtual machines on your local computer and not machines on the network. From File menu select New > Virtual Machine. A wizard will start that guides you trough the virtual machine set-up process. After few initial options the first real decision you need to make is to choose the network connection type. Bridged networking is probably the best choice. If you are in a network where each computer needs to be registered for the network, then NAT networking will be easier as you don’t need to register your virtual machine to the network.

The second important choice is selecting the disk capacity. Set the capacity as high as you think you ever may need in this virtual machine, the capacity cannot be increased later on. Uncheck Allocate all disk space now option to keep disk usage at minimum. The disk will be allocated as needed. Finally click Finish button. The virtual machine will be created.

After you have created your new virtual machine you still have to specify the resources it may consume. Click your virtual machine on the inventory unless it is already selected. On the right-hand pane of the VMware Server Window under Commands bar you should have an option link Edit virtual machine settings. Press this link to open the virtual machine settings window.

On the Hardware tab set memory to 512MB if you have 1GB or more of system memory to guarantee Windows XP to run smoothly on the virtual machine. Then click on the CD-ROM settings and turn on the Connect at power on option. This makes your CD/DVD-drive automatically visible to the virtual machine. You need your CD/DVD to be visible so that you can install operating system and software to the virtual machine.

Now we are ready with setting up VMware Server itself. Let’s continue to installing the operating system.

Installing Windows XP on Virtual Machine

Installing windows XP to virtual machine doesn’t much differ from installing Windows to any other computer. Insert the Windows XP installation CD to the CD-ROM drive of your computer. Make sure you have a valid license with a Windows XP serial available. If you have autorun enabled on your host computer, ignore the window that will pop-up.

Make sure you have selected the correct virtual machine from the inventory on VMware Server control panel. Now start your virtual machine by pressing the Start this virtual machine link on the VMware Server control panel. The Virtual Machine should now start up, then connect to your host computer CD-ROM drive and start the Windows XP installer on the CD. From now on the Windows XP installation will proceed as normally.

Installing VMware Tools

After Windows XP installation has finished, there is still one more task to do before you can start using your virtual machine as normally. The virtual machine runs on top of the host computer and the performance is not optimal. All the graphics, mouse movements and key presses are transferred between the host computer and the virtual machine. VMware Tools is a package that should be installed on the newly created virtual machine to improve the performance of the host computer – virtual machine link.

On Windows virtual machines the installation of VMware Tools is very straight forward. On linux virtual machines you will need to recompile your kernel. When virtual machine is turned on and you have logged into it with administrator privileges, select Install VMware Tools from VM menu of the VMware Server control window. This will mount a virtual CD image and if autorun is turned on, an VMware Tools installer will automatically start. If autorun is not turned on, you’ll need to start the installer manually from the CD-ROM drive of your virtual machine.

Conclusions

Congratulations, you’ve now installed VMware Server on Windows XP and installed another installation of Windows XP on the virtual machine. To install applications to virtual machine, simply insert installer CD:s to your host computer CD-ROM drive and you can directly access them from your virtual machine. You can mount CD-ROM images on your host computer to your virtual machine.

It wasn’t that difficult, was it? If you are interested in getting some deeper knowledge on any aspects of virtual machines, please let me know. I can consider writing further articles on using virtual machines on software development.

From the beginning the LabVIEW developers recognized the need for some form of node or interface to allow LabVIEW users linking in their own code that could be created outside of LabVIEW. The reasons wanting this can be varied. Someone might be interested to interface to an existing application or code library already developed and tested in order to leverage its functionality. Other reasons could be interfacing to third party drivers and libraries or that some optimized code needs to be executed for performance reasons.
This first installment about external code in LabVIEW will try to bring a historical overview about the possibilities to interface to external code in the different LabVIEW versions.

LabVIEW 2, MacOS only, external code resources

This version of LabVIEW did only run on Macintosh computers. In the Macintosh 68k OS, executable code was really just another resource inside the resource fork of the file among the other resources such as icons, images, menus, text strings etc. LabVIEW therefore used this technology to implement an external code interface. The compiled object code was added to the LabVIEW VI simply as a code resource in addition to the code resource created by LabVIEW from its diagram code. Whenever the VI got loaded into memory the compiled VI code resource and the additional external code resources were linked into the existing code base.

LabVIEW 3, CINs, complications and reasons

LabVIEW 3 (we leave out 2.5 as that was only really a 3.0 prerelease) was the first version to support other operating systems than Macintosh OS. It is not fully clear to me if shared library support was already standard in the Sun OS (later to be called Solaris 1) operating system at that time. The first versions of shared library support under Unix were however in general quite buggy and each Unix vendor had his own ideas about how it should work. The Macintosh OS also did not have a standard interface for shared libraries. One had to download an extension for this and the first version for shared library support was at some point discontinued and replaced by a different incompatible version. Here too were a number of nasty bugs present that got only slowly ironed out with new releases.
But the most difficult platform was the DLL interface for the Windows version. It had some serious troubles due to the fact that LabVIEW was a flat 32bit memory application built around a so called DOS memory extender. This DOS memory extender was delivered with the Watcom C development system and provided to applications a true 32bit environment while running on top of the old 16bit environment used in Windows 3.x. Any applications wanting to use that environment had to be compiled with Watcom C. This posed problems when wanting to call normal Windows DLLs, since they were really 16bit and the stack as well as pointers inside the 32bit environment had absolutely no meaning to a DLL running in the 16 bit environment. So when passing information between the 32bit LabVIEW application and the 16bit OS environment the entire parameter stack and any pointers had to be properly translated.
Interfacing to Windows DLLs directly would have meant to translate auto magically every single parameter between the 32bit LabVIEW environment and the 16 bit Windows memory model. For every single call a complete new stack frame needs to be allocated in the 16 bit environment, parameters need to be copied from the 32bit memory into the 16bit memory and for pointers additional translations need to be done to make the pointers valid in the 16bit environment. On return of the function these operations have to be reversed too. Watcom did provide some routines to deal with this translation, which basically was only possible by executing some involved assembly code internally, but the setup and configuration of those functions was a quite involved task. Therefore it was decided that this would be a to large development effort for an initial multi platform LabVIEW version. Instead the already existing idea of external code resources from the Macintosh OS was used and ported to the Windows and Sun OS. A Windows CIN back then was in fact a native Watcom REX object code file and a Macintosh OS CIN was a 68k object code file. The lvsbutil tool provided in the cintools directory wrapped this object code file into a CIN header and added the resulting file as another resource to the VI resources. This allowed LabVIEW to directly call the code resource in the same environment as LabVIEW itself was running, without involved memory translations that are difficult to handle automatically and also cause performance degradation. The disadvantage was that the Windows CINs only could be generated by the Watcom C compiler since they needed to be in the 32bit REX object format which no other compiler could generate.
I feel personally that the developers missed an opportunity here when they did not allow for multiple code resources being added for the same CIN. This made it necessary to manually load the correct platform specific code resource into the VI whenever a VI was moved between platforms. This deficiency was never fixed in later versions of LabVIEW and caused a significant loss of convenience in using CINs for multiplatform libraries.

LabVIEW 4, Shared library support

LabVIEW 4 added the Call Library Node to interface directly to external shared libraries (Macintosh Code Fragment Manager components which were not standard for non PowerMac computers, Unix shared libraries and Windows Dynamically Loaded Libraries)
Due to the limitations of the Macintosh Code Fragments and Windows 3.1 16 bit DLLs the supported data types were limited. For instance function return values other than void and numeric were not possible because of differences how Borland and Microsoft DLLs returned pointer types as function return values. More complex function parameters than string and arrays were also not possible because the parameters needed to be prepared accordingly for Windows 3.1 DLLs. To create an automatic thunking interface supporting more complex data types would have been a real nightmare to implement and therefore was left for a possible later version of LabVIEW. Because of the 32bit <-> 16bit translation in accessing external DLLs under Windows 3.1 this solution also had a lower performance than using CINs. Also developing code for more than one platform was not very straightforward when using DLLs. This made the use of CINs still the preferred external code solution in those days especially when support for multiple LabVIEW platforms was desired or performance was an important issue.

LabVIEW 5, multithreading

With the introduction of multithreading support, the external code interfaces also got somewhat more complex in certain situations. To take advantage of multithreading the external code interfaces needed to get configured to tell LabVIEW if it was safe to call the external code in different threads. For CINs this was done by exporting an additional function from the CIN which told LabVIEW if the CIN was safe for reentrant execution or not. LabVIEW assumed automatically unsafe behavior if this export was missing. This forces the CIN to always be executed in the only exclusively single threaded execution system, which was the UI system. For DLLs there was no way to have an automatic way of telling LabVIEW if a DLL function was safe for reentrant execution or not. Also a DLL could have multiple functions and some could be safe while others could be unsafe and Microsoft never had anticipated that a programming environment might be interested in this information from shared libraries. Therefore a manual configuration option was added to the Call Library Node configuration dialog. Only the developer of the VI could really know if a function was safe or not, either because he had developed the DLL himself and understood the issues or because he got this information from the documentation for the DLL. In many cases there is no specific information available in the documentation and in that case the best option is to leave the Call Library Node configuration to execute in the UI system. The alternative is trial and error, which can be cumbersome. Race conditions and other errors resulting from unsafe reentrant execution can occur randomly and at different moments based on previous execution order of library functions. Also many external factors such as system load or used memory can cause randomness in how race conditions make themselves noticed. Often you can execute an unsafe function countless times from a multithreading environment only to find that the application starts to crash or exhibits unexplainable calculating results after it has been shipped to the other side of the world.

LabVIEW 6, Extended shared library support

In LabVIEW 5.1 support for 68k Macintosh and Windows 3.1 was dropped and this allowed for an enhanced data type support in the Call Library Node. A function now could return also a string and function parameters could be configured to adapt to the LabVIEW data type, as no complicated automatic thunking needed to be performed anymore.
In LabVIEW 6.0 this was even more extended with ActiveX datatypes for Windows platforms, additional selections for the Adapt to Datatype parameter selection and as a gadget the selection of the available function names in a drop down box, but unfortunately only for Windows. Another nice feature added is the Create .c file selection in the context popup menu for the Call Library Node. With this you can let LabVIEW create a C header file with the correct prototype for the currently configured Call Library Node. This feature is especially handy if you happen to use the Adapt to Type parameter type as LabVIEW obviously knows best how its own data types are to be declared in C syntax.

One indication that CINs are starting to be considered legacy technology by the LabVIEW developers is the removal of support for creating external subroutines. This were external code fragments not loaded into the VI itself but instead being left as independent files on the file system in order to be called by different CIN code resources. One of its applications were common subroutines, another one was providing a place to store global data among multiple CIN code resources. This was a fairly seldom used feature although the National Instruments NI-DAQ library and the LabVIEW Advanced Analysis library did make use of them before they were ported to the Call Library Node interface.

LabVIEW 7, not much news on this front

LabVIEW 7 has not made significant changes to the possibilities of incorporating external code in comparison to the previous versions. The Call Library Node is quite mature and works well for almost any possible scenario and the CIN support has been further marginalized by removing almost any use of it in all the different LabVIEW function libraries provided by a fresh installation. Also National Instruments finished the port of almost all its hardware interface libraries and add-on toolkits to use the Call Library Node instead of CINs.

LabVIEW 8, A few more improvements

In LabVIEW 8.0 the Call Library Node was left mostly alone and no new feature was added. LabVIEW 8.2 however improved the Call Library Node further by adding error terminals to it, allowing passing the path to the shared library to be loaded at runtime, and it also added so called callback functions although this naming is in my opinion quite misplaced. Callback functions are usually function pointers that a caller can provide to be called back by a library or other external component. This callback functions can usually be called by that library at any time it wants to inform the caller about something. What LabVIEW 8.2 really supports is the configuration of initializing and deinitializing functions that the LabVIEW environment will call before and after calling the actual function itself and an abort function when the user aborts the user hierarchy while LabVIEW is in the process of calling that Call Library Node. Obviously this is only something that is possible for functions that are declared reentrant in the configuration.

I’m very excited to announce that Rolf Kalbermatter will be blogging a series of articles on LabVIEW external code interface here at EXPRESSIONFLOW. Rolf is a highly appreciated and active member of LabVIEW community. Rolf’s special areas of interest are in LabVIEW related low-level issues such as LabVIEW internals and external code interfacing. As a former employee of National Instruments, Rolf Kalbermatter has had an excellent opportunity to gain a deep insight to these issues. I’m very happy to welcome Rolf as an author at Expressionflow.

Multiple users have reported that they are unable to post comments to Expressionflow. The problem has been tracked down to have been caused by rich text comment editor that was used on this site. The rich text comments have now been disabled and there should be no more problems posting comments. Should you have any problems, please inform me. My email address can be found at the bottom of the page in the copyright notice. (Post has been edited!)

I was giving a talk on LabVIEW object-oriented programming a few week ago in the local LabVIEW user group in Helsinki. For the talk I did some research on the roots of dataflow programming and the roots of object-oriented programming. According to a Wikipedia article I found, dataflow programming was introduced in Bert Sutherland‘s Ph.D. thesis, The On-line Graphical Specification of Computer Procedures in 1966. Coincidentially the first object-oriented programming language Simula 67 was introduced around the same time.

Now these two different programming paradigms are merging and giving birth to a new paradigm object-oriented visual programming or should I call it object-flow programming. I believe this to be just the beginning of a new phase in the evolution of visual programming; we’ll see a lot of innovation in this field for the years to come.

Multi-core processors force the software industry to seek solutions to the development of parallel application. Object-flow programming makes developing parallel programs easy. Text based programming languages are bug-prone; visual software development is much less so. Object-flow programming has all the means of doing the same for programming as what Microsoft Windows did for operating systems -making programming so easy and intuitive that it’s no longer a privilege of few.

What do you think? Do you agree with me on the future opportunities of object-flow programming? What do you see to be the greatest obstacles? Could National Instruments get object-flow programming to Forbes cover page or do we need some other company to take the lead? I’d love to hear you comments!

Would you like to test your software on multiple different operating systems? Do you have multiple development branches of your software you would like to isolate on separate computers to avoid unwanted interactions? Is the software you are developing a client-server system that requires multiple computers to run? Do you need to debug your crashing software?

If you answered yes to any of the above questions, virtualized development environment may be the solution to your challenges. Virtualization is currently a hot topic in IT-industry. The word virtualization has multiple meanings and the most common meaning is running multiple operating systems simultaneously on one physical computer by virtualizing the hardware layer. Practically this means that you can run multiple operating system installations in parallel on your computer.

There are a few ways to implement virtualization. One way is to run a virtualization software such as VMWare Server (Windows, Linux), VMWare Workstation (Windows, Linux), VMWare Fusion (OS X), Parallels (OS X), Xen (Linux) or XenSource (Linux) on top of the currently installed operating system or host operating system (the supported host operating systems are in parenthesis). These virtualization systems then allow setting up multiple operating system installations of top the host operating system. The operating systems run as if they were installed on bare metal but they are really running on top of virtual hardware environment provided by the virtualization software. Click the image below to see what it looks like to run LabVIEW on virtual Fedora Core 6 linux on VMWare Server on Windows XP host operating system.

Virtual hardware environment

The isolated virtual computers are called virtual machines. From the operating system point of view virtual machines are exactly like real computers. They provide a processor, memory, hard drive, network interface, a monitor, a CD/DVD-drive, mouse, keyboard and may even support some USB-devices. The user of the virtualization software may define how much system resources such as memory and hard drive space each virtual machine may consume. The user may start and stop virtual machines by pressing start and stop buttons.

The virtual hard drive of each virtual machine is really a large file in the host operating system. The file may either be of a fixed size or gradually resizing up to some upper limit specified by the user. The memory is shared with the host operating system but the user may specify how much memory the virtual machine may consume. The host CD/DVD drive can be used with the virtual machines or alternatively a CD/DVD image can be mounted as a virtual CD/DVD drive. The host mouse and keyboard can be used to control the virtual machines. The virtual machine monitor is a window on the host operating system desktop.

The benefits of virtualization in software development

As indicated by the question in the beginning of the article there are multiple ways virtualization can benefit in the software development process. Virtualization allows isolating multiple software development environments on a same physical computer so that each branch is totally unaware of the other brances and cannot have any interactions with one another. This is a nice thing when you want to develop multiple different versions of the same software and don’t want the development of the different versions to interact and to cause problems in this way. You may also want to test your software with multiple different version of your development tool such as LabVIEW and keep all different version of the development tools isolated from one another. The ability to set multiple isolated development environments on a single computers makes the development process easier and saves your money and nerves.

Another issue where virtualization is a great benefit is when you want to test your software on different operating systems or different versions of the same operating system. Virtualization software allows you to set up multiple different operating systems on a single computer and run them all in parallel. Consider for example that you are developing a LabVIEW application and want to test that it runs properly on Windows XP, Windows Vista, different versions of Linux and OS X. With virtualization software you can run all these operating systems on one computer, although running OS X requires this computer to be a Mac.

Third benefit is when you develop a networked application and need to have multiple computers set up to run the application. Instead of really setting up multiple physical computers you may set up multiple virtual machines that run the different components of the software and interact with one another via the network.

A fourth task where virtual machines show their power is debugging your software. Virtualization technology allows you to make snapshots of your entire virtual machine. The snapshot stores the state of the virtual machine including the memory state and hard disk state to a file. Later you can roll back to this snapshot and repeat what ever you were doing. This is a nice tool when you are for example dubugging a crash. It allows you to roll back to the moment just before the crash and see what really was going on when the crash happened.

Conclusions

Virtualization and virtual machines are a great tool for software development. In this article I covered some general benefits of virtualization in the software development process. I’ll write a follow-up article where I talk about setting up a superb free virtualization software, VMWare Server for Windows. Subscribe to the feed not to miss the next article.

I’d also like to cover LabVIEW licensing issues related to running LabVIEW in virtual machines. I’ve emailed twice National Instruments media relations within the last month telling them that I’m writing an article on LabVIEW virtualization and asking them to comment LabVIEW licensing under virtual machines but they don’t seem to bother responding me. I guess blogging is still not considered a real media.

In our last topic in article series Introduction to Object-Oriented Programming in LabVIEW I explained how real world objects form conceptual hierarchies. This concept of hierarchies is also present in object-oriented programming where building block can have hierarchical relationships. This concept of hierarchical relationships of software modules in object-oriented programming is called inheritance, as explained last time.

Inheritance in practice

So what does inheritance practically mean in the context of object-oriented programming? Why would we like to define class hierarchies?

Let’s first define some concepts. When a class inherits from another class we call the class upper in the hierarchy a parent class and the class lower in the hierarchy a child class. Further we call parent, parent’s parent and all other classes up in the inheritance chain ancestor classes. Likewise we call all classes down the inheritance chain descendant classes. In the picture below these concepts are visualized for the class Car.

As we explained earlier a class in object-oriented programming is a user defined datatype that encapsulates both data and functionality. In comparison conventional LabVIEW data types only carry data. As classes are types in object-oriented programming, wires of class types are called objects.

Each class in object-oriented programming specifies some functionality. To implement this functionality the class developer writes a set of method VIs. The method VIs are an integral part of the class. In addition the class developer specifies some internal or private data type for the class. This data type is a cluster. Note that the unlike conventional clusters, this cluster can also be empty.

Reusing ancestor methods

So what’s all the fuss about inheritance? Inheritance allows a developer of the descendant class to reuse much of the code in any of the ancestor classes. If an ancestor class has a method public method VI, this method is available also in any of the descendant classes. Furthermore if objects of ancestor class carry data of certain type, then all the descendent classes carry similar data of the same type.

Let’s take an example. Consider a land vehicle class. As each land vehicle has wheels, we decide to specify that a land vehicle class cluster of private data is an array of wheels. Cluster of private data is a place where the developer specifies the data type that is carried by the wire. Now our all objects of Land Vehicle class as well as all objects of any of the descendant classes of Land Vehicle would carry array of wheels as private data. In addition descendant of Land Vehicle can carry other private data as well but they would always carry at least an array of Wheels.

We cannot fix the number of wheels as some vehicles such as bicycle has only few wheels and others such as a train have more wheels. Further we cannot add an engine to cluster of private data as not all land vehicles have engines. The picture below illustrates the private data of our Land Vehicle class.

Now we define a public method VI Add Wheel.vi to Land Vehicle class. This method would add a wheel to a vehicle. Now each descendant class of class Land Vehicle would also have these two methods automatically. Land Vehicle would be a kind of a template or a starting point from which we can now build different kinds of land vehicles such as a car or a bicycle.

Class Land Vehicle is a parent class of classes Car, Bicycle and Motorcycle. Now comes the interesting part. All these three classes can call the Add Wheel.vi method as if it was their own. The picture below illustrates this ability.

So by inheriting classes Car, Bicycle and Motorcycle form a common parent class Land Vehicle, we can share code related to adding wheels to different kind of vehicles between these three classes. The same generality cannot be achieved in classic dataflow programming with such an elegant way.

Passing descendant classes as arguments

Consider you want to travel from Paris to Berlin. Unless you want to walk, you would need a vehicle to take you to Berlin. However it could be an aircraft, a land vehicle or even a watercraft. So generally you could say that any vehicle could be used to travel from Paris to Berlin.

Similar way thinking can be applied to object-oriented programming. When any VI expects an input of general class type then any of its descendants can be passed as an argument as well. So should you have a VI Travel by Land.vi that expects an object of class Land Vehicle as an input, you can pass any object of any descendant class of class Land Vehicle as an argument. This is illustrated by the following picture. The VI expects a Land Vehicle (right) and we pass a Car which is a child of Land Vehicle (left).

In the previous example we showed how we can reuse ancestor method VIs in descendant classes. However this is not the only benefit of inheritance and class hierarchies. In addition to reusing ancestor class code, we can also pass descendent classes as arguments where ancestor class is expected. Alternatively we can create an array of different kinds of Land Vehicles as select one of the items in an array using index array.

Conclusions

In LabVIEW object-oriented programming or LabVOOP for short we developers can share parent or other ancestor class code between all the decedents of that class. This is a great benefit when software components with shared properties are needed. In my next article in this series I’ll talk about class interfaces, how the interfaces can be shared between classes in the hierarchy and how this greatly enhances software development process. Subscribe to the RSS feed of this blog not miss it.