LabVIEW Development Best Practices Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Classes - Organization in lvproj and File Explorer - What's Best Practice

Highlighted

I searched but did not seem to find any best practices document on how to organize classes in lvproj and on disk.  If this has been addressed somewhere before, can you please direct me?  FYI: I'm a CLD just getting started with OO 

 

* I remember reading its best to keep all your classes, regardless of inheritance, in a flat folder structure on disk in \Classes\ ?

* Good practice is to develop each base class in its own lvproj ?

 

Consider an example of a sensor instrument driver (serial comm binary protocol).

The "main vi's" I want a user or another developer to use are the following: 

Configure, Initialize, Start, Read Sensor, Close

With specific Read Sensor data subset functions to convert from the Private class data.

Then there's the get/set functions

 

1.) In file explorer, should all these be stored under a flat structure \Classes\Sensorname\?

Or should there be subfolders for support vis in

\Classes\Sensorname\Read Data Msgs\  (ex: ReadEulerAng.vi, ReadQuaterion.vi)

\Classes\Sensorname\Accessors\  (ex: getBaudRate, setBaudRate)

2.) On disk, Should only the "main vi's" be found under \Sensorname\ and all other support vi's be in subfolders?

3.) Same as 2, but in lvclass?

 

For binary comms, there are generally a lot of conversion and support vi's behind the scenes for parsing and data conversion.  

4.) Should all vi's possibly called by viis in a lvclass be located in that lvclass (or put these auxilary vi's in a lvlib under the same lvproj (and inside the same folder as the Class)

5.) Where do these go all in the lvclass and on disk?

 

In traditional drivers there are generally the following categories for msgs:

Action-Status, Configure, Data, Utility, etc. 

Is this still a good way to organize messages?  On disk and in lvproj

 

I like to keep my code organized, and I'd like to do it correctly from the start.  

Please provide some guidance or suggestions what you have found works best for you.

Thanks!

0 Kudos
Message 1 of 3
(1,590 Views)

Hi Stranman,

 

My general advice is that you need a structure that helps you with your style. Let me try and answer your questions on how I work:

 


Stranman wrote:

 

* I remember reading its best to keep all your classes, regardless of inheritance, in a flat folder structure on disk in \Classes\ ?

* Good practice is to develop each base class in its own lvproj ?

 

 

 


I aim to keep my classes on disks organised in the same kind of structure in the project. LabVIEW doesn't enforce this but I consider it good practice to keep the two similar. For this reason I wouldn't have them all in one flat folder but organised by subsystem/module/however you break up your code.

 

I wouldn't have additional projects for each class - just keep one main project.

 

In your example I would assume that your sensor driver exists within a DAQ subsystem of your module so if we had a couple of sensors I would have the folders:

 

\DAQ\Sensors\BaseSensorClass

\DAQ\Sensors\Sensor1

\DAQ\Sensors\Sensor2

So related classes are all next to each other.

 

Within those folders my normal organisation is to have the .lvclass file and the public API of that class in that directory and then normally a folder for subVIs and Controls. If it is a base class I may have a folder called Override for dynamic methods that I expect to be overriden. Again I am for this to be the same in the .lvclass file in the project and on disk.

 


@Stranman wrote:

 

 

For binary comms, there are generally a lot of conversion and support vi's behind the scenes for parsing and data conversion.  

4.) Should all vi's possibly called by viis in a lvclass be located in that lvclass (or put these auxilary vi's in a lvlib under the same lvproj (and inside the same folder as the Class)

5.) Where do these go all in the lvclass and on disk?

 


So here I would say the answer is no. A class and it's contents should have a single purpose (single responsibility principle) so you should not mix in VIs for specific instrument communications and VIs for data parsing of a protocol. These should be split into two with the parsing and conversion forming a class/module for that protocol.

 

I actually have this exact case in a project. I have different variants of an instrument which use different protocols. I have separate classes (or I am using existing libraries) for managing the protocols. This means that I reuse the Modbus library in different instruments.

Again if you are writing these classes put them in the appropriate subsystem or if they are very general a utility folder e.g. /DAQ/Protocols/Modbus.

 


@Stranman wrote:

 

In traditional drivers there are generally the following categories for msgs:

Action-Status, Configure, Data, Utility, etc. 

Is this still a good way to organize messages?  On disk and in lvproj

 

 


There is no difference here. OOP is merely a different way of organising the same code and concepts that you find using Action Engines or other modular techniques. If that feels like a natural way to sub-divide the API then go for it.

 

All of these comes from the way you think about the projects. I would perhaps take a look at how your organise existing projects and try and continue the themes so it still feels familar and works for you. If you are using action engines, where you would have folders for action engines, have folders for classes. OOP isn't as dramatic a change as some may have you think!

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
Message 2 of 3
(1,525 Views)

Thanks for the feedback!

0 Kudos
Message 3 of 3
(1,508 Views)