The Art of Creating Dynamic,Flexible LabVIEW Applications

Norman Kirchner CLD, CPI – Texas InstrumentsGerald Albertini CLD – Texas Instruments

August 10, 2006

‘Dynamic’ in LabVIEW – Going N+1

• What does ‘Dynamic’ mean to us?– Ability to have software change and grow based

upon customizable configurations and user inputs– Ability to transfer data and control, without the

need of additional wiring

• Why use it?

• How do We Accomplish it?

Measurement Library – Adding Instrument

Make Driver

Add Configuration to Panel

Add New Instrument Specific Cases

Add Configuration Data to DataFlow

Increase Size of Code to Include Driver VI’s

Add Configuration to Connector Pane

<more>

Repeat For Every

Measurement

150+

Make Driver

Update TypeDef

Done Once

Test Module

Sub-Panel

Config.vit

Instrument Driver

The Art at Work

• Universal Instrument Configuration & Control

• Drop-In “Brat Code”• Daemon – Background Engine• Calling into Other VIs• VIt Usage• Plug-in Architecture• Sub-panel• Callback

InstrumentConfiguration

InstrumentConfiguration

InstrumentConfiguration

Instrument Driver

Instrument Driver

Data

Advanced VI Server Techniques

• Drop-In ‘Brat Code’ & Extrapolation– What Happens When Children Control the Parent

• Calling VI’s From Anywhere– Reach Out and Run Someone

• Utilizing the VIt– These ain’t your fathers templates

Drop-In ‘Brat Code’ & Extrapolation – The What

• Code that can “look up to” and operate on the code it’s placed inside

– Stupid about the code around it– Smart enough to function w/ little to NO input

Drop-In ‘Brat Code’ & Extrapolation – The Why

• Achieve Complex Operations w/ Little to No Wiring

• Very Modularized

• Fosters Re-use

• Enables Plug & Play Code(or Drop & Run)

“The scope of the code does not depend on pre-defined limitations.It adapts to the code it’s in.”

Drop-In ‘Brat Code’ & Extrapolation – The How

• Get a reference to the high level object of interest

– Front Panel Ref– Application Ref– Path

• Scan results to get items– Utilize unused/hidden fields to flag items

• Perform extraction or operation

No Passing of Data Needed

Daemons – Drop-in Engines

• Adds Complex Functionality by the Addition of 1 VI

• Self Managed or ‘Lite’ Interaction• Similar to Windows Services• Utilizes Multi-Processing CPU

Encapsulate Complexity Within EngineClean Code = Happy Code

Invoking VI’s from others – The What

• Running Code Not Placed as SubVI

• “Dynamically” call a VI– Load VI | Pass parameters | Run VI | Read Result | Close

• In LV, EXE, Across PC, Around World

Invoking VI’s from others – The Why

• Improve performance (memory usage)

• Make design more modular– Ability to share work among team members– Increase scalability of the application

• Create distributed applications• Enable recursion in G• Also…very useful for “release tools” builder

– VI analyzer is a good example

Your Programs are No Longer Limited by Software and Physical Boundaries

Invoking VI’s from others – The How

• VI server Method “Run VI”– Passing parameters through “Set” and “Get” methods (Invoke Nodes)– Ability to run asynchronously : “Wait Until Done”

•VI server Method “Call by Reference”•Passing parameters is direct•Runs synchronously – like a subVI would•Pay Attention to Error Handling

Utilizing the VIt – The What

• Running Multiple Instances of a Same VI…asynchronously

• Dynamic calls to a VIt

• Example:– an application controlling N

similar devices– Pseudo “MDI” Applications

Utilizing VIt – The Why

• Write once, reuse over and over and over …

• Maintenance and growth made simple– Easily expandable to “N+1”

• Maximizes Code Reuse

Easy and elegant…No need to duplicate VIs

Utilizing VIt – The How

• It’s just VI Server…

• “VI Path” Points to a VIt

• Keeping Track of Instances References

Plug-in Architecture – The What

• Software Calls Into Dynamic Framework– Plug-ins Must Match Rules of Framework

• Automatically recognized by the software– Drop new “Plug-In” in a specific directory to

make it available to the application

• Program Extension– Add new features without rebuilding program

Connector Pane

Directory structure

Naming Conventions

Enum b4

Enum aftr

Dirs b4 Dirs aftr

Plug-in Architecture – The Why

• SCALABILITY !• Easily deploy new features• Make Code More Modular• Examples:

– Adding signal processing algorithms to an analysis SW

– Adding support for a new instrument in the “Universal Capture” module presented earlier

ShowCase LV SCC providers

Plug-in Architecture – The How

• Call By reference Node + Strictly typed refnums• Connector assignment MUST be clearly specified (all plug-ins

use the same!)• “Plug-in” directory(ies) so that the SW can automatically scan

available modules

Event Registration & Encapsulation – The What

• Defining Events External to Event Structure

• Handling Events Inside of SubVIs

• Change What is Registered During Run-Time

Event Registration & Encapsulation – The Why

More reactive code• Prevents “Bloated” Case Selectors• Promotes Re-use• Reduces need for wiring

Re-use event action w/out needing to code it into your event structure every time!

Your Code

Event handler

Event

Event Registration & Encapsulation – The How

• Define objects of interest• Get reference to object(s) & wire to registration node• Handle events in same VI or pass registration node ref to sub-VI

– SideNote: Sub-VI may grab object ref from caller

Utilizing Sub-panel

• Everyday unseen Example : LV Options window• Multiple views of same information (Tabular / Pie / Chart)– Reduction of code space & data space

• Single window / Multiple Displays– When switching between multiple windows just won’t do

Caveats and Pitfalls

• Complexity Up Front• Harder to Troubleshoot• Document Paradigm, Not Just Code

• Need Clear Vision of the Future (no crystal ball, just binoculars)

Conclusion

• Spend Time Now and Save a Lot of Time Later• Saves Room on BD and Time Spent Coding• Saves Memory• Lets You Create Dynamic / Flexible Displays• SMRS ( scaleable, modular, reusable, simple)

Always Think“What If I Need to Add 1 More”

Questions? Maybe answers…