Basic OOP concept "instances" resp. "references"

2020-02-27T13:54:01.447000Z

Hello everybody

Thanks for your help, I finally found it yesterday. Interfaces are treated as pointer anyway so the declaration as POINTER TO or REFERENCE TO makes no sense resp. is not useful.
So if you want to use a FB as "fb instance", define in your input/output/method/property "fbinstance : POINTER TO FBType" .
Then you can pass the real pointer from the caller of an FB with ADR(fbinstance).The "opposite direction" would be the ^, so if you need to have the instance, instead of the pointer, often used if you refer to the instance with THIS, you will need the ^ so it doesnt take the pointer, it takes the instance.

To hom it may be interessting:
The goal of our ErrorHanlder code is:
1. Encapsulate functionality to where it belongs to and have a "nice" architecture.
2. Maybe more important, we will have libraries in our company. So if you want to be able to still encapsulate the functionaly of errorhandling inside the error causing element/FB you need kind of an Interface to the element which effectifly handles the error. If your component is in a library, there is no filesystem where you can log to, therre is no HMI you can show your error, resp. you don't know where you will be running.

In our case we startet with a motor. So if the motor runs, and there is something wrong it needs to raise an error and keep the error state. As soon as the error is gone, it can start again. (Could be a circuitbreaker or a VFD in overload, what ever). We in our company normaly want the user to commit an error, so the motor stays in errorstate as long as the user does not commit the error.

