LabVIEW – More LCOD

PREFACE

LabVIEW Component Oriented Design (LCOD) is a method that uses several simple Design Rules that can be helpful in programming LabVIEW applications.

I have been using some of the LCOD methods for over 30 years. In 2010 I started writing about this LCOD experience on my website and eventually developed some programming notes on LCOD. This sat for a while until I finally edited and expanded them into this book.

Whether you are a new LabVIEW programmer or an old seasoned one like me, the quest always remains the same, building better programs with our favourite software tool > LabVIEW.

The aim of this book is to offer some guidance and help in achieving this.

I have been programming and using many design methods and languages for over half a century. In 1988, I wrote the first LabVIEW & LabWindows training courses for Europe.

I have trained over 3000 people on how to program in LabVIEW.

This book is about the evolution of my design work using LabVIEW LCOD over the last 35 years. I started working on this LCOD methodology, unknowingly and naturally in 1987 in my first LabVIEW programs. It developed very slowly from there. What’s 35 years?

Just a heads up: in many pages of the book, you will find the abbreviation COC. Don’t panic, it is not Clash of the Clans. COC serves as an abbreviation for the term used on many pages, namely Cluster of Constants. Pronounce it C – O – Cs : no, not the other way.

Cluster of Constants or COCs are at the heart of this book. They may, after a while, invoke mental pictures and even dreams.

COC may even become LV jargon, an acronym. How is that COC coming along?? Is it a Type Def? Definitely make it a Type Def!

Another term used throughout the book: when you read Component, think Oh yes, a special type of LabVIEW SubVI or a LCOD state engine. These three terms Component, SubVI and LCOD state engine may be used alternately throughout the book.

This book may be the final hurrah of an older LabVIEW groupie, almost!

A big thank you to Jeff Kodosky and his development teams over the years before I go. It has always been a great delight to play with your creation, considering the software tools we were using before it came along.

Thank you also to Jim Truchard and NI for driving the Virtual Instruments and LabVIEW products to market.

And just to complete my professional work cycle, recently I have found a young engineer to continue with my LabVIEW creations who will probably markedly improve them.

Enjoy the book.

INTRODUCTION

Just to make this book a little more fun, I have included some chapters of my experiences with various technologies from the 1960s to the present. It started with a 1967 PDP 8i that was first used to provide biomedical instrumentation solutions and then the newer evolving technology that was used to meet requirements in many university research fields, then later industrial test, automation, instrumentation, T&M, agriculture, horticulture, marine, military calibration and repair, also some embedding, sensors and a little on teaching LabVIEW worldwide.

abbreviation >> LV = LabVIEW

abbreviation >> COC = Cluster of Constants

abbreviation >> LCOD = LabVIEW Component Oriented Design

DESIGN CONCEPTS AND METHODS OF LCOD PROGRAMS

Before the mid-1990s, this LCOD abbreviation did not exist, although I am sure some were playing with the concepts. Finally, in the mid-1990s, these concepts were made real and introduced in the book A Software Engineering Approach to LabVIEW by Jon Conway and Steve Watts.

It outlined the design concepts and methods of LCOD programs, with four main focuses:

Hidden Data

Abstraction

High Cohesion

Low Coupling

It is a great book and explains three of the focuses very well.

This present book shows a better way for hidden data and can become a companion and or an adjunct to the original book.

The book's purpose is to expand the understanding and use of LCOD.

Hidden Data

Hidden Data in this book means: removing constants from diagrams; in fact removing them from the program entirely, on to disk.

This book will show a graphical method to achieve hidden data: an important LabVIEW step. Over several chapters this new hidden data method will be expanded to completion. This new LCOD design method also develops into a full programming methodology.

Abstraction

Abstraction in this book means a programming methodology that takes concepts, data, information and ideas based in computer terminology and language, such as data types and formats, hardware descriptions, port #s, bit #s etc. and elevates those meanings to more meaningful human language word descriptions and concepts. Abstracting will allow a more human context into the program solution in the actual LabVIEW front panels, diagrams and data.

Abstraction promotes a language elevation or conversion to take place for clarity of meaning.

Examples of abstraction or language conversion or elevating meaning

Computer words > Digital Output Port A has Bit # 1 True. The abstraction: in human words this becomes Water Pump #1 = ON

Computer words > ADC Channel # 5 > Reading is 3 VDC. The abstraction: in human words becomes > Manometer # 1 Pressure = 2000 Pascals (by calibration).

To achieve these abstractions:

