Over its nearly 40-year lifetime, LabVIEW has become the go-to option for test and measurement engineers in a variety of industries. In fact, the National Instruments (NI) software and hardware platforms have become so synonymous with the test and measurement space that many full-stack applications are built from the ground up only using G (the formal name for the LabVIEW programming language).
So, what happens when you cross laboratory-style benchtop testing with traditional application development? In some cases, the code can resemble tangled spaghetti.
Yeah… a little tough to understand what’s going on here.
There are numerous ways to improve the cleanliness of this block diagram: type defined clusters, subVIs, or general wire cleanup. Implementing Object-Oriented Programming (OOP) is another useful way to improve the readability of block diagrams.
Using OOP can improve cleanliness, but there are even more benefits that are typically overlooked during discussions of aesthetics. Considering it is a programming paradigm for designing applications, why not discuss OOP in the context of design?
Application Design
What do we as developers consider when designing an application?
Collaboration: How many developers will be working on this project?
A development process for one to two developers will look considerably different than a project with 30 developers. LabVIEW VIs are stored in binary, making code merges notoriously difficult when developers conflict.
Budget: How much time can be allocated to spend on the project?
Like it or not, every project is limited by time or money. A flexible budget allows for thorough design and the development of internal tools for the project.
Scope: How much code needs to be executed synchronously? Asynchronously?
For single use applications, the fixed development time of setting up a producer-consumer loop is perfectly acceptable. For complicated applications, creating templates with reuse code can drastically reduce setup time.
Scalability: Does this code need to be scaled for future feature requests?
Will the end user request more features in one month? Six months? Six years? The same way factories produce goods with better margins in economies of scale, programming can be more efficient with scalable designs.
Benefits of OOP
So, when does OOP make sense?
To be blunt, using OOP is not all or nothing. A simple hardware abstraction layer can be helpful for almost any project. Beyond hardware, the use of OOP depends on the design considerations already mentioned.
Significant Collaboration
Leveraging effective abstraction layers, polymorphic behavior, and encapsulation can make parallel development easy and data safe. Additionally, the binary nature of LabVIEW VIs makes merging conflicts arduous. OOP implementations can prevent conflicts.
Flexible Budget
This goes without saying, but time should always be budgeted for code design. Done effectively, the upfront cost of base classes, abstract classes, and generic architectures can pay off in the long run.
Complex App Scope
Class-based templates can drastically reduce reuse code, especially for asynchronous module lifecycles. Although effective templates are not 100% unique to OOP, it is a great tool for the job.
Future Scalability Important
Building architectures with generic “plug and play” classes offer more flexibility in the support phase. If a base class does not cover the functionality required for a new device, use inheritance to create a child class and only override the relevant methods.
Pitfalls of OOP
Why not always use OOP?
Easy, it doesn’t apply to every project, tester, application, or student assignment out there. Time is limited. The reality is, designing a class structure and architecture is not always practical for small or low-budget projects. Committing to one framework also requires all team members to be familiar with and trained in these non-trivial concepts.
At the end of the day, clean code is organized and planned before implementation. If organized well, functional programming can be just as effective as OOP and less complicated. Non-OOP paradigms can organize code effectively but can come at the tradeoff of individual developer responsibility. OOP forces some resemblance of organization before, during, and after active development. Left unorganized, LabVIEW code gets ugly quick (literally).
Final Thoughts
Like any tool, context matters. A drill does not make a great hammer, nor does a hammer imbed straight screws. The same applies to programming. If you find yourself struggling with organizing your code, conflicting on collaboration, or scaling your applications: OOP can be a great tool for your toolbelt. Otherwise, functional programming can be just as effective for small scale Test and Measurement applications.
Ready to take your Test and Measurement project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals.