Architecture to allow modular software design

[johntrich1971]

I agree with Matt. I don't believe that a single, monolith program is appropriate for the application as I understand that philipp_htr needs. The plugin architecture that he described is much more appropriate.

[RTSLVU]

---

@johntrich1971 wrote:

I agree with Matt. I don't believe that a single, monolith program is appropriate for the application as I understand that philipp_htr needs. The plugin architecture that he described is much more appropriate.

---

LOL: well good luck with this requirement:

@philipp_htr wrote:

different required software modules can be generically integrated (by the user, not the programmer) without additional programming effort.

---

One properly written program will do all that seamlessly when the end user selects the tests that need to be ran 

[RTSLVU]

Or you could just use Test Stand

[RTSLVU]

Also making one program that can run on multiple instrument configurations in very similar. I  maintain several ATE systems, as much as we have tried to standardise our test racks over the years.

No two systems are exactly the same. But they all run exactly the same program 

Here is an example of how I did it, for instance there can be any one of three different DC sources (or none) in the system

1. None
2. Sorensen DHP series
3. Sorensen SGI series
4. Agilent 8700 series

My "DC Source Voltage vi" contains all the code for every possible DC source in our systems and the proper code is chosen by reading a configuration file at the start of the program.

No DC SourceSorensen DHP DC SourceSorensen SGI DC SourceAgilent DC Source

[philipp_htr]

@RTSLVU 

Thanks for your code suggestions and of course you are right for the case that we do not want to extend the amount of modules in the future.

But this is one important requirement I did not mention in the beginning. We do not want to re-program the main-code and rebuild it afterwards, we simply want to add a module by programming this one, based on a module template. This is not important for the user, because he chooses from available modules, but it's important for the programmer. This is the reason, why our first approach was the Plugin-architecture. I hope it's more understandable now.

Yes, Test Stand would match the requirements but we want to do this on our own.

@Jacobson

Yep, that's it! Are there ways that you can particularly recommend here? Especially, for the build process of the modules? Actually I think the best solution is the use of packed libraries for the modules, but I'm quite unsure. 

And well sorry, I'm not really used to the citation function yet.

[johntrich1971]

If you're really wanting code that can perform new functions then a plug-in approach where vi's are called dynamic is the best solution. The main program has to be carefully planned so that there's no dependence upon data being passed between modules. Each module would then know how to handle the data that it receives.

if you're trying to do something more like RTSLVU but want to be able to change hardware then an object oriented approach will work. Rather than write new code in the main you write a new child object and select that object from the main.