Post on 20-Jan-2016
description
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…