06-24-2025 08:09 AM
@Faizan_habib wrote:
I do not understand the plugin architecture? can you please refer me to some documentation which can help? or any example.
Thanks
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kGQWSA2&l=en-IN
06-24-2025 10:59 AM
Thanks Santhosh for providing the Collaterals. I have one more question when it comes to scalability which in my case adding the new instrument driver, would that be easy for a person who is very beginner to LabVIEW or in general programming to add a new functionality in OOP based Architecture.
06-24-2025 11:04 AM
@Faizan_habib wrote:
Thanks Santhosh for providing the Collaterals. I have one more question when it comes to scalability which in my case adding the new instrument driver, would that be easy for a person who is very beginner to LabVIEW or in general programming to add a new functionality in OOP based Architecture.
Good understanding of LVOOP is required to effectively create new classes from template and implement overriding methods.
06-25-2025 03:36 AM
@Faizan_habib wrote:
Thanks Santhosh for providing the Collaterals. I have one more question when it comes to scalability which in my case adding the new instrument driver, would that be easy for a person who is very beginner to LabVIEW or in general programming to add a new functionality in OOP based Architecture.
For a beginner, nothing is easy. 🙂 It is however not any harder than in any other language. Check the examples and tutorials and you'll be fine. 🙂
10-23-2025 02:49 AM
After having strived after "big" HAL, I found that an architecture made out of independent modules is easier to develop and to maintain.
My modules use the DQMH, but other frameworks can achieve the same thing.
For the instruments I create "type-specific" cloneable modules with a shallow hardware abstraction layer, which supports a limited amount functionality - to keep it SOLID and include what is actually needed, but with the possibility for easy refactoring, if necessary.
For example I would create a cloneable Power-Supply module, with an API that should handle most common power supplies functions (like 1-4 channels, set current/voltage, set limits, get current/voltage). Inside the module I create an abstract class which implements the functions. For each actual power supply I want to use I create a child class with the actual implementation of the function.
When I start an instance of module I select which class I want to use and connect to the supply - the class knows what connection type (Ethernet, USB, etc) it uses, the module doesn't need to.
That can be done for all kind of instruments. If an Instrument is a bit more special, I have a DQMH template to quickly create its own module. The scripted tester in DQMH also allows for simple standalone testing of an instrument. The class abstraction allows you to create a simulated instrument, so you can unit test your module or even test your application without hardware.
On your question, what would be easy for a beginner - if you provide a template (or use the clone class tool from OpenGDS) with the functions which need to be implemented, it should be easy. They don't need to know LVOOP and neither how the DQMH module works, but they can use the module and the tester to simply test their implementation.