Draft Blog Post 1

One thing I've been learning over the past few months is LabVIEW. It's a very powerful programming tool. By drawing a data-flow diagram (DFD) you can build a program very quickly.

Another thing I've learnt is that, like most programming, with LabVIEW, you can get 80% of the solution very easily. The next 15% is tough, especially with concurrent processing. The final 5% ends up requiring a much deeper expertise; knowing the fuller toolkit and idioms of the language.

Data-Flow Diagrams

I say that LabVIEW uses data flow diagrams; that comes from an early bias. I learned SSADM (Structured Systems Analysis and Design Method) in my late teens, and it has remained the framework for much of my systems analysis and requirements capture work. Another way to look at it is a schematic, or wiring diagram.

Data-flow diagrams capture how data moves between entities and functions. A classroom example would follow a purchase order from the sales desk to the warehouse, shipping, and billing. Each department processes and maybe adds to the data. A pick list would be generated for the warehouse, while a shipping label and packing list would be created for the shipping department. Meanwhile, billing would generate an invoice and on later payment a receipt.

LabVIEW certainly follows the look of a DFD for the most part in its Block Diagram editor. You connect data nodes and process nodes via wires.

The data nodes encompass a wide range of variables. Integers, floats, strings, arrays, and handles/references.

Process nodes include built-in functions that can include:

• GUI rendering tools for graphs

• data port connections

  • VISA connection via Comm Ports

• data accessors for test equipment connected to your PC

  • Picoscope

  • Digilent Analog Discovery

  • NI Data acquisition models

• mathematical functions

  • FFT

  • PID

These process nodes include mechanisms to call any DLL on your system, load .NET components, execute Python, and several interesting other hooks into SDKs and libraries.