LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Include SubVIs inside Class Methods - LVOOP

Hi dear community, recently I have started to use more often LVOOP. I have indentified some design patterns and I am using some of them. However I have a doubt about a best practice. Normally I group my VIs, routines like array operations (Delete values, convert 1D to 2D array, etc) are inside LVlibs.

 

When I build a class where I need to perform one task that is included in the LV library I call the Library SubVI inside the method, is it a good practice or any VI that is called inside the method must be a method of the LabVIEW class?

 

I will appreciate if you can share the approaches that you use, thanks in advance.

0 Kudos
Message 1 of 8
(2,365 Views)

I think that is a good approach.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 8
(2,357 Views)

There is nothing wrong with calling SubVIs from external libraries inside class methods. Just be aware of your dependency management - ensure you aren't creating circular dependencies, and do your best to minimize external dependencies when possible/practical. 

Message 3 of 8
(2,353 Views)

I generally use the approach that if a subVI inside a class takes in a class wire as an input, it should almost always be a member of that class.  Very few exceptions.

 

If it doesn't take a class wire as an input, then I look at functionality.  If it's something that will only ever be relevant to this one class or its descendants, it gets put in the class.

 

For anything else, there's really no problem putting it in a library.  I would in fact recommend it in most cases, because duplication of code is generally a bad thing.

 

The only other reason I could think of to not put it in a library is to modularity.  If you build a class and want to share it but you need to also share a gajillion libraries with it, it potentially becomes a burden to use.  We've started to notice this problem where I work.  Our instrument library had dependencies on our error library and generic library, both of which are small and commonly used in the company.  Then we added code that inadvertently added a dependency on our test data library, which had a dependency inside our inventory tracking library, which had a dependency inside our database access library, and so on.  We have all of those libraries on our dev machines, so we didn't notice... but a few months down the line we tried to set up an engineer with the Instrument library so he could do some simple coding on his own, and we ended up spending far too much time downloading all of these libraries onto his PC so that he could run a simple 4-VI connect-initialize-measure-stop routine with our instrument library.

Message 4 of 8
(2,350 Views)

@Kyle97330 wrote:

...... but a few months down the line we tried to set up an engineer with the Instrument library so he could do some simple coding on his own, and we ended up spending far too much time downloading all of these libraries onto his PC so that he could run a simple 4-VI connect-initialize-measure-stop routine with our instrument library.


A Source Distribution >>> Preserve hierarchy

 

OR

 

Save as previous >>> Preserve hierarchy

 

helps with that situation and makes it very clear how scattered VIs may be.

 

Trying to help,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 8
(2,346 Views)

@Ben wrote:

@Kyle97330 wrote:

...... but a few months down the line we tried to set up an engineer with the Instrument library so he could do some simple coding on his own, and we ended up spending far too much time downloading all of these libraries onto his PC so that he could run a simple 4-VI connect-initialize-measure-stop routine with our instrument library.


A Source Distribution >>> Preserve hierarchy

Tried that, just for kicks...

 

1400 files across 9 libraries.

 

Like I said... we had a problem.  Still have, I guess.  Try not to do this!

0 Kudos
Message 6 of 8
(2,332 Views)

Jon McBee did a presentation last year at NI week on dependency management.  You should check that out.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 7 of 8
(2,326 Views)

Hi Kyle I agree with the point of adding VIs outside the class could make difficult to share the class. I will be aware with the dependencies relationship, currently I have cases mostly in GUI elements where I have everything self contained into the class and I can share it without issues 🙂 but there are some class that are very specific of the project and in this case I am using the approach of Method with Library VIs inside. Very illustrative read all the comments.

 

 

0 Kudos
Message 8 of 8
(2,314 Views)