LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LVOOP - Best way to do a "conversion" class

Solved!
Go to solution

Hi!

As the title suggests I have a question regarding LVOOP

Let’s say we have a class called “Servo Amp” which serves as an HAL for a Servo Amplifier. It implements all the functionality we need to control the servo amplifier and the connected drives. The several child classes override a few functions that work different on these devices to maintain a consistent easy-to-use API.

 

Now one major problem is that the servo amplifier only knows about increments to move from a to b. These increments heavily depend on the drive, the measuring system and so on. To simplify the use of the device I want to be able choose from two units for moving operations: mm/s for linear systems or rpm for rotary systems. This property should be set when initializing the servo amp class so for example we have an enum set to linear or rotary.

 

Now I want to implement a function “Move To Position” which needs to know if the input parameters are in mm/s or rpm cause we need to do a lot of conversions on these numbers to get the inc/s the servo amplifier needs. My first thought was to create some kind of conversion class and make it a property of the Servo Amp class. The problem with this is how can I handle different conversions for derivate classes of the Servo Amp class? Some of the devices have different controllers, A/D converters and much more I need to take into consideration.

Now my question is what would be the “best” way to implement some kind of conversion class or maybe something I don't have on my radar right now to get this working in a convenient way? I would love to see some auto adapting input names and descriptions like polymorphic VIs do but I’m not sure if this is even possible.

Best regards
Jens

0 Kudos
Message 1 of 7
(2,121 Views)

I think some additional information is required to better understand the problem you are trying to solve.

 

What is the conversion you actually want to do? You mention different conversion in the child classes. So what's the input (speed in mm/s rpm)? What is the output you want to have? Is this "same" conversion with different algorithm/parameters or do they have different inputs/outputs? How do you want to use the linear/rotary property of the parent class? How does the “Move To Position” know the input type(linear/rotary)? Is it given as a parameter or should it use the class property?

 

Why are trying to create a conversion class? Do some child classes for example use the same conversion which you could the reuse or what would be the benefit of the converter class? I mean compared to a solution where each child class overrides the "Move To Position" and implement the specific conversion(s)?

 

What do the various devices have in common?

0 Kudos
Message 2 of 7
(2,077 Views)

Hey!

 

I'll try to make things a bit more clear...

 


What is the conversion you actually want to do? You mention different conversion in the child classes. So what's the input (speed in mm/s rpm)? What is the output you want to have? Is this "same" conversion with different algorithm/parameters or do they have different inputs/outputs? How do you want to use the linear/rotary property of the parent class? How does the “Move To Position” know the input type(linear/rotary)? Is it given as a parameter or should it use the class property?

The input is a simple number but the unit is based on a property of the class, the output also a single number but always in inc/s. The conversions are based on device specifc parameters, can be different algorithms per device or group of devices and need to know the input unit type.

 

The linear/ rotary property could be a class on it's own or a simple enum, not sure what is the best solution here. The "Move To Position" VI knows the input type simply by the "Servo Amp class" instance wired to it (class property or override VI).

 

 


Why are trying to create a conversion class? Do some child classes for example use the same conversion which you could the reuse or what would be the benefit of the converter class? I mean compared to a solution where each child class overrides the "Move To Position" and implement the specific conversion(s)?

 

What do the various devices have in common?


I really like you question cause I'm not sure if I really need a conversion class, doing it by just overriding the necessary VIs might be a good solution. Down below you can see a part of the conversion for the majority of the devices. A few other devices need more parameters an use different algorithm.

 

Jens_S_1-1635867701601.png

Based on the unit mm/s or rpm we nee to change the "rotativ" value and the "Speed" conversion (it's jut a quick and dirty example). So I could use a SubVI for the conversion and the parameter that just takes the linear/ rotary property and the value as an input.

0 Kudos
Message 3 of 7
(2,061 Views)
Solution
Accepted by topic author Jens_S

Thanks for the clarifications. It's a bit easier to understand the problem now.

 

Of course it's difficult to design architectures with limited information (and very limited resources 🙂), but here are some thoughts I get from your answers.

 

" A few other devices need more parameters an use different algorithm." What I take from this is:

  • Different conversion instances can have different amount of parameters => Need different kind of converters (inheritance)
  • Several devices can use same conversion => Converter should property of a device

Based on these, I get this idea: Make a conversion class that has the "convert" method that child classes can override. Store the child specific parameters in the child classes. Converter is initialized in the servo amp child classes with the correct attributes and stored in the servo amp base class. For the linear/rotary conversion just use the enum, no need for a class.  In case I understood everything and didn't miss something, all this should enable a "convert" method in servo amp base class that can be safely called for any servo amp child instance.

 

Hopefully this gives some ideas for finding the correct direction.

 

 

Message 4 of 7
(2,047 Views)

Hey!

 

First of all, thanks for the effort. Your suggestion sounds very promising and I tried to implement it in a small test project.

You can start the Test1.vi, enter a value that should be converted, in which unit it is and get the corresponding result back as a string.

Basically it already works as I had imagined it. The initialization of the class objects and their values is always a point where I wonder why the standard values of the class control are not taken directly as a value when an object of the class is created.

 

I have attached the test project and would be happy if you could take a look at it and give me some feedback.

0 Kudos
Message 5 of 7
(2,016 Views)

Hello Jens,

 

I took a quick peek. Looks pretty much okay to me.

 

I'd create/initialize the converter objects outside of the ServoAmp and give it as a parameter for the ServoApm:Init. This way you can use the same converter in multiple instances of Servo Amp.

I'd maybe create a protected method, Convert, in the ServoAmp. This way the child classes don't need to know anything about the conversion, just call it.

After these you get rid off the setters and getters and have a better encapsulation.

 

Hope this helps.

0 Kudos
Message 6 of 7
(1,981 Views)

Hey!


Sorry for my late response. Thanks for taking a look at the demo project and your ideas.


Giving the Conversion class as a parameter for the Servo Amp Init would assume you exactly know how the device you want to talk to is handling all the data. From a user perspective I can not assume that the end-user does know these very specific details. Cause these conversions won't change for a specific device I don't see an advantage in using them as a parameter

0 Kudos
Message 7 of 7
(1,952 Views)