Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
I have a question about Object Oriented Programming as it applies to inheritance of output variables
FUNCTION_BLOCKBASEVAR_OUTPUTÂ Â Status:BASESTATUS;END_VARFUNCTION_BLOCKL2EXTENDSBASEVAR_OUTPUTÂ Â Status:L2STATUS;END_VARTYPEBASESTATUS:STRUCTÂ Â Bit1:BIT;Â Â Bit2:BIT;Â Â Bit3:BIT;END_STRUCTEND_TYPETYPEL2STATUSEXTENDSBASESTATUS:STRUCTÂ Â Bit4:BIT;Â Â Bit5:BIT;Â Â Bit6:BIT;END_STRUCTEND_TYPE
I'm getting the error "Duplicate definition of variable 'Status' in function block 'L2' and in base 'BASE'", because the outputs share the same name. It looks like input and output variables are always inherited by the subclasses.
I would like all my function blocks to use the same output variable "Status", which will inherit all the variables from the base class and add other variables as I go deeper into the sub classes. I looked at interfaces for a while, but they don't seem to apply to input and output variables, only properties and methods. Since inheritance of properties and methods can be influenced by the keywords PUBLIC, PROTECTED, INTERNAL and PRIVATE. I tried to turn the variable "Status" into a property, so that I could then hide it from the subclass with "INTERNAL" but there seems to be some issues with using a structured variable as a property (for example, structured properties don't appear in the list of variables in a function block when online with the PLC, also see here: l viewtopic.php?t=5577 l )
Is there a way to hide an output from a sub class? I'm thinking I could then manually copy bits as needed (ie. Status.Bit1:= SUPER^.Status.Bit1, or Status:= SUPER^.Status).
For now I can get around this by calling each "Status" output a different name, but that can get confusing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Both Fb_executer and the fb executer are abstracts fbs which has to be extended. I have some code in Fb_executer which are using Reference.
The solution for me is using an internal pointer to reference wich I use in FB executer.
When I extend my fb_executer i add to it my varinout extended reference which i point to the base variable reference pointer in Fb_init. It works fine, but I have to dont forget to point the pointer to the new reference or....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@ThK Interesting, I was using Schneider SoMachine, but I just tried it in Codesys 3.5 SP10 Patch 2, and I'm getting the Duplicate definition error in both. I wonder if something changed in SP11.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2017-09-05
Originally created by: rickj
When you extend a FB the new FB inherits all the variables declared in the original, which includes input and output parameters. You are getting an error because you are declaring two different output parameters with the same name (i.e.status).
As far as I know it's not possible to override previous super/base class definitions.
What are you hoping to achieve by doing this? Your example implies that Status is defined differently for each sub-class, consequently requiring individual code for each sub-class. You, could simply leave the Status definition out of the base class and defer it's definition until the end.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@rickj That's probably worth thinking about. Basically I'm building up a library for motor control. My base function block is a Hand-Off-Auto control, which is then extended by a motor control function block, which is then extended by pump, fan or compressor, etc function blocks. Each block might be used stand alone, but they also extend the lower level blocks. As I go deeper into the levels, more status and alarm variables are added (For example, the motor control adds run status and hour counters, the pump adds flow control. The object oriented approach seems like the right way to go, but it's possible my design approach is incorrect.
Tim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You should also grab a book about OO, if you start doing OO without knowing the basics your code will get far worse than doing it the classic way.
If you have base class with lets say a status, your deriving class will always derive this status. If you want to change the behavior of this status you have to override it.
Your object hirarchy you mention would already be wrong.
Imagine a base class Hand-Off-Auto control, which is extended to a motor, and then extended by a pump. Thats not the way OO is used.
A derived class needs always be able to be treated as baseclass, at least the question is derived class also a baseclass needs to be answered with yes. This would not be the case here.
A pump is not a motor. A compressor is also not a motor. A compressor uses a motor, but it is not a motor. I would really sugges you read books about this first before you already ask concrete questions about implementations.
And maybe you want to search for books in OO in other languages than ST / IEC 61131, because its pain to find anything usefull about this language in the internet.
This site is quite good for having an entry point:
Unless you don't understand anything on this site which is IEC 61131 related you should read more about OO.
I think that the question is there exist an abstract base class wich has n attribute wich is already an abstract base class. And in the base class wich hs the attribute there exist some code with his attribute.
As it is not possible to extend both classes which mechanism can be used to semi automatize it.
For example workink with a pointer to the abstract attribute in the primery base class. But it is dangerous if you forget to point the extended atribute in the new extended class.
Enviat des del meu Aquaris M5.5 usant Tapatalk
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the replies. @schaepper you make some good points, and I have changed my design somewhat. There's not a lot of good information out there about IEC61131 object oriented programming and sometimes it's hard to sort out the good information from the bad in online forums.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a question about Object Oriented Programming as it applies to inheritance of output variables
I'm getting the error "Duplicate definition of variable 'Status' in function block 'L2' and in base 'BASE'", because the outputs share the same name. It looks like input and output variables are always inherited by the subclasses.
I would like all my function blocks to use the same output variable "Status", which will inherit all the variables from the base class and add other variables as I go deeper into the sub classes. I looked at interfaces for a while, but they don't seem to apply to input and output variables, only properties and methods. Since inheritance of properties and methods can be influenced by the keywords PUBLIC, PROTECTED, INTERNAL and PRIVATE. I tried to turn the variable "Status" into a property, so that I could then hide it from the subclass with "INTERNAL" but there seems to be some issues with using a structured variable as a property (for example, structured properties don't appear in the list of variables in a function block when online with the PLC, also see here: l viewtopic.php?t=5577 l )
Is there a way to hide an output from a sub class? I'm thinking I could then manually copy bits as needed (ie. Status.Bit1:= SUPER^.Status.Bit1, or Status:= SUPER^.Status).
For now I can get around this by calling each "Status" output a different name, but that can get confusing.
Dear tvm,
i tried it today with SP11 and get no error.
Hi
I have the same problem with an var_inout.
I have an virtual Fb which is extended to create fb which are used to give orders wich are:
Fb_executer
Var_input
Execute:bool
End_var
Var_inout
Ref:reference
End_var
Var_output
Done:bool
Abort:bool
Busy:bool
End_var
Both Fb_executer and the fb executer are abstracts fbs which has to be extended. I have some code in Fb_executer which are using Reference.
The solution for me is using an internal pointer to reference wich I use in FB executer.
When I extend my fb_executer i add to it my varinout extended reference which i point to the base variable reference pointer in Fb_init. It works fine, but I have to dont forget to point the pointer to the new reference or....
@ThK Interesting, I was using Schneider SoMachine, but I just tried it in Codesys 3.5 SP10 Patch 2, and I'm getting the Duplicate definition error in both. I wonder if something changed in SP11.
Originally created by: rickj
When you extend a FB the new FB inherits all the variables declared in the original, which includes input and output parameters. You are getting an error because you are declaring two different output parameters with the same name (i.e.status).
As far as I know it's not possible to override previous super/base class definitions.
What are you hoping to achieve by doing this? Your example implies that Status is defined differently for each sub-class, consequently requiring individual code for each sub-class. You, could simply leave the Status definition out of the base class and defer it's definition until the end.
@rickj That's probably worth thinking about. Basically I'm building up a library for motor control. My base function block is a Hand-Off-Auto control, which is then extended by a motor control function block, which is then extended by pump, fan or compressor, etc function blocks. Each block might be used stand alone, but they also extend the lower level blocks. As I go deeper into the levels, more status and alarm variables are added (For example, the motor control adds run status and hour counters, the pump adds flow control. The object oriented approach seems like the right way to go, but it's possible my design approach is incorrect.
Tim
Hi
The problem comes if you have some code with status in the base class.
You should also grab a book about OO, if you start doing OO without knowing the basics your code will get far worse than doing it the classic way.
If you have base class with lets say a status, your deriving class will always derive this status. If you want to change the behavior of this status you have to override it.
Your object hirarchy you mention would already be wrong.
Imagine a base class Hand-Off-Auto control, which is extended to a motor, and then extended by a pump. Thats not the way OO is used.
A derived class needs always be able to be treated as baseclass, at least the question is derived class also a baseclass needs to be answered with yes. This would not be the case here.
A pump is not a motor. A compressor is also not a motor. A compressor uses a motor, but it is not a motor. I would really sugges you read books about this first before you already ask concrete questions about implementations.
And maybe you want to search for books in OO in other languages than ST / IEC 61131, because its pain to find anything usefull about this language in the internet.
This site is quite good for having an entry point:
Unless you don't understand anything on this site which is IEC 61131 related you should read more about OO.
https://stefanhenneken.wordpress.com/
Greetings
Dears.
I think that the question is there exist an abstract base class wich has n attribute wich is already an abstract base class. And in the base class wich hs the attribute there exist some code with his attribute.
As it is not possible to extend both classes which mechanism can be used to semi automatize it.
For example workink with a pointer to the abstract attribute in the primery base class. But it is dangerous if you forget to point the extended atribute in the new extended class.
Enviat des del meu Aquaris M5.5 usant Tapatalk
Thank you for the replies.
@schaepper you make some good points, and I have changed my design somewhat. There's not a lot of good information out there about IEC61131 object oriented programming and sometimes it's hard to sort out the good information from the bad in online forums.