Today’s big news is that Microsoft made a $44.6bn takeover bid for Yahoo! And I thought Yahoo! was so 90′s.

If the deal goes ahead, will it have implications related the visual programming? We all know that NI is the leading developer of visual programming languages with its LabVIEW integrated programming language and development environment. However neither Microsoft nor Yahoo! have been completely quiet in this scene. Yahoo! has developed a domain specific visual programming environment Yahoo! Pipes for aggregating web feeds and other online information resources. Microsoft has developed a little similar tool, Mashup Creator, for their Popfly online web development environment. In addition Microsoft has a product called Microsoft Robotics Studio for robotics application development.

Even though the products of both Microsoft and Yahoo! are rather simple and restricted, they indicate that visual programming is slowly coming of age. However consolidation of services from the two companies doesn’t necessarily mean anything good for a minor field like visual programming. It’s very plausible that projects like Popfly and Pipes end up dead when giants like Microsoft and Yahoo integrate their organizations.

What do you think? Will Microsoft’s possible deal with Yahoo! have implications in the field of visual programming?

LabVIEW Object-Oriented Programming (LVOOP) was introduced in LabVIEW 8.20. LVOOP allows developers to build recursive tree-like data structures within LabVIEW dataflow model. Recursive data structures are enabled by allowing class private data members to be of ancestor class type. As ancestor class private data members can hold descendant class objects, recursive data structures are possible.

However LabVIEW doesn’t allow using recursive type structures where a type refers to itself. I present here that indeed building such types would be possible within the dataflow framework of LabVIEW. Such recursive types would allow building recursive data structures in more intuitive and type safe manner than what is possible with current LVOOP implementation.

more…

Summary

The Queued State Machine -Producer Consumer architecture; abbreviated in this article as QSM –PC, is one essential architecture that significantly facilitates programming mid-sized to advanced LabVIEW –based projects that constitute 100 or more VIs. A common application for the QSM -PC architecture is in programming LabVIEW’s event structure to send commands for asynchronous processing in a parallel loop so that event cases can exit code execution quickly and avoid GUI lockup. Another application is in multiple parallel VI programming such as in parallel data acquisition, alarm monitoring, and results analysis, where this method empowers any parallel VI to send and receive commands and data across other parallel VIs with no data loss.

In light of the intermediate to advanced nature of the objects that make up the QSM –PC architecture, taking full advantage of this template requires detailed knowledge of the ‘why’ and ‘how’ of its various characteristic design aspects. This article defines, illustrates, and describes at length the various elements of the QSM –PC architecture and includes a LabVIEW example of this implementation with detailed narrative comments.

more…

LabVIEW 8.5 includes a new visual merge tool LVMerge that can be called from external source code control program for three-way VI merging. I’ll go trough the steps required to integrate LVMerge with popular TortoiseSVN source code control client.

If you have edited a VI that is under source code control, occasionally someone else may have edited the same VI after you have checked it out. As a result the two versions of the same VI are likely differ from each other. In three-way merging, these two different versions of the VI are compared agains a common base version of the VI. This way the merge tool can identify which of the changes have occured in both of the modified version since the VI was last checked out. LVMerge is a three-way merge tool and allows developers to visually compare all three versions of the VI. For each modification in either of the two modified version of the VI developer can choose if the modification should be ignored or included.

Setting up TortoiseSVN

To set up LVMerge with TortoiseSVN, right click on a directory under souce code control and select from the right-click menu and and then from the appearing submenu. TortoiseSVN Settings screen will open.

Select Merge Tool from the tree menu on the left and press Advanced… button on the right to open the advanced merge tool settings.

No, let’s define that files with extension .vi shall be merged with LVMerge. Tio do this, click Add… button. A dialog window with two fields Extension and External Program will appear.

For the Extension field fill in

.vi

For the External Program field fill in

“C:\Program Files\National Instruments\Shared\LabVIEW Merge\LVMerge.exe” “C:\Program Files\National Instruments\LabVIEW 8.5\LabVIEW.exe” %base %theirs %mine %merged

If your LabVIEW installation directory is not under C:\Program Files\National Instruments, mofify the path respectively.

Press Ok for all the open windows and you are done setting things up.

Accessing LVMerge to Resolve Conflicts

Now we are ready to resolve conflicted VIs. When TortoiseSVN encounters a conflict, it layouts a exclamation point on top of the file icon on windows explorer. The exclamation point indicates that the file is conflicted and that you need to manually resolve the conflicts.

To resolve the conflicts, right click on the conflicted file and select and from the appearing context menu. Now TortoiseSVN will call LVMerge to allow you to resolve the conflicts. LVMerge is a rather intuitive tool and I’ll not go into detail how to use it. You’ll come along.

After you are done with resolving conflicts, save the file with the proposed name and quit LVMerge. TortoiseSVN doesn’t automatically know that the conflicts are now resolved but you still need to thell this to TortoiseSVN. You can tell TortoiseSVN that all conflicts are now resolved by selecting and from the right click menu of the conflicted file. After you have resolved all conflicts in your project, you can commit your changes to the repository.

