Creating and Managing Reusable Code in LabVIEW

1. Creating and Managing Reusable Code in LabVIEW Wes Willis Field Sales Engineer- NM

2. What do we mean by “Reusable?” Scalable—Easy to add functionality to a VI without completely redesigning the VI Readable—Easy to visually inspect the design of a VI and understand its purpose and functionality Maintainable—Easy to change a VI without affecting the intent of the original VI

3. Scalable VIs • Scalable design easily allows modifications to original design Data Acquisition VI that acquires data from one thermocouple Data Acquisition VI that acquires from any number of thermocouples Data Acquisition VI that acquires thermocouple data Data Acquisition VI that acquires any type of data

4. Readable VIs – Poorly Designed Code

5. Readable VIs – Well Designed Code

6. Maintainable VIs • Allow you to add new features without completely rewriting the application • Use good program design and architecture • Are designed with the understanding that other programmers may need to use and modify your code

7. Business Benefits of Reusable Code • Faster time to market • Consistent quality • Consistent implementation across developers • Transfer ease • Reduction of software defects - Less support $$

8. Agenda • Scalable Architectures • Strategy for Designing an API • Icons & Documentation • Maintaining Reusable Code • Distributing Reusable Code Scalable Readable Maintainable

9. Creating Reusable Code Scalable architectures

10. Basic Architectures State Machine > Producer Consumer > < Event-Driven

11. Queued Message Handler • Producer-consumer, events and state machine combined • Receive and process messages generated by events • Events can be triggered from UI, or other communication interface • Each message will perform an action

12. Queued Message Handler • Event Structure Handle UI and trigger messages • State Machine Process messages • Queue Send messages to State Machine • User Events Feedback to Event Structure

13. Queued Message Handler • IMAGE!!!! (And Demo) Demo: Queued Message Handler

14. Functional Global Variable • Also known as: • FGV • LV2 Style Global • Action Engine • Etc. • Stores data in an uninitialized Shift Register • Performs multiple tasks using the same stored data

15. Basic Functional Global Variable Demo: FGV - Basic

16. FGV in a Large Application • Performs all module functions • Store references, shared data, etc. • Encapsulates low level functionality from user

17. FGV in a Large Application Demo: FGV – File IO

18. Subpanel Plugins • Run different Front Panels within main VI • Scalable: easily add another VI • Flexible: UI Can be anything that fits within subpanel • Modular: VIs independently coded and tested • Simple: may not need communication to main VI

19. Subpanel Plugins Demo: Subpanel

20. Asynchronous Processes • Run VIs in parallel • Calling VI does not need to wait • Can dynamically spawn any number of the same process • Useful for Background tasks • Examples • Auto-save • Archive data • Garbage collection

21. Asynchronous Processes Demo: Asynchronous Processes

22. Object Oriented • Use dynamic dispatch in the Command Pattern to avoid predicting data types • Use class hierarchy in the Factory Pattern to automatically execute correct functionality • Many more…

23. State Machine vs. Command PatternThese diagrams represent functionally equivalent code

24. The Basics of an Object Factory A B Objects Loaded Into Memory C Generic Plugin  Parent Location on Disk Where Plugins are Stored A B C  Children

25. Creating Reusable Code Strategy for designing an API

26. What is an API? • Application Programming Interface • Public functions used to programmatically call code that you or someone else wrote. • Group of SubVIs that all access the same set of underlying code

27. API Considerations • Simplicity • Consistency • Adaptability • Usability

28. API Simplicity • Make it simple • But offer optional advanced functionality Most Common Functions Advanced functions

29. API Consistency • Icons • Connector Panes • Data Types • Naming

30. API Adaptability • Plan for future expansion and change to the API • Use typedefs so changes to enums and clusters update throughout • Leave empty connector pane terminal for future possible controls/indicators • Ensure future additions/changes won’t break existing code • i.e. renaming VIs, rearranging connector panes, etc.

31. API Usability • Logical organization of palettes • Intuitive functions • Helpful names of functions and inputs • Well-Documented

32. Creating Reusable Code icons

33. Brand Your API

34. Think About Functionality

35. Don’t Reinvent The Wheel

36. Use Color Wisely vischeck.com

37. verb object Be Consistent Add Network Device

38. Icon Tools / Resources LabVIEW Icon editor Axialis Icon Workshop Corel Paint Shop Pro ni.com/iconlibrary LabVIEWPartnerProgram@ni.com eTrainings at ni.com/addondevcenter

39. Creating Reusable Code Documentation

40. Why Is Documentation Important? • Documentation is a code feature • Supplements the software • Adds credibility to your code • Reduces number of support calls • Meets Compatible with LabVIEW requirements

41. What Kind of Documentation is Important? Goal: Answer “pre-use” questions Useractivities • Goal: Provide in-product support for features

42. In-Product Support—Context Help Answer for users,“Does this fit my use case?”

44. In-Product Support—Context Help VI descriptions NOT “Acquires data.”

45. In-Product Support—Context Help “Returnstwo arrays that describe the magnitudes and angles of obstacles the device detects within a given range.” VerbOutput(s)Input(s)”

46. In-Product Support—Context Help Input/output descriptions • Provide units in which values are expressed, default values, error information • NOT “timeout is the time to wait for a response.” • INSTEAD “timeout (ms) sets the amount of time to wait for a response from the host. If timeout (ms) elapses, this VI returns error code 5. If you set timeout (ms) to -1 (default), this VI waits indefinitely.

47. In-Product Support—Detailed Help • Cross references to relevant examples • Error codes VIs can return • Screenshots of workflows

48. In-Product Support Solution: Context help + HTML Help • Use tools from NI Partner team to populatecontext help and generate detailed HTML help • ni.com/addondevcenter

49. Where to Go from Here • ni.com/addondevcenter • Readme HTML file template • VI Properties Editor tool • VI to XML tool for creating HTML Help • Notepad++, KompoZer—HTML editors (free) • FAR—Compiled HTML Help (CHM) editor (purchase) • http://helpware.net/FAR/ • Requires Microsoft HTML Help Workshop (free)

50. Managing Reusable Code Source code control