By Andrew Bond, Industrial Automation Insider
Latest version of LabVIEW promises to simplify transition to new generation of multicore processors
A National Instruments press conference at the Institution of Engineering and Technology to announce a new release of LabVIEW has become as regular a feature of the English summer as Wimbledon, Cowes or catastrophic flooding. This summer has been no exception, so last month software marketing director John Pasquarette, for whom this is also becoming a regular fixture, was back for another outing of his double act with U.K. and Ireland marketing manager Ian Bell.
Last year they were celebrating the 30th birthday of the company and the 20th of the product and were able to spice up their performance by incorporating into their act the newly introduced Lego Mindstorms NXT robot whose software is based on LabVIEW. This year they were faced with rather more of a challenge, given that the principal feature of LabVIEW 8.5, now routinely described as neither a programming language nor a measurement tool, but a “graphical system design platform,” is its support of automatic multithreading on desktop PCs and of real-time control on multicore systems.
The challenge, therefore, was first to explain the issues raised by the emergence of a new generation of multicore processors, second to explain how the new release copes with them and, third and most important, why, with the one exception of the guy in the front row whose mission in life was to demonstrate that he knew more about the subject than Pasquarette, the assembled hacks should be interested.
Dual cores ubiquitous
As Pasquarette explained patiently and in words of no more than one syllable to the rest of us, dual-core processors are now almost ubiquitous in new desktops and laptops. Moreover quad cores will reach the market later this year, and Intel is promising processors with up to 80 cores within five years.
Driving this trend is, as ever, the endless pursuit of higher performance which, with raw processing speed having virtually reached its limit, is now being sought through increased parallelism.
That however brings its own problems. Whereas traditionally software developers have been able to reckon on faster processors improving the performance of their software, these more recent developments “do not take most current applications along for their customary free ride,” as Microsoft software architect Herb Sutter put it in his article, “The Free Lunch Is Over” in the March 2005 issue of Dr Dobb’s Journal. Instead applications must be broken up into parallel paths or “threads” that can be executed simultaneously. That means, using conventional development tools, learning new functions to create, destroy, communicate between, synchronize and debug across threads.
Not if you’re a LabVIEW user however. LabVIEW has, in fact, supported multithreading since 1998 and has the capability automatically to divide applications into multiple execution threads. As a result, in contrast to conventional applications, existing LabVIEW applications already run of the order of 1.6 times faster on dual-core processors. Now, the latest release allows execution threads to be scaled automatically to the total available number of cores and adds improved thread scheduling for LabVIEW timed loops, as well as delivering enhanced “thread-safe drivers” and libraries. As a result, users such as Germany’s Max Planck Institute and AmFax Ltd in the U.K. are experiencing performance improvements of between five and 20 times.
As well as providing support for multithreading on desktop systems, the new release also offers significant advantages when implementing real-time control on embedded multicore systems. Symmetric multiprocessing (SMP) with the LabVIEW Real-Time environment allows automatic load balancing of tasks across multiple cores while maintaining determinism. Additionally, users can manually assign portions of code to specific processor cores to fine-tune real-time systems or isolate time-critical sections of code on a dedicated core. And the new Real-Time Execution Trace Toolkit 2.0 visually displays timing relationships between sections of code and the individual threads and processing cores where the code is executing. The same inherent parallelism is also claimed to make LabVIEW ideal for developing FPGA (Field Programmable Gate Array) applications, with an FPGA Project Wizard automating I/O configuration, IP development and overall setup for common I/O, counter/timer and encoder applications.
The other major innovation in LabVIEW 8.5 is the introduction of a new Statechart module which allows the design and simulation of event-based systems including, for example, safety-critical applications, based on the UML (Unified Modelling Language) standard. Also specifically aimed at industrial applications are a range of I/O, measurement and display enhancements for building PAC (Programmable Automation Controller)-based systems, including a new library of OPC drivers that nearly doubles the number of compatible PLCs and industrial devices supported. In addition, a new multivariable editor makes it easy for users to quickly and easily configure or edit hundreds of I/O tags in high-channel-count systems using a simple spreadsheet interface.
Also new are a set of flexible pipe display tools to simplify the building of more realistic industrial user interfaces and an interactive drag-and-drop approach to tying I/O tags directly to displays running on Windows CE-based industrial touch panels and handheld PDAs. Control design and simulation enhancements include Model Predictive Control (MPC) and analytical PID controller design.
As always with National Instruments presentations, admiration for the ever-increasing range of capabilities is tempered by the seeming arrogance of proposing solutions for applications in specific industries which wholly ignore the standards of those industries. Thus, although the specific example of an industrial application cited by Ian Bell was a simple, almost archetypal, batch control application, the question “Why would one use LabVIEW for this rather than a development environment which complied with the increasingly widely accepted IEC 61131-3 standard?” evinced no very convincing explanation other than that conventional PLC-based systems could not meet the requirements of all industrial applications.