Codesys: Problem mit Interface in einem Funktionsblock VAR_IN_OUT

[drfunfrock]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe hier einen FB mit folgender Definition

VAR_IN_OUT
    inverter : I_Inverter; // Interface for inverter
END_VAR

Wenn ich denn folgendes mache

MaschineFB(inverter:=MeinInverterFB);

bekomme ich einen Fehler weil ein FB kein Interface ist, obwohl er eines implementiert. Daher kam ich auf die Idee und machte eine Modifikation die funktioniert aber dämlich aussieht

VAR
  InverterInterface : I_Inverter;
END_VAR

InverterInterface := MeinInverterFB;
MaschineFB(inverter:=InverterInterface );

Das kann es doch nicht sein? Ich habe mit OOP gute Erfahrung gemacht, aber das hier sieht nach einer schlechten Implementierung aus.

 

[plcSniffer]

Da stimmt dann definitiv bei der Implementierung deiner Bausteine etwas nicht... wie sehen MaschineFB und MeinInverterFB aus?

 

[StructuredTrash]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ohne es jetzt getestet zu haben, das Problem wird die Deklaration von inverter als VAR_IN_OUT sein. Da erwartet der Compiler halt schon ein "fertiges" Interface, dem schon ein FB zugewiesen wurde. Mit VAR_INPUT sollte es aber funktionieren. In Deinem anderen Thread zum Thema hattest Du allerdings ein dynamisches Array of I_Inverter. Das kannst Du ja nur als VAR_IN_OUT übergeben und wirst um die dämlich aussehende Lösung nicht herumkommen.

 

[drfunfrock]

Ich habe dann per Vererbung versucht das Problem zu umgehen

Inverter Basisklasse <- Herstellerklasse

Wenn ich dann ein Array in VAR_IN_OUT der Basisklasse deklariere, kann ich kein Array einer abgeleiteten Klasse übergeben. Damit wird OOP irgendwie zum Witz, weil es keine Templates gibt. Das Problem das ich habe, ist, dass es hier bis zu 70 Umformer gibt. Damit müssen dann auch Alarm-Ereignisse verwaltet werden, weswegen ein Array natürlich sinnvoll ist. Daher muss ich dann ersteinmal ein Array eines Interfaces initialisieren und kann dass dann übergeben.

Wir machen dass mit OOP auf einer SPS zum ersten mal, weil unser Produkt recht viel Kode hat. Das "Hindernisslaufen" fängt schon damit an, dass Automatisierungssoftware sich nicht gut mit GIT verträgt und ich ständig gegen eine Mauer laufe. OOP verspricht bei komplexen Systemen einfach eine schnellere Anpassung an Kundenwünsche, aber das hier macht mich recht unsicher.

 

[StructuredTrash]

Solange die Objekte = FBs nicht von vornherein dynamisch angelegt werden, wird die IEC61131-OOP nicht an die Möglichkeiten aus dem Hochsprachenbereich herankommen. Ich denke, dass die FBs noch recht lange statisch bleiben werden, und mein Bauch sagt mir, dass das auch gut so ist. Eine dynamische Speicherverwaltung, die harten Echtzeitanforderungen standhält, die Fähigkeit zum Online change nicht einschränkt und auch das Problem der Verknüpfung mit der HW elegant löst, ist sicher nicht so einfach zu entwickeln.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Frischer Wind, Ideen und Anregungen aus dem HochsprachenBereich sind etwas feines.
Aber wir SPS-Programmierer sind noch etwas altmodisch gepolt und haben ständig die harten EchtzeitAnforderungen im Hinterkopf.
Ich bin mal gespannt auf die (hoffentlich!) praxisorientierten Umsetzungen, die uns ins Haus stehen . . .