Note! When resolving conflicts this way, the merged version gets saved on top of your own version of the VI. If you make mistakes in the merge process, you may accidentally loose your own changes to the VI. This is a feature of TortoiseSVN.

Don’t forget to read Jim Kring’s recent post Using Beyond Compare as your TortoiseSVN Diff Program for ZIP Archives at Thinking in G.

I don’t normally blog about bugs. However with this particular bug I decided to make an exception as it potentially affects everyone in a very nasty way. A few days ago a severe LabVIEW data corruption bug was found by a LAVA forums member Wolfram. As a result of this bug LabVIEW incorrectly reuses calling VI data buffer when calling a value property node in a subVI. The content of a calling VI data buffer gets overwritten by the data passed to value property node. As LabVIEW stores block diagram constants as data buffers, also the values of block diagram constants get changed. The bug is present in all recent LabVIEW version including LV 8.5.

The most common use case I can think of that reproduces the bug is when passing data to an subVI to be interactively viewed by the user. In such cases it’s common to use value property to modify the displayed data. As a result of the bug, the values written to value property node ‘backpropagate’ to the calling VI or to where ever LabVIEW decided to make the last buffer copy.

Main VI passes data for subVI to be visualized

SubVI uses value property node to modify the displayed data

Main VI after execution, moving mouse over the constant displays the changed constant value

Download an example project from the link below:

Buffer bug example for LabVIEW 8.0

National Instrument has just released version 8.5 of its visual programming language and integrated development environment LabVIEW. The following new features have been added to LabVIEW development environment

• synchronizing LabVIEW project environment with hard disk folder content
• new visual merge tool for merging different versions of same VI
• new functionality for resolving cross-linking issues
• multi-core support for LabVIEW Real-Time
• quickly create accessor methods for LabVIEW classes

In addition the language has got some new features as well

• enhanced memory efficiency with new in-place memory structures
• support for shared reentrant VIs
• support for recursive calls to member VIs of LabVIEW classes
• feedback nodes can now be used outside loops
• ability to exit for loops in middle of iteration with new stop terminal
  
• enhanced linear algebra support

The full list of changes can be found in the upgrade notes pdf document. NI has also published the list of most important bug fixes.

It’s interesting to see how these new features affect the software development with LabVIEW. I’m especially happy to see the support for recursion in LabVIEW object-oriented programming, as the lack of that was one of the most restrictive things in the previous LVOOP implementation. As of now, I found no evaluation download link for the latest release. I guess we’ll have to wait to really get our hands on this latest toy from NI. Any comments and further information is very welcome.

EDIT: The download link for LV 8.5 for Windows evaluation is now online.

LabVIEW Object-Oriented Programming, or LVOOP for short, has been around for about a year now. Have you had time to take a look at it? If not, it’s about the time. I made you a short video on the very basics of LVOOP development process. It doesn’t go into details of inheritance and all that but it gives you and idea on how to get started. So get yourself a cup of coffee, sit down comfortably, and press the play button.

(length 09:05)

This blog article is written in two parts. Part 1 introduced MS SQL Server 2005 Express Edition in relation to MS Access and discusses essential installation logistics. A LabVIEW –based installer for MS SQL Server 2005 Express Edition is included for download with this second part of the blog article. Use of this utility can be described in one phrase as follows:

“Copy the folder < Database Manager> to your target computer and after you have installed LabVIEW runtime engine, launch the executable: Database Manager -Installer.exe. Later on, you can use the Database Manager –File Copy.exe utility to import, export, or upgrade database files.

more…

Referring to the sequence in the slogan: design, develop, prototype, and deploy, this blog article starts at the tail end of that sequence. The reasoning is that: by addressing the number-one bottle neck in adoption of client/server databases, namely: portability, distribution, and advanced custom installation, LabVIEW users will be motivated to seriously consider bundling these powerful databases with LabVIEW applicationsThis blog article is written in two parts, Part 1 introduces MS SQL Server 2005 Express Edition in relation to MS Access and discusses essential installation logistics. Part 2 delivers the LabVIEW -based installer wrapper for MS SQL Server Express 2005.

Blog articles that follow will discuss fundamentals of relational database design suited to automated measurements and control applications. The intent is to help developers design and program functional databases relevant to the measurements and automation field of LabVIEW applications.

more…

Visual programming is gaining more and more visibility outside the the LabVIEW community. In ITWritings blog Tim Anderson draw attention to the fact that multiple visual programming languages have gained public attention lately. These include a visual programming environment Scratch for kids by MIT, Yahoo pipes RSS feed syndication language and Microsoft PopFly online visual programming language for Silverlight.

It seems that visual programming languages are gaining attention in the field of domain specific languages. This is definitely the right route to go as the main stream general purpose programming languages are hard to replace. In addition domain specific languages allow gathering experience on visual programming in general that can later be leveraged on more general purpose language domains.

National Instruments (NI) has been very protective in the field of visual programming. NI owns multiple visual programming related patents and has used this patent portfolio to keep other companies out of the field of visual programming. It’s interesting to see if NI will continue it’s protective policy and sue MIT, Yahoo and Microsoft for patent infringements.