Codesys Objektorientiertes Programmieren

Zuviel Werbung?
-> Hier kostenlos registrieren
@Werner29

Danke für die Klärung,

die REF Lösung ist schon verstanden, aber ich habe eine Safety Anwendung (SIL 2 in ST) zu programmieren und da sind mir mit internen Vorschriften Referenzen (auch als "expert") verboten. Spätestens von meinem Review Partner bekomme ich dann "geht nicht" beschieden. Sonst würde ich durchweg VAR_IN_OUT verwenden.

Das Performance Problem ist hier auf mich den Applikations Programmierer verschoben, denn dann muss ich alles temporär kopieren oder für jedes benötigte Element der struct Property eine eigene Get Property anlegen.
In C# ist die Dereferenzierung einer Property Struct erlaubt. Das ist eine Frage, wie tief (intelligent) der Compiler den Ausdruck analysiert, denn er weiss ja, dass ich nur das eine Element der Struct an dieser Stelle benötige.

Noch ein Hinweis allgemein zur OOP: Wenn ich Methoden etc. anlege, sind sie aus "Gründen der Kompatibilität" automatisch PUBLIC, es wäre defensiver sie PROTECTED oder PRIVATE zu machen, ggf. könnte man so etwas in den Options einstellen, aber zumindest vom Editor automatisch das Schlüsselwort PUBLIC einfügen.

Bitte das nicht als Verriss ansehen, ich muss auch TIA manchmal einsetzen und da hat Codesys Lichtjahre Vorsprung.
 
@Werner

Das liest sich nun aber, als ob man die erste beschriebene Methode auch gleich ganz weglassen könnte?
Gibt es einen Fall, für den die dann besser geeignet ist?

Eigentlich sind das die Sachen, über die ich mir gerade bei einer SPS nicht den Kopf zerbrechen möchte. Ich hätte da Angst, durch eine fasche Verwendung eine Maschine zu zerstören.
Vielleicht bin ich da zu konservativ, aber ich halte solche Dinge in einer Maschine per se für unsicher, da muß man schon ganz genau wissen, was man macht oder?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

in Thread #8 steht das:
Das mag zunächst umständlicher wirken, aber nur dadurch kann man zur Laufzeit das eine Objekt gegen ein anderes austauschen, weil es eben dieselbe Schnittstelle bietet.

Wie macht man das in der Praxis?

MfG

CAS
 
Hallo toto45,

1. Variablen in VAR .. END_VAR sind grundsätzlich nicht von aussen zugreifbar. Deswegen wie schon von StructuredTrash geschrieben VAR_INPUT oder VAR_OUTPUT-Variablen verwenden.
2. Properties werden spätestens dann notwendig, sobald man mit Interfaces arbeitet. Properties sind aber Code und per default werden diese nicht gemonitort, denn wenn der Code beim Monitoring einen Seiteneffekt produziert dann könnte das sehr unangenehm sein.
Wenn man sich sicher ist, dass durch die Ausführung des Properties kein Unsinn passieren kann, dann kann man das Monitoring mit folgendem Attribut einschalten:

{attribute 'monitoring':= 'call'}
PROPERTY Dingsbums: INT


Bernhard

Hallo Bernhard,

von welchen Seiteneffekten ist hier zum Beispiel die Rede? Das Einzige, das mich stört an den Properties ist, dass sie nicht gemonitort werden. Ich möchte sie aber auch ungern durch attribute aktivieren, wenn es
triftige Gründe gibt, das nicht zu tun.

Viele Grüße

Dax
 
Hallo Dax,

das Property wird dann tatsächlich ausgeführt, um den Wert zu ermitteln.
Nehmen wir an du hast ein Property NextId, das folgendermassen implementiert ist:

NextId := _locVar;
_locVar := _locVar + 1;

dann wird der Member _locVar in der Instanz deines FBs allein dadurch hochzählen, dass du ihn im WatchFenster anschaust.
Das würde dann tatsächlich alle 200 ms hochgezählt werden, das ist der typische Zyklus für das Variablen-Monitoring.
Wenn du weist, dass du keinen Seiteneffekt in dem Property hast, dann kannst du das Attribut ohne Probleme setzen.
 
Das Demo Beispiel zeigt genau das. Darin kommt die folgende Deklaration vor:

m_units : ARRAY [0..10] OF IUnit;

die Elemente von m_units werden zur Laufzeit mit konkreten Instanzen belegt die jeweils einen unterschiedlichen Typ haben, aber gleichartig behandelt werden über die gemeinsame Schnittstelle.
Mit herkömmlichen Mitteln ist sowas nicht möglich.
 
Zurück
Oben