TIA TIA - Gesetzte Bits aus variabler Bit-Struktur abfragen/auswerten

[heri1980]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo!

Bin gerade dabei unsere S7-Klassik-Bausteine in die TIA-Welt einzupflegen. Dabei versuche ich alle Bausteine auf "optimierten Bausteinzugriff" umzustellen. Leider heißt das auch, dass es den lieben "Any"-Typen nicht mehr gibt...und da beginnen meine Problemchen bzw. vielleicht stehe ich einfach auf der Leitung??!!

Folgende Ausgangslage... Wir verwenden für unsere Störmeldungen einen Datenbaustein mit Bit-Strukturen für die verschiedenen Bereiche/Stationen und werten aus der gesamten Struktur eine Sammelmeldung aus. Bis dato haben wir die (Bit-)Struktur auf eine Any-Eingangsvariable unseres Auswerte-FC's verschaltet und haben diese wortweise nach gesetzten Bits (Fehlern) durchforstet!!

Beim TIA dachte ich mir, ich verwende als Eingangsvariable unseres Auswertebaustein den Typen "Variant". Die Beschaltung funktioniert auch ohne Meckereien... aber jetzt stehe ich an und komm nicht weiter!! Wie kann ich die einzelnen Bits abfragen?! Wie könnte ich, ev. über eine Schleife, wortweise die ganze Struktur durchforsten?! Dachte da an die Bausteine Deserialize/Serialize... Bin ich damit auf dem richtigen Weg?!

Vielleicht hat ja der eine oder andere von euch einen guten Vorschlag oder sogar eine Lösung dafür parat?!

Danke!

LG heri



Damit's ev. etwas klarer wird...

 

[Onkel Dagobert]

Hallo heri,

vom "optimierten Bausteinzugriff" habe ich bisher immer Abstand gehalten. Jetzt habe ich dir zu ehren mal meinen Störmeldebaustein auf "optimiert" umgestellt. Zu meiner Verwunderung lässt er sich auch fehlerfrei übersetzen. Ich habe jedoch keine Ahnung, ob er auch "optimiert" funktioniert, kann es im Moment auch nicht testen.

Die Sammelstörmeldung bilde ich wie folgt:

// Sammelstörung
#TEMP_DWORD := 0;
FOR #n := 0 TO 28 BY 4 DO
    #TEMP_DWORD := #TEMP_DWORD OR (PEEK_DWORD(area := 16#84, byteOffset := #n + 96, dbNumber := #STOERMELDE_DB));
END_FOR;
#SSM := #TEMP_DWORD <> 0;

Der Eingangsparameter am FB ist ein "DB_ANY".
Im Störmelde-DB habe ich ARRAYs of DWORD für Quittierbits und UDTs für die eigentlichen Störmeldebits.


Gruß, Onkel

 

[heri1980]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo "Onkel"!

Danke für deine Antwort!

Aber, besteht auch die Möglichkeit als Eingangsparameter gleich die gesamte Struktur zu verschalten z. B. "DB_ANL_ERR".A1?

Wie weiß ich bei deiner Lösung bei welchen Offset die Struktur beginnt bzw. wie lange die Struktur ist?!

LG heri

 

[PN/DP]

In "optimierten" Speicherbereichen haben Variablen keine Adressen - man kann also auch keinen Offset ermitteln.

Harald

 

[Onkel Dagobert]

Ich hatte mich nur gewundert dass der Compiler so etwas durchgehen lässt. Ich bleibe mal schön unoptimiert .

@heri, mit einer Struktur hast du wohl noch schlechtere Karten.

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Heri,
wenn ich mir deine Struktur so anschaue, könntest du auch
ein Array daraus machen. Dann ist es zwar mit Kommentaren
Sense, aber du könntest es wunderbar mit einer Schleife durchforsten.

 

[PN/DP]

Jetzt habe ich dir zu ehren mal meinen Störmeldebaustein auf "optimiert" umgestellt. Zu meiner Verwunderung lässt er sich auch fehlerfrei übersetzen.
[...]
Der Eingangsparameter am FB ist ein "DB_ANY".

Meine Vermutung: Einen FC/FB als "optimiert" zu markieren heißt ja nur das dessen Lokalvariablen "optimiert"-Zugriff bekommen, doch es heißt vielleicht nicht, daß alle Eingangsparameter auch aus "optimierten" Speicherbereichen kommen müssen? Wenn der Eingangsparameter als "DB_ANY" auch am als "optimiert" markierten FB zulässig ist, dann wird der Compiler schon wissen, daß da nur ein DB mit Standard-Zugriff verschaltet werden darf und wird dann beim Aufruf nur nicht-"optimierte" DB zulassen - hoffentlich

Mit PEEK_xxx kann nur auf Speicher mit Standard-Zugriff zugegriffen werden.

Dabei versuche ich alle Bausteine auf "optimierten Bausteinzugriff" umzustellen.

Wenn man auf "optimiert" umstellt, dann muß man auch vollsymbolisch programmieren. Das ist im Zusammenhang mit solchen Bitfeld-Strukturen eher kontraproduktiv, weil man da jede Bitvariable einzeln anfassen muß. Die üblichen Speicherüberlappungs-Tricks gehen nicht. Ich würde die Meldungsbit-DBs einfach auf Standard-Zugriff lassen, das wird die CPU schon nicht in die Knie zwingen. Man muß nicht jede Marketing-Aussage bezüglich Performance glauben, vor allem nicht wenn "optimierte" Lösungen nur äußerst umständlich realisierbar werden.

Harald