For this we have 2 Interfaces:
- The AlarmHandlerInterface (this will be implemented by the FB which is actually resetting the error, making the decision if it has to be logged or viewed on a screen. And it handles user actions to reset the errors.
- The AlarmSourceInterface. This is needed because we want like a callback method to the error causing element so we can reset its errorstate.

INTERFACE AlarmHandlerInterface
(* ------------------------------------ *)
METHOD RegisterAlarm
VAR_INPUT
  deviceWithAlarm:   AlarmSourceInterface;
END_VAR

INTERFACE AlarmSourceInterface
(* ------------------------------------ *)
METHOD ResetAlarm

If the Motor which implements AlarmSourceInterface needs to raise an alarm, it needs to call the RegisterAlarm method from the AlarmHandler which implements the AlarmHandlerInterface (and needs a type of AlarmSourceInterface in this signature). We in our case provided the AlarmHandler to the Motor in the FB_Init method (like a contstructor) so its only called once.

The AlarmHanlder will then put the Motor into an internal list, like this:

METHOD RegisterAlarm
VAR_INPUT
   deviceWithAlarm   :   AlarmSourceInterface;
END_VAR
(* ------------------------------------ *)
devicesAlarmList[devicesInList]:= deviceWithAlarm;
devicesInList:= devicesInList + 1;

In this case its a fixed Array with 100 elements, im sure its possible to improve this to a dynamic approach. Because normally you don't know how many items will be added and need to increase the size of the array / list dynamically.

This code is called when for example the operator on a HMI pressed a button to commit all errors:

METHOD PUBLIC ResetAllAlarms
(* ------------------------------------ *)
//Resets all the alarms on each motor
FOR currentDevice:= 0 TO devicesInList - 1 DO
  devicesAlarmList[currentDevice].resetAlarm();
END_FOR
devicesInList:= 0;

It goes through the array which has only items of type AlarmSourceInterface in it and calls on each of this devices the reset alarm method.

In the future we could also implement warnings and maybe sort of an autocommit depending if you use it.
In our case, the Interfaces and the Motor itself will be in the library. The AlarmHandler is in the project were your work is done.

I will add the project for you so you can have a look into it. I also added pragmas so you see were you have to so something.

Greetings and thanks a lot for your patience. I hope I can put more samples here in the future.

BasicOOP_AlarmHandling.project [113.41 KiB]

Basic OOP concept "instances" resp. "references"

2020-02-27T13:54:01.267000Z

Originally created by: Viacheslav Mezentsev

schaepper hat geschrieben:
I attached my latest project to this post if someone is interested.

Example works for me (Codesys 3.5.11.0). Maybe I'm don't understand something?

BasicOOP.project [114.17 KiB]

Basic OOP concept "instances" resp. "references"

2020-02-27T13:54:01.099000Z

Hi.

Convert first your fb to an interface:

A:Interface;
B:fb_ whichimplements interface

B=A

And pass b sa var_input.

Codesys treates as pointers. If you see in debug B you can see the address of A littlel bit offseted.

But if an fb waits for an interface as input, before you have to cast it.

Basic OOP concept "instances" resp. "references"

2020-02-27T13:54:00.926000Z

Check this one: https://stefanhenneken.wordpress.com/2014/11/16/iec-61131-6-abstract-factory-english/

This is a great post on how to create dynamic function blocks using interfaces with proper samples and not only pseudocodes.

Of course I understand you, copies are not what you are after.

In my sample I'm using pointers everywhere to update from outside data that exists on the pointed function block. Unless I've made a mistake (more than possible given I've written the code directly here) it should work properly.

See that article from Stefan which I guess it will give you some extra light on how to do it.

Hope this helps.

Basic OOP concept "instances" resp. "references"

2020-02-27T13:54:00.754000Z

Joan M hat geschrieben:
Check the last link I pasted in the first message, Stefan shows how to use interfaces correctly to get the most similar to what JAVA, C++, C# gives you.
In any case it is not important what interface you implement, you are passing the function block pointer (in my example pseudo code).
If you want to be able to use a more dynamic approach (given your background and the advantages it offers it is normal you would like to) then look at the Stefan link where good samples are implemented and deeply explained.
Hope this helps.

You refering to this? https://stefanhenneken.wordpress.com/20 ... nterfaces/
I read it completely, even time before but it does not (and in any article) explain the problem of "objects" always beeing copied if you don't use Reference To or similar approaches.

If you don't use REFERENCE TO, POINTER TO or what ever if you just declare FB's as normal. And you pass a FB to another FB, and the "foreign" FB manipuliates the FB you are providing, he will manipulate the copy, not the FB you are providing.

Here is my Pseudocode:
motor1.ManipulateCopyTestString('ManipulationFromOutside');
motor1(alarmHandler := alarmHandler1);
POU1(motorInput := motor1);

//This is the Methodcall from POU1
motorInput.ManipulateCopyTestString('manipulatedinsideforeignfb');

if you now look into "motor1" which was actually manipulated inside POU1, it will still have the string in it 'ManipulationFromOutside' which means POU1 manipulated a copy. And this is my Problem:

Copy's don't make sense at all in an OOP aproach, and if I use pointers or references, I face the problems already describe in this post?

Basic OOP concept "instances" resp. "references"

2020-02-27T13:54:00.201000Z

Check the last link I pasted in the first message, Stefan shows how to use interfaces correctly to get the most similar to what JAVA, C++, C# gives you.

In any case it is not important what interface you implement, you are passing the function block pointer (in my example pseudo code).

If you want to be able to use a more dynamic approach (given your background and the advantages it offers it is normal you would like to) then look at the Stefan link where good samples are implemented and deeply explained.

Hope this helps.

Basic OOP concept "instances" resp. "references"

2020-02-27T13:54:00.024000Z

Yes, the problem is the type.

You can't typecast pointers.

In my code the pointer points to the function block type not to it's interface.

In your code, given the name it looks like it points to the interface the function block implements.

Basic OOP concept "instances" resp. "references"

2020-02-27T13:53:59.846000Z

Joan M hat geschrieben:
pseudocode:
[code]PROGRAM MAIN
VAR
fbAlarmHandler : AH;
fbMotor(ptrAlarmHandler := ADR(fbAlarmHandler));
END_VAR

motor();

This is exactly the code that will not work because it sais:
Canot convert type "Pointer To AlarmHandler" to type "POINTER to AlarmHandlerInterface"

This where all the post is about...

Basic OOP concept "instances" resp. "references"

2020-02-27T13:53:59.624000Z

pseudocode:

function block motor
VAR_INPUT
  ptrAlarmHandler : pointer to AH := 0;
END_VAR
--------------------------------------------------
ptrAlarmHandler^.i := ptrAlarmHandler^.i + 1;

function block AH
VAR
  i : int := 0;
END_VAR
-------------------------

PROGRAM MAIN
VAR
  fbAlarmHandler : AH;
  fbMotor(ptrAlarmHandler := ADR(fbAlarmHandler));
END_VAR
-------------------------
motor();  // After executing that code you should see i increasing by one.

Hope this helps.

Basic OOP concept "instances" resp. "references"

2020-02-27T13:53:59.455000Z

I tried it without the ^ but it still gives me the same alarm.

"Remember that the pointers doesn't allow typecasting here, if you define a pointer to a specific type you can't pass a different pointer there."

What would be the solution? Just as an info: My goal is not to use references, or pointers, whatever I just want to pass the same instance of a FB around. If I do it the "classic" way without pointers,refs or anything then the FB's always get copied on asignments. I just want to overcome the copies.

Basically I just want to use it like every other "OOP" language in the field like C#,JAVA,Python,C++ what ever...

I attached my latest project to this post if someone is interested.

BasicOOP.project [114.17 KiB]

Recent posts to Basic OOP concept "instances" resp. "references"

Basic OOP concept "instances" resp. "references"

Basic OOP concept "instances" resp. "references"

Basic OOP concept "instances" resp. "references"

Basic OOP concept "instances" resp. "references"

Basic OOP concept "instances" resp. "references"

Basic OOP concept "instances" resp. "references"

Basic OOP concept "instances" resp. "references"

Basic OOP concept "instances" resp. "references"

Basic OOP concept "instances" resp. "references"

Basic OOP concept "instances" resp. "references"