LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

OOP: Initializing device communication

Hi all,

 

I'm really, really new to OOP but want to take the leap to integrating OOP into my programs. I've done the tutorials but it has been quite awhile ago. 

I'm using LV2020 so interfaces are a thing now.

 

Say for example, I want to have the flexibility of different devices communicating with the LabView program. I don't have the devices with me to see if they actually work and I'm still in the stage of conceptual planning the structure.

For now all the communication is serial but I don't know if in the future if other devices might be added, eg. USB

 

What I currently have is:

 

CommunicationInterface <-- Grandparent class (not to be confused with the OOP interface)

Methods: InitializeCommunication (dynamic dispatch)

                CloseCommunication (dynamic dispatch)

     - SerialCommunication <--Parent class

        Attributes: Baudrate, bits, parity, etc

        Methods: GetSerialSettings, WriteSerialSettings (the settings are bundled in a normal cluster)

               - Device A <-- Grandchild class

                  Methods: InitializeCommunication (VI for overriding the grandparent class, reading and writing settings from parent)

So if I have a Device B and C that also uses serial communication, that will be the second grandchild.

 

Is the above structure suitable?

 

Both Device A and B have microcontrollers where it should be possible to read and write to its respective EEPROM. Would it be correct to make the EEPROM an Interface, so both can inherit from it? But the two EEPROMs are independent of each other (meaning I can read/write different parameters at separate times to either of the microcontollers), so do I make it a separate class instead? But then how do I get both devices to inherit from both Communication and EEPROM other than by making it an LV Interface?

 

Secondly, if I know Device A should always be initialized first, and then only B or C (the user has to choose), do I still put all the VIs for override in an array to the grandparent dynamic dispatched vi in the main program? Or do I set Device A specifically for the first Initalize and then an array of B and C for a second Initalize?

 

Thank you in advance.

0 Kudos
Message 1 of 3
(929 Views)

Hi nikvl

Did you check this article before, where you can find appropriate information about devices communication. 

Also, there is another link where you can Choose the Right Interface to Control Instruments in LabVIEW. 

Try to find the necessary information from the following links below.

 

Regards)

________

Best way to thank is to give Kudos / Marking as a solution. 

0 Kudos
Message 2 of 3
(821 Views)

@nikvl wrote:

I'm really, really new to OOP but want to take the leap to integrating OOP into my programs.


What you're trying to do is starting to look like a HAL.

 

You might want to get a feel of how OO works out on something easy (and granted, boring).

 

A HAL in OO can bring anyone to their knees. It's not OO's fault, it is just an open end and not easy at all.

 

Just a warning; A HAL might not be what you're trying to make, but it sure has similar features.

 


@nikvl wrote:

For now all the communication is serial but I don't know if in the future if other devices might be added, eg. USB


VISA is already OO-ish. Wrapping VISA in a class will very likely become utterly pointless.

 

VISA can do RS232, USB, TCP\IP, even GPIB and then some...

 

From experience, this will likely become another disappointing start in OO.

 


@nikvl wrote:

CommunicationInterface <-- Grandparent class (not to be confused with the OOP interface)

Methods: InitializeCommunication (dynamic dispatch)

                CloseCommunication (dynamic dispatch)

     - SerialCommunication <--Parent class

        Attributes: Baudrate, bits, parity, etc

        Methods: GetSerialSettings, WriteSerialSettings (the settings are bundled in a normal cluster)

               - Device A <-- Grandchild class

                  Methods: InitializeCommunication (VI for overriding the grandparent class, reading and writing settings from parent)

So if I have a Device B and C that also uses serial communication, that will be the second grandchild.

 

Is the above structure suitable?


Probably not.

 

I'm not sure what this all means.

 

CommunicationInterface <-- Grandparent class

 

If you intend to make a Grandparent class, it seems very wrong. But I'm not sure if that's the plan.

 

Some UML would help.

 


@nikvl wrote:

Both Device A and B have microcontrollers where it should be possible to read and write to its respective EEPROM. Would it be correct to make the EEPROM an Interface, so both can inherit from it?


I don't think so.

 

A class implements an interface.

 

Would you say:

Device A implements an EEPROM?

Or

Device A has an EEPROM?

 

You already said so ("Both Device A and B have microcontrollers where"). So the device parent (if all children have it) or some children (if not all children have it) should probably contain the EEPROM.

 

But this is all semantics.

 

You could also say "Device A uses an EEPROM". Then the EEPROM class becomes an input to Device methods.

 

Indeed, you could say "Device A implements EEPROM". But you didn't.

 


@nikvl wrote:

But the two EEPROMs are independent of each other (meaning I can read/write different parameters at separate times to either of the microcontollers), so do I make it a separate class instead? 


You're mixing up things.

 

If there are two EEPROMS, you instantiate two objects of the same class. You never ever want to duplicate code. The two objects (instantiations of a class or one of it's children) can live in a array, cluster, map, set, or simply as constants on a diagram or some other class's private data. 1, 2 or any number of them.  

 

Classes are what you make, objects is what the application uses.

Classes are the code and API, objects is the data in your application.

 

You really, really need to understand well this to succeed.

 


@nikvl wrote:

But then how do I get both devices to inherit from both Communication and EEPROM other than by making it an LV Interface?


I don't think that's the way to go.

 

You can make the EEPROM an interface and make Device A and Device B implement that interface. 

 

Keep in mind that the EEPROM interface cannot have any private data!

 

I'd either make a "has a" or a "uses a" relation.

 

But you decide. What makes the most sense:

Device A is an EEPROM (inheritance; you ruled this out)

Device A implements an EEPROM (interface; a more complicated is a relation)

Device A has an EEPROM (containment; object lives in private data of class or parent)

Device A uses an EEPROM (dependency; input to methods)

 

All can be made, but the interface would be hard even for an experienced programmer.

 


@nikvl wrote:

Secondly, if I know Device A should always be initialized first, and then only B or C (the user has to choose), do I still put all the VIs for override in an array to the grandparent dynamic dispatched vi in the main program? Or do I set Device A specifically for the first Initalize and then an array of B and C for a second Initalize?


If the objects are in an array, and A is first, and you execute the init in a for loop, you know A initializes first.

 

Nothing wrong with that.

 

It seems odd to have a scalar device (A) and an array of devices (B and C). You should think "lazy" (really: the least amount of work in the long run, aka efficient) and imagine the work both ways imply.

 

A scalar and array would mean duplicate code for every method. Once on A, once in a for loop.

 

Of course you can init A, then B, then C, then build an array. But you'd still be making more code then needed. Sometimes things need to be like that, for instance if A, B and C are different classes (childs of the same parent) and the init isn't dynamic dispatch. The static inits can have a different connector pane, and you can't call it in a for loop.

 

Hope it helps. It's worth the initial struggle.

Message 3 of 3
(808 Views)