Virtual Soldering （1）

Published:2011/8/2 2:23:00 Author:Amy From:SeekIC

Dr. Thomas Scherer

Even experienced electronics engineers occasionally find themselves confronted by the need to swap soldering iron for keyboard: not all projects can be realized purely in hardware. LabVIEW makes an excellent choice of programming language for engineers!

When a PC forms an integral part of a technical solution and no suitable software is available off the shelf, some programming is required. There are various solutions to this problem: suitable modern programming languages include C in its various forms such as C++ or C#, Visual Basic from Microsoft, Delphi from Borland or even Lab­VIEW from National Instruments (Nl). Visual Basic is designed rather for smaller applications, whereas C has for a long time been a universal tool. Del­phi is an alternative for those who are not comfortable with C’s idiosyncrasies and prefer the structured style of Pascal. The majority of all large applications and all modern PC operating systems are written in C: and with good reason. This gives rise to the generally-held opinion that ’real programming’ should be done in C, since C, of all the third-generation languages, produces the most ele­gant and fastest solutions. So what about LabVIEW?

Fourth-generation language

First, all the arguments that persuaded Microsoft, Apple, Linus Torvalds and many other professional programmers to use C as the basis for various operating systems are quite beside the point for the casual programmer. What counts is only how much effort it takes to write a good program. And by ’good program’ we mean one that does not just function correctly in principle, but one that is above all else reliable and easy to use.

When you consider that, when you buy a PC today, you have to download some 100 MB of patches and extensions from the Internet in order to bring Windows XP up-to-date, perhaps you might think twice before using C. Every month Microsoft issues updates to fix bugs and close security holes. And this is not just to question the abilities of the Microsoft software engineers: the situation is no different for OS X or Linux. The complexity of the software is not solely to blame for the problem. Also at fault is the programming language. C does not make it easy to find errors, and nor does it help to avoid them in the first place. C is just text, and typing errors can easily creep into text files. Modern software consists of incredible amounts of text (Windows, for example, is millions of lines of code). Even understanding it in outline is a sci­ence in itself. A casual programmer has neither the know-how nor the organizational means to get a complex piece of software into a usable state in a reasonable amount of time.

Of course this problem did not just arise yesterday, and there have been solutions available for some time: fourth-generation programming languages. Essentially these are program generators that, usually with the help of a graphical user interface, create the actual code accord­ing to the abstract arrangement of functional blocks and control units. This high level of abstraction makes devel­opment much faster, since there is no need constantly to reinvent the wheel.

This is akin to developments in electronics where inte­grated circuits are now used instead of discrete compo­nents. It is clear that integrated circuits, which offer ready-made professionally-optimized subsystems, allow an individual to solve more complex problems than before, and with a drastically reduced likelihood of mak­ing a mistake. In software this in analogous to a program generator that produces code which has been optimized and thoroughly tested by professionals. Of course there are also disadvantages. The conse­quence of a higher level of abstraction is an inevitable loss of flexibility. Solutions can no longer be tailored so precisely to particular problems. The programs do not run as quickly as those written in C, and the files gener­ated are considerably larger, in the same way as the number of transistors in an integrated circuit has grown explosively. However, in view of the sizes of hard disks and memory available today, the large files do not present a problem. The difference in speed is relatively small these days (and an assembler program is gener­ally faster than one written in C). The limited flexibility, however, definitely makes a difference: program gener­ators are not equally good in all applications. They are more or less specialized to certain application areas such as databases, data capture, or measurement, con­trol and regulation.

Unfortunately our analogy now breaks down: ICs from different manufactur­ers are generally compatible with one another: this is not the case with pro­gram generators. A piece of code from one manufacturer cannot be com­bined with one from another (as if one had to buy a complete set of ICs from a single manufacturer). This also goes for LabVIEW.

Besides factors such as the compre­hensiveness and the range of functions provided, an important selection crite­rion is the level of maturity of the included modules. Another factor that should not be underestimated is the size of the user community for support. It is also important to consider the field in which the programming language is to be used. Ultimately one is going to sell a product, and if the prospective customer’s technical department turns up its nose (justifiably or not), then you have a small problem.

In this regard LabVIEW presents no great difficulties. In the car industry the use of LabVIEW for measurement and testing is standard from Alfa Romeo to Volvo. LabVIEW can be found somewhere in practically every field of scientific endeavour. And, as product cycles get shorter, the sheer flexibility of LabVIEW is becoming more and more highly valued in the production environment.

Overall, then, LabVIEW offers the most mature fourth-gen­eration language code base and the largest developer community in the fields of measurement, test and control. However, LabVIEW is no software jack-of-all-trades: you could not, for example, write an office suite using it, although it is perfect for instrumentation data processing. The most important limitation is that LabVIEW may not, according to the manufacturer, be used in safety-critical applications. Nl is covering itself here from a legal point of view: it is hard to find any practical reasons not to use it.

Reprinted Url Of This Article: http://www.seekic.com/blog/project_solutions/2011/08/02/Virtual_Soldering_（1）.html

Print this Page | Comments | Reading(416)