At the User Group track during this year’s NI Days, engineers and scientists heard from talented LabVIEW software developers discussing the lessons they had learnt from many years of projects implementing solutions with high quality LabVIEW software.
James McNally discussed some of the practical lessons he has learnt, and which he now applies to his software development processes when using LabVIEW Object Oriented Programming.
James’ lessons included:
- Code cannot be too modular
James discussed that most LabVIEW developers when starting with LabVIEW classes will often put too much data in a class. He also noted that many developers may be reluctant to create more small classes due to a perceived overhead in time taken to create a new class. James e gave some examples of using nested classes to simplify logic within classes and to make more reusable code.
- Take a top down approach when designing classes
This is a lesson that we have experienced in our software development team at Metis Automation. When creating modular code, the top level modules should have no details or data from any of the lower level implementing layers.
For example, if a production control application needs to change the state of a machine interlock, actuated via an output on a PLC, the top level production control module should not have any details about the physical output channel on the PLC. That information should be held solely in the module that interfaces with the PLC. The top level production control module should just send a message down to lower implementation layers requesting a change in state of the machine interlock.
By ensuring that no controls or data is duplicated between these layers also ensures that the problem of classes becoming locked can be avoided. Classes become locked when their data is loaded into multiple application instances. For example, on a Windows Host and on a RT controller. A way around this is to ensure that both applications use different controls, and do not share any references, enums or typ defs.
- Learn from others
James recommended learning the language of OO developers in other languages so that LabVIEW developers can learn from their experience and lessons. He recommended Code Complete as a great resource for Object Oriented design and general software development lessons.
- Test, Develop and Refactor
James is passionate about Unit Testing and Test Driven Design, he showed us how his software development process now invokes creating Unit Test code for each of the code modules that he creates. Test Driven Design then takes this a step further, as you are encouraged to create code until your test passes, then go back and refactor your code to remove any unnecessary functions or improve the style of code that you have created.
Following these principles helps you to create software that is modular, easy to maintain and easy to modify.
Simon Carter then discussed client server applications in LabVIEW, using the Asynchronous Call feature at Metis Automation, we typically use the Asynchronous Call to launch multiple User Interfaces in sub panels. Simon’s presentation showed how this feature can be used to launch multiple client listener applications to create a flexible and powerful client server application.
Chris Woodhams finally covered the use of 3rd Party Tools for LabVIEW software development, and focuses on some tool his team’s uses in their software development processes.
Chris had used the National Instruments produces STM toolkit for TCP/IP connections in LabVIEW. This provides LabVIEW developers with a ready to use API that handles connecting to multiple devices across a Ethernet network. It looks like a great tool to speed the development cycle for LabVIEW developers.
Chris also pointed out some useful features in the Open G toolkit, including advanced file read functions and array sorting VIs.
The main benefits of the Tools Network and all of here tools is that it can increase the productivity of your software development team by using already proven and tested code modules.
