1 / 23

St. Louis LabVIEW User Group

St. Louis LabVIEW User Group. How to Choose an Architecture June 21 st 2011. Terminology. C. So what is a design pattern in LabVIEW?. Basic design patterns that ship with LabVIEW Advanced design patterns Object oriented design patterns New design patterns that emerge over time

goro
Download Presentation

St. Louis LabVIEW User Group

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. St. Louis LabVIEW User Group How to Choose an Architecture June 21st 2011

  2. Terminology

  3. C. So what is a design pattern in LabVIEW? • Basic design patterns that ship with LabVIEW • Advanced design patterns • Object oriented design patterns • New design patterns that emerge over time • So why do we need advanced design patterns?

  4. A. Use Cases – Laboratory • Can range from very simple to very complex • Are sequential in nature or process oriented • Are more likely to leverage express VIs • Can require a basic framework that is easily modified for a variety of similar tests

  5. B. Use Cases – Test • Are often sequential in nature • Typically have a very simple and intuitive user interface • Need high level executive code (perhaps Test Stand) to coordinate test execution • Necessitate flexibility for exchanging instrumentation • Use a methodology to set and modify limits and other configuration information • Could require several vehicles for logging data (file, database, Web) • Can require extra design effort when the use case demands parallel testing

  6. C. Use Cases – Process/Distributed • Include many asynchronous processes • Require a clearly defined messaging system • Involve processes or services which provide data to multitudes of clients • Are potentially distributed across a network

  7. What is the big picture? UI.vi DAQ.vi QDSM QDSM QDSM QDSM Error.vi Report.vi

  8. A. Introduction Let’s see, should I use functional global variables or single element queues? I used functional globals before, so I’ll use them again. Get the right tool for the right job!

  9. What happens to data? • Fundamentally, five things happen to data in LabVIEW.

  10. How might the application change? You cannot account for every potential change

  11. Other Important Considerations

  12. State Machine • Actions may be invoked by a person, a remote system across TCP/IP, a database, another VI, or some other mechanism. We are architecting for multiple processes. Initialize Get TCP Msg Handle Error Action 2 TCP Init Send TCP Msg Handle Error

  13. Enum or String? • Enums • Seamlessly connect to the case structure such that there are no typos. • Facilitate adding cases. • The architect can distribute the type def enum and QDSM to the developer. • String • The QDSM template can have a case in the structure that handles potential typos. • Strings facilitate integration with other functions that use strings such as Run Time Menu Tags and TCP/IP VIs. • Strings are a universal data type that is recognizable outside the LabVIEW environment. • Strings can be used on the connector pane of subVIs that form part of the reuse library associated with the QDSM. • Can be used to append data with a state change.

  14. One Cluster Shift Register or Many? If you use many: • Easy to view all of the data without having to unbundle or show context help • Important to group them in one location, at the top or the bottom • Now possible to automatically wire the unwired cases Consider doing both!!

  15. Architecture • JKI State Machine • Design your own • FGV / DVR • Obj Oriented

  16. Queue Driven Message Handler – Reusable Components

  17. Functional Global Variables – Benefits • Provideglobal access to data while minimizing potential race conditions introduced by global variables • Encapsulate data so that debugging and maintenance is easier • Facilitate the creation of reusable moduleswhich simplifies writing and maintenance of code • Can pass any kind of data and can enhance a variety of advanced design patterns (such as user events)

  18. Sidebar: Creating and Registering User Events (Review) Note: The label for the User Event Data Type input becomes the name for the user event in the event structure

  19. Sidebar: Improve Flexibility of User Events Being able to pass the reference through a FGV adds flexibility!

  20. Advantages of XControls • Encapsulates UI code into an abstract component • Reduces complexity and increases readability of main block diagram • Removes UI-based restraints from the architecture of the main VI • Abstracts complex code away from standard developers • Creates reusable and distributable UI components • Easily distributable • Updates control instances to new versions while maintaining integrity

  21. B. Design Techniques

  22. Where Can You Go for More Code and Ideas? • Asynchronous Message Communication (AMC) • Specific Error Handler (SEH) • Current Value Table (CVT) • Buffered Variable Table (BVT) • Generic Configuration Editor (xCE) • Multi-Process Engine (MPE)

  23. Where Can You Go for More Code and Ideas? www.lavag.org More Than A Message Board A Community of Avid LabVIEW Programmers A Place to Learn About New Technologies A Place to Shape the Future of LabVIEW

More Related