Advice on use of classes requested

[SimonAldred]

I have an inspection application that captures and processes images and sends the result to a user interface. Each of these tasks is performed in a separate parallel loop. In some factories I have two cameras and in others only one, so the capture loops can be different depending on location. Likewise processing is often dependent on the factory and type of product made. Rather than have different versions of the software for various factories / production lines I would prefer to have one customisable application. Would the best way to achieve this be to make my capturing and processing loops classes and use dynamic dispatch, or are there alternative approaches I should consider?

Thanks

Simon

[Quiztus2]

It largely depends on how much time you're willing to invest in developing your software. LabVIEW shines when it comes to quick, simple applications, such as "I put 3 loops into my main VI and that's my entire app." You can achieve a lot in a short amount of time with minimal knowledge of software development.

Classes are a powerful tool for adding functionality through inheritance or composition, especially for things like graph management. For example, using classes to encapsulate data-related logic in your loops can streamline your code.

My advice is to stick with LabVIEW for as long as possible if your design is simple and fits the "3 loops in a main VI" pattern. This approach aligns with LabVIEW's strengths and intended use. If your needs grow beyond this, frameworks like DQMH, the Actor Framework, or JKI SMO can help guide your development. However, if your application becomes more complex, you should consider whether LabVIEW is still the best choice, as other programming languages may offer a more comprehensive solution.

[Yamaeda]

The easiest would be to control it through an ini-file and simply don't start the 2nd loop or just to nothing in it (with some delay so it doesn't load cpu 100%)

[SimonAldred]

I've considered this. I agree it is an easy thing to implement. It just seems a little clunky. I do use an ini file for setting many of my preferences. It's getting quite large which is why I was thinking of a more elegant solution. If I created a DAQ class with child classes for different capturing options I could imagine that this might work quite well. Likewise for processing. 

[NIquist]

As others have mentioned, LabVIEW OOP has some overhead which makes it less attractive unless you plan to expand/modify your code with new or enhanced functionality in the future.  It's main disadvantage for me is that I never have time to deal with that extra overhead and my company isn't interested in how the code works.  They just want it ASAP.  If I needed to create an overall test sequencer (like TestStand) in LabVIEW, I would definitely go with OOP or Actor Framework though.

There is an excellent example you should check out called Board Testing - Benefits of Object-Oriented Design.  (Help > Find Examples... Fundamentals > Object-Oriented)

It compares images of different PCB boards for wrong component placements using two solutions.  One simple procedural, task-based program, and one that does it with OOP so you can compare.

Don't be fooled by the seemingly simple OOP code though.  Most of LabVIEW's OOP is in the way the classes are set up in the project.  Look at that carefully while you read through the HTML explanation to get a good idea how these paradigms compare.

[Quiztus2]

If I created a DAQ class with child classes for different capturing options I could imagine that this might work quite well. Likewise for processing. 

---

Normally, you don't create different member vi's in order to have different options (parameters). As already mentioned, this is the use case for .ini 

If you are using DAQmx and IMAQdx right now, there is not much benefit from adding them in to classes aswell, since they are already somehow classes-ish. But feel free to share some code or .ini