Jump to content

Any reccomendation for tools to get started with OOP?


Recommended Posts

Hey all,

 

I want to start my first big design in LV with OOP by laying out and designing a motor class.  I was wondering if there are any tools that I should look into to help me with the process.  I've built a power supply class which is basically an abstract factory where all the children create the concrete classes. I am still trying to understand a lot of the different architectures/design patterns from the LV forums but am getting a better understanding each time I go through them again.  My biggest issue I can see is having child classes return different data types without it getting overly complicated (any suggestions on designs on this front are more than welcome).

 

Digressing back to the original question, As of right now I am looking into GOOP, but its occasionally crashing LV 2015.  It seems like theres some good stuff with GOOP, but the lack of documentation is a bit rough to slog through.  I was wondering if you fine folks could recommend any tools for me to look into as well. 

 

I'm sorry this is a generic request, but I don't know what I don't know.

 

Matt

Link to post
Share on other sites

Factory is a good way to create your instruments but you probably want one factory for all instruments rather than one for each type. That way you only pass the parent (abstract) reference around, which makes it easy to swap out one concrete instrument for another of the same type. Returning different data types from classes of the same instrument type is something you don't want. When designing your classes, you should already know what kind of data you expect that class structure to handle and all instruments of one type should be able to put their data into that one given format.

Maybe @MikaelH can throw the Introduction to OpenGDS pdf your way. I can't find it.

 

Link to post
Share on other sites
18 hours ago, Matt_AM said:

My biggest issue I can see is having child classes return different data types without it getting overly complicated (any suggestions on designs on this front are more than welcome).

You need see past your specific motor types to think what your generic motor needs to do.  Is it returning configuration info?  That can be JSON, rather than a typed cluster.  Or a Variant, or an object of a "config" subclass.

My advice is to NOT learn OOP with a Motor Parent class unless you have enough experience with different motor types so that you can form a solid view of what a generic motor does.  

Link to post
Share on other sites

@MikaelH Thanks for the links good sir, I appreciate it!

 

@ThomasGutzler What do you mean by "Returning different data types from classes of the same instrument type is something you don't want."?  I'm assuming you mean something like use the parent "Power Supply" object for my connector panes and define the child (such as TDK Lambda) during the initialization section of my test.  This way the if I wanted to change the PS from TDK Lambda to say Sorenson, all I'd have to do is change the test's initialization section since all my connector panes are using the Power Supply parent class in their connector pane.  If this is the case, I am doing that already, I may just be bad with my vocabulary.

 

@drjdpowell Fair point, learning to walk makes running a lot easier.  I guess what I am currently trying to do is define my end goal and figure out the different steps along the way.  Then start working on the individual steps to build up to my end goal.  Like for a generic motor (in my case) I'll need a power supply class and CAN communication class as my main two classes along with some other private methods/data (ignition task and methods, motor info, stuff like that).  As far as the CAN coms, I am actually running into a bit of an issue trying to figure out how exactly I want to lay it out.  I'm using XNET and I'm trying to figure out how I should handle having things like single point signal/frame as well as queued signal/frame.  If I go down the splitting out all of those into their own child class, then I'm going to have 4 child classes for my basic XNET write class.  OR I could try and go into a strategy pattern where the XNET class has some other class information that contains how the data is supposed to be written (something like the CookingStrategyPattern from here.)

 

Thanks all for responding, I appreciate the help!

Link to post
Share on other sites
On 11/20/2020 at 5:30 PM, Matt_AM said:

 

@ThomasGutzler What do you mean by "Returning different data types from classes of the same instrument type is something you don't want."?  I'm assuming you mean something like use the parent "Power Supply" object for my connector panes and define the child (such as TDK Lambda) during the initialization section of my test.  This way the if I wanted to change the PS from TDK Lambda to say Sorenson, all I'd have to do is change the test's initialization section since all my connector panes are using the Power Supply parent class in their connector pane.  If this is the case, I am doing that already, I may just be bad with my vocabulary.

I think what Thomas meant is that if you are going to use Dynamic Dispatch (DD) then you are forced to have the same data type as the connector pane of the concrete DD VIs all have to be identical. If you already have something working its probably ok. As an example you cannot have Instrument 1 return an array of DBL and Instrument 2 return an array of SGL for a "Read.vi".

Edited by Neil Pate
Link to post
Share on other sites
On 11/21/2020 at 2:30 AM, Matt_AM said:

 

@ThomasGutzler What do you mean by "Returning different data types from classes of the same instrument type is something you don't want."?  I'm assuming you mean something like use the parent "Power Supply" object for my connector panes and define the child (such as TDK Lambda) during the initialization section of my test.  This way the if I wanted to change the PS from TDK Lambda to say Sorenson, all I'd have to do is change the test's initialization section since all my connector panes are using the Power Supply parent class in their connector pane.  If this is the case, I am doing that already, I may just be bad with my vocabulary.

What Neil said. Looks like you've got it worked out.
The hardest thing to get your head around is the factory instrument creation. This is the only place where you might not use dynamic dispatch to call instrument specific vis containing their specific configuration. But as @drjdpowell said, you can use JSON for that.

Link to post
Share on other sites

Just be really careful if you intend to used packed libraries. Start building the exe & ppls now. It is not trivial. It's of limited use if it can't be deployed.

 

This is the best documentation I've found yet.

Effectively_Using_Packed_Project_Libraries_SEPAD.pdf ‏2772 KB
https://forums.ni.com/t5/NIWeek-Session-Content/Software-Engineering-Processes-Architecture-and-Design-nbsp/ta-p/3929895?profile.language=en

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.