LCOD usually uses Named State Engines (Components) (Nouns).

LCOD State Engines Case Selectors are controlled by a series of enum constants as (verbs) (actions).

Enum Constants and Enum Controls

Abstraction happens in many places in LabVIEW. One example is inside a State Engine diagram, when the controlling enums, as (verbs), are wired to a Case Selector.

Enum abstraction

The Text Data in the enums that are wired to the Case Selector are now displayed in each individual case state’s heading or label.

Abstracting is very helpful for the programmer, adding meaning and documentation to the diagram.

Cohesion

Cohesion in this book means: focused and singular-purpose SubVIs or Component, such as Calibrate this sensor or do this type of test. Not combining those two tasks together in one SubVI. Cohesion is all about splitting or separating these types of combo SubVIs into separate focused, cohesive pieces for clarity and ease of maintenance.

Not doing half a computation in one SubVI and the rest in another SubVI.

Coupling

Coupling in this book means: Low/No Coupling throughout a LabVIEW diagram is imperative.

Coupling occurs between SubVIs in two ways, Code and Data.

Code Coupling

If there is a SubVIs used inside a program in two locations and you edit the SubVI in one part of the program to make it work correctly there but forget about the other location’s use of the same SubVI, you immediately create an accidental coding coupling error. Whenever the SubVI runs in this forgotten location, it could result in I/O malfunction, data errors and the like. Great confusion can arise.

It is always better to create two separate SubVIs with different distinct names to stop accidental code coupling. Name them for their function, location and purpose. This makes each a private SubVI.

All the encouragement about reuse of SubVIs throughout a program may not always be totally beneficial. LabVIEW is very efficient in compiling small code size SubVIs.

Data Coupling

Data coupling is more common.

It is very easy for data coupling to get out of control. For example, it can happen when private data and public data usage becomes confused. private data in this book is data that only a single SubVI knows, uses and has access to. public data, on the other hand, is available to all SubVIs of a program. For instance, if two SubVIs share private data between them and the private data in one SubVI is modified to achieve a certain result, there will be a data coupling error when the other SubVI runs. This is especially true for calibration data and constants used in formulas.

OTHER AREAS OF FOCUS

I would like to add a couple more items to the list of four above for LCOD focus.

Public and Private Data

Continuing on with public and private data ideas. Program designs that separate public and private data correctly will often exhibit strong cohesion and low coupling naturally. Get the public and private data rules sorted and the program will become simpler and more stable.

Enums as Type Defs

Make all Enums into Type Defs (verbs). Use them everywhere but especially for driving the SubVI State Engine’s Case Selectors.

Also do make all controls and indicators that are repeatedly used throughout the whole program into Type Defs.

This is especially true for complex front panel clusters of controls or indicators.

These Type Defs will create the consistent look and feel uniformity in the front panels.

Some examples:

Cluster type definitions

These two Control examples are clusters.

Also, numeric, strings, booleans, arrays, charts and graphs that operators use, once sized, fonted, coloured and so on, need to be Type Defs.

As you will see later, all the Cluster of Constants or COCs used in the hidden data method are Type Defs. Type Defs take a little time to build, yet do it, as it will pay off handsomely.

These rules are especially applicable to large programs where you cannot hope to hold the details about all the SubVI’s front panels, diagrams and data in your mind. Rely on Type Defs to manage a large part of it all for you. You will know you are globally winning in your design efforts when you change a Type Def and save it, and the computer sits for some time updating all the other copies throughout the program. Smile when this happens.

If you are building small programs, still use these development points, as someday you will build a big program and all the early training will pay off.

Programming Ecology

I call these ideas and methods programming ecology, as the design is nurtured, kept clean and healthy. Take your time and don’t short circuit the build; stay on cue and keep the design flow right through to the end.

Ecology. Go around and pick up all the garbage and clean up the mess so it can breathe.

This introduction, hopefully, will whet the appetite for some LCOD learning and fun.

CHAPTER 1

THOUGHTS ON AND EXPERIENCES OF LABVIEW PROGRAMMING

Focus:

LabVIEW Program Design

Using LCOD

The book uses a series of LabVIEW applications to demonstrate the LCOD methods.

All the applications panel and diagram snippets are from various versions of Australian and New Zealand Standards Windows, Walls, Doors, Roofs and Facade Industrial Testers.

The first example shown is a front panel for these types of industrial tester applications.

This front panel shows the main application’s entry point for the operator at startup.

Notice the row of