1 / 38

Five Techniques for Better LabVIEW Code

Five Techniques for Better LabVIEW Code. Peter Blume President peter.blume@bloomy.com. Overview. Introduction Five techniques with examples Specifications Data flow State machines Error handling Documentation Conclusion. Introduction.

jaden
Télécharger la présentation

Five Techniques for Better LabVIEW Code

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Five Techniques for Better LabVIEW Code Peter Blume President peter.blume@bloomy.com

  2. Overview • Introduction • Five techniques with examples • Specifications • Data flow • State machines • Error handling • Documentation • Conclusion

  3. Introduction • Most LabVIEW applications begin with an industrial measurement and/or control challenge • LabVIEW facilitates fast development cycles • Easy to connect and control instrumentation • Fast solutions to industrial challenges • Instant gratification for developers • LabVIEW developers adopt fast habits • Sloppy wiring • No documentation • Computer science fundamentals are ignored • Fast habits = bad habits

  4. Justifying Bad Habits • LabVIEW is a graphical language • Computer science fundamentals don’t apply • Block diagram is self-documenting • We don’t have time to write good code • Intense time pressures • LabVIEW is a secondary responsibility • Requirements continuously change • Equipment availability constraints • I’m the only developer / end-user • Nobody else needs to use or understand my programs

  5. Issues Resulting from Bad Habits • Application requirements expand • LabVIEW code becomes messy • Inefficient • Buggy • Difficult to troubleshoot, expand, and maintain • Not reusable • Overall development time is increased

  6. Bad Code Example

  7. Good Code Example

  8. Let’s Write Better LabVIEW Code! • Follow these five techniques • More up-front time and effort • Attention to detail • Discipline • Dramatically save time in the long run

  9. 1. Write a Functional Specification • Understand the application’s requirements • Interview operators, developers, engineers, managers, bean counters • Document the requirements • Statement of high-level objectives • Specific requirements for I/O, analysis, GUI • Timetable and budget • Design prototype screen shot • Assign priorities to each requirement • Test methodology

  10. Functional Specification (Continued) • Avoid designing the system • Don’t prolong specification phase by including too much detail such as how to implement the system • Make the specification readily accessible • Have all contributors review and approve • Revise when requirements change • Keep it somewhere that you and others can quickly reference it

  11. Simple Specification Example

  12. Bad Code Example

  13. Good Code Example

  14. 2. Use Proper Data Flow • Data flow definition: “A block diagram node executes when all its inputs are available. When a node completes execution, it supplies data to its output terminals and passes the data to the next node in the dataflow path.” • Parallel paths are permitted and desirable • Efficiency is optimized when LabVIEW determines the execution order • Readability is optimized when source terminals, wires, and destination terminals are visible

  15. Data Flow Impediments • Sequence structures • Excessive nesting • Local and global variables • Coercions • Sloppy wiring • Excessive bends • Overlapping wires with other objects • Multidirectional data flow

  16. Impeded Unnecessary sequence Coercion Local variables Simple Data Flow Example Better data flow

  17. Bad Code Example

  18. Bad Code – Zoom In on Wiring

  19. Data Flow Enhancements • Artificial data dependency • Use error cluster and/or task ID • Shift registers • Reduce local and global variables • Clusters • Reduce the overall number of wires • Neat wiring • Left-to-right data flow • Straight wires • Consistent data types • Comments with “>” indicating data flow direction

  20. Good Code Example

  21. 3. Use a State Machine Top-Level Architecture • Define application as a series of states • Go to any state from any other state • Easy to modify, maintain, and debug • Self-documenting • Scalable

  22. Classic State Machine

  23. State Machine Enhancements • Use enumerated or string for case selector • Poll user interface events in “No Event, Default” frame or in separate event structure in parallel loop • Use intuitive state names • Include “Initialize” and “Shutdown” states

  24. Enumerated State Machine

  25. Event-Driven State Machine

  26. 4. Incorporate Proper Error Handling • Trap and report any I/O related errors in all VIs • I/O functions include DAQ, file I/O, instrument I/O, communication • Trapping is facilitated by propagation of error cluster • Reporting methods include dialog prompt or log to file

  27. Error Trapping

  28. What’s Wrong With This Picture?

  29. Better Error Handling

  30. 5. Document Your Source Code • Assume every VI will be used and maintained by other developers • Best time to document your source code is while you develop it

  31. LabVIEW Documentation Techniques • Control labels • Use succinct, intuitive labels • Indicate units in parentheses or use free labels • Enter descriptions or online help where further text is needed • Icons • Intuitive text or graphic • 10-point small fonts • Color-coding for icons of related subVIs

  32. Documentation Techniques (cont’d) • Diagram • Leave the background color white • Set all control labels visible • Liberally document with free labels • Enter descriptions for every subVI

  33. Bad Code Example

  34. Good Code Example

  35. Summary • Write a specification for all projects before you begin coding • Use proper data flow • Use a state machine top-level architecture • Incorporate proper error handling • Document your source code while you code

  36. Conclusion • Techniques improve: • Readability • Robustness • Efficiency • Maintainability • Reusability • Techniques can be implemented quickly if you make them habits • Apply to every project, starting now • Apply consistently throughout each project • Dramatic reduction in overall time and effort

  37. About Bloomy Controls • Test, measurement, automation, and control specialists since 1991 • Systems integration, software development, and training provider • NI Select Integrator and Certified Training Center • 3 Certified LabVIEW Architects • 8 Certified LabVIEW Developers • 1 Certified TestStand Architect • 2 Certified TestStand Developers • 8 Certified Professional Instructors • Offices in Windsor, CT; Milford, MA; and Mahwah, NJ

  38. Contact Bloomy Controls • Email info@bloomy.com • Write or visit

More Related