The Art of Creating Dynamic, Flexible LabVIEW Applications

1. The Art of Creating Dynamic,Flexible LabVIEW Applications Norman Kirchner CLD, CPI – Texas Instruments Gerald Albertini CLD – Texas Instruments August 10, 2006

2. ‘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?

3. Measurement Library – Adding Instrument Done Once

4. The Art at Work Test Module • Universal Instrument Configuration & Control • Drop-In “Brat Code” • Daemon – Background Engine • Calling into Other VIs • VIt Usage • Plug-in Architecture • Sub-panel • Callback Sub-Panel Config.vit Data Instrument Configuration Instrument Configuration Instrument Driver Instrument Driver Instrument Configuration Instrument Driver

5. 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

6. 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

7. 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.”

8. 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

9. 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 Engine Clean Code = Happy Code

10. 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

11. 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

12. Invoking VI’s from others – The How • VI server Method “Call by Reference” • Passing parameters is direct • Runs synchronously – like a subVI would • Pay Attention to Error Handling • VI server Method “Run VI” • Passing parameters through “Set” and “Get” methods (Invoke Nodes) • Ability to run asynchronously : “Wait Until Done”

13. 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

14. 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

15. Utilizing VIt– The How • It’s just VI Server… • “VI Path” Points to a VIt • Keeping Track of Instances References

16. Plug-in Architecture – The What Connector Pane Directory structure Naming Conventions • 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

17. 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

18. 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

19. Event Registration & Encapsulation – The What • Defining Events External to Event Structure • Handling Events Inside of SubVIs • Change What is Registered During Run-Time

20. 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 Event handler

21. 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

22. 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

23. 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)

24. 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”

25. Questions? Maybe answers…