DQMH Module Layout Help - create 2 motor modules or 2 control modules?

[Matt_AM]

Hey Fancy Folk,

I'm looking for some project layout help regarding my DQMH modules.  Long story short, I work with motors and I want to create a generic motor template.  The issue I'm running into is how to design the controls for the motor module.  Below is an image of my basic module layout and then ill talk about what my I'm planning on doing.  Since I am relatively new to DQMH, I wanted to see if there are better options than what I am going to do.

So when it comes to motor controls, I typically am either using a brushed DC motor, which is controlled by an H bridge and 3 DIOs, or a brushless DC motor, which is controlled by ignition and CAN messaging.  Ideally I'd like a "controls module" to handle the coms between the brushed and brushless, but the problem I am seeing is that they are too different for control.  So I'm thinking about making 2 different motor modules, a brushed and a brushless which would take away the need to force the 2 controls schemes into 1 controls module.  

As for the modules themselves, I want each to be independent so I can drop them where ever. However, I am thinking about using project templates to create the dependencies between the.  I was thinking about having 2 different project templates (brushed and brushless) which would include the other required modules (Log, PS, and Feedback) and basic message passing (feedback -> motor, motor checks if its supposed to log and if so, motor -> log).  My logic is that the project template would handle the majority of the generic code passing messages, thus creating dependencies, but the modules themselves wouldn't have dependencies between them.  

if there's a better option out there, I'm all ears.  Like I said, I'm trying to get into DQMH and do some more project based stuff vs individual modules.

Thanks,

Matt

Additional thought process regarding 2 motor controls instead of one:

I was originally thinking about making 1 "large" controls module but I shyed away from that because I was afraid that I'd need to have 2 vastly different functionality in 1 module which would create 2 different API's for the brushed and brushless controls which would then clog up the module itself.  I think that having each module do 1 specific job is more the route I want to go.  I understand at some point the developer would need to know the proper order to use the module, I just want that to be as easy as possible. 

[Ozfarmboy]

I would consider whether a class hierarchy for the different controls types and the different feedback types would be feasible.

In other words, your Controls module would then use an OOP HAL to decide whether you'll be using brushed or brushless control type.  You would have a class for each, with a parent class (or perhaps interface) called Controls

Then you could do the same for your Feedback module. The feedback module would then use an OOP HAL to decide whether to use XNET or Analog.  You would have a class for each, with a parent class (or perhaps interface) called Feedback.

This is how we've done quite a few of our device or instrument modules.  ie.  We have a module that needs to talk to a range of weigh balances, so we've created a class hierarchy to handle the different vendors, and products.  Adding a new child class is easy, and means the DQMH module is unlikely to change.

[Matt_AM]

Ozfarmboy,

---

@Ozfarmboy wrote:

I would consider whether a class hierarchy for the different controls types and the different feedback types would be feasible.

---

This is what I'm trying to figure out.  From my current point of view, I don't think it'd be worth it without making this complciated.

In other words, your Controls module would then use an OOP HAL to decide whether you'll be using brushed or brushless control type.  You would have a class for each, with a parent class (or perhaps interface) called Controls

---

This is where my lack of knowledge is showing.  I'm not sure how I'd create a HAL for my controls.  The only way I can imagine having an OOP based controls is having something like multiple initialization requests with "different APIs" for the brushed and brushless motor (see picture below).  But if I'm going down that route, why not just make 2 different controls templates vs having 1 controls template and "2 APIs"?  

If I'm using jargon wrong, please let me know. I'm sure my UML diagram is waaaay off (just meant to be a rough visualization of what I am trying to say), I don't come from a CS background so going into OO and what not has been interesting to say the least.  I get high level concepts but understanding how actual design patterns are built doesn't make the most sense to me.  I've been trying to use this to help me implement design patterns.

Thanks,

Matt

[Ozfarmboy]

OK, so they are quite different, so the classes don't give you the benefits there.

Unless you made the commands more generic? ie. "Setup motor", where the brushed and brushless have very different approaches?  The interface could be a variant which converts into a list of parameters.

Would be interested to hear what others have to say.

[Dhakkan]

Hello Matt,

This post by Tom McQuillian gives some implementation ideas as hinted by Christopher. I found the post by doing a search for 'object oriented programming' in the forum. The key here is abstraction: Define the objects and methods according to what your application needs.

For object oriented analysis and design, SOLID principles are helpful. This time, I did a Google search for 'LabVIEW SOLID principles' and found this forum link. The references therein may guide you well.

Additionally, if you use LabVIEW 2020 or newer, you can leverage these principles more effectively via LabVIEW interfaces.

[Matt_AM]

---

@Ozfarmboy wrote:

Unless you made the commands more generic? ie. "Setup motor", where the brushed and brushless have very different approaches?  The interface could be a variant which converts into a list of parameters.

This is the sticky wicket.  Giving more details about the differences, the brushed is controlled by 3 DIOs while the brushless is controlled via CAN and can be set into current, speed, or position mode.  To me, these are 2 radically different operation control modes that I can really shove into 1 design style DQMH module.  At this point, I feel like it'd be easier to have a servo/brushless motor controls module than a brushed/brushless module.

Digressing to an earlier comment I made, have you done project templates with a bunch of modules in them?  I think that would be a good way for me to keep my modules dependency free while creating the dependencies via the project templates.  An example being feedback module broadcasts to main module which broadcasts to log module.  This way, feedback and log won't have direct dependencies but are loosely coupled via main module.

@Dhakkan wrote:

This post by Tom McQuillian gives some implementation ideas as hinted by Christopher

Yeah, I've seen Tom's videos and I like them.  I was watching his AF videos a while back and I think he does a good job at breaking down things into manageable chunks and did a good job of explaining the "behind the scenes" of AF. I saw that he did a DQMH one in 2020 during the virtual NI week.

One of the biggest issues that I've ran into trying to figure out OO is how to implement the core concepts of design patterns in LV.  There are a bunch of high level "here's simple examples to get you thinking in OO and what this pattern is supposed to do" and not any "real world down and dirty, we ran into these problems with this design and here's how we dealt with it" posts.  Which I get, its time consuming to document that sort of stuff and can show too much of "how the sausage is made".

 Matt

Edit: strikethrough.

[Dhakkan]

---

@Matt_AM wrote:
This is the sticky wicket.  Giving more details about the differences, the brushed is controlled by 3 DIOs while the brushless is controlled via CAN and can be set into current, speed, or position mode.  To me, these are 2 radically different operation control modes that I can really shove into 1 design style DQMH module.  At this point, I feel like it'd be easier to have a servo/brushless motor controls module than a brushed/brushless module.

If your top level UI is the controller itself and nothing else, then you could consider making a sub-panel in the main UI. This sub-panel would be populated with a dynamic-dispatched 'controlPanel.vi' method, defined for each motor variant. This VI would expose the variant-specific controls and indicators. The actual closed-loop control algorithm can and should remain private to each variant. The rest of the main UI module could take care of other things (power supply, logging, etc.). NOTE: This is not a best practice, from the standpoint that the motor's UI is tightly coupled with its business logic. As your experience with OOP grows, you can decouple the UI part into a separate class and re-define class associations.

On the other hand, if control mode, etc., is to be manipulated behind the scenes, like in a test script, then you'll need a different design based on specific requirements thereof.

---

@Matt_AM wrote:

One of the biggest issues that I've ran into trying to figure out OO is how to implement the core concepts of design patterns in LV.  There are a bunch of high level "here's simple examples to get you thinking in OO and what this pattern is supposed to do" and not any "real world down and dirty, we ran into these problems with this design and here's how we dealt with it" posts.  Which I get, its time consuming to document that sort of stuff and can show too much of "how the sausage is made".

---

For me, the original Gang of Four book was hard to follow. And, as you rightly stated above, the examples provided in other sources helped with understanding, but not directly in practice. What helps me (ongoing process) is to come up with a design that satisfies the requirements. Later on, I recognize the pattern applied. With my competency improving, in limited situations, I am able to name the pattern while designing an application. I read and re-read (present tense): Head First Design Patterns book and Refactoring Guru online. Sam Taggart's blog also has informative content and links.