Dynamische Texte

Anfügen

Funktionsbaustein Anfügen

Erzeugen

Funktionsbaustein Erzeugen

Get

Funktionsbaustein Get

Konverter

Funktionsbaustein Konverter

Länge

Funktionsbaustein Länge

Mid

Funktionsbaustein Mid

Schalter

Funktionsbaustein Schalter

Set[i]

Funktionsbaustein Set

Speicher-Diagnose

Funktionsbaustein Speicher-Diagnose

Suchen

Funktionsbaustein Suchen

Text-Ressource Laden

Funktionsbaustein Text-Ressource Laden

Vergleicher

Funktionsbaustein Vergleicher

Visualisierung

Funktionsbaustein Visualisierung

Überblick

Der Datentyp "Dynamische Texte“ ermöglicht die speicherplatzeffiziente Verarbeitung von Texten bis zu einer maximalen Länge von 4095 Zeichen. Für jeden einzelnen Text wird nur der benötigte Speicherplatz reserviert, sodass anders als bei String-Datentypen mit fester Länge auch beliebige Kombinationen von kurzen und langen Texten nicht automatisch zu hohen Speicherplatzverlusten führen. Derzeit werden die "Dynamischen Texte“ nur im RAM abgelegt, d.h. sie sind nur zur Laufzeit verfügbar. Mit den Bausteinen der vorliegenden Bibliothek werden die "Dynamischen Texte“ durch Konvertieren von Standard-Texten oder Zahlenwerten bzw. Laden von HMI-Text-Ressourcen erzeugt und können anschließend geändert, verknüpft und ausgegeben werden.

Die Speicherbereiche DYNTEXTDATA und DYNTEXTRAM bilden die Basis für den Datentyp "Dynamische Texte". Die Elemente des zuerst genannten Speicherbereichs werden den Bausteinausgängen und internen Speichern zugeordnet. Sie enthalten Verweise auf Abschnitte des zweiten Speicherbereichs, in denen die Texte abgelegt sind. Als Verweisinformationen dienen der Offset und die Größe in Bytes. Sie werden während der Onlinebeobachtung in den Signallinienfenstern angezeigt.

Auf Grund der beschriebenen Verweisstruktur ergeben sich einige Besonderheiten im Vergleich zu den Standard-Datentypen. So können mehrere Elemente von DYNTEXTDATA auf den gleichen Abschnitt in DYNTEXTRAM zeigen. Andererseits hat das Zuweisen längerer Texte eine erneute Speicheranforderung zur Folge, d.h. in DYNTEXTRAM wird ein neuer Abschnitt gesucht, der mindestens die Größe des neuen Texts umfasst. Daraufhin ändern sich natürlich auch die Werte von Offset und Größe im zugehörenden DYNTEXTDATA-Element.

Wenn der ursprünglich genutzte Abschnitt nicht weiter ausgedehnt werden konnte und ein neuer zugewiesen wurde, kommt es zur Fragmentierung von DYNTEXTRAM, d.h. zwischen den genutzten Bereichen entstehen Lücken. Bei nachfolgenden Speicheranforderungen wird natürlich geprüft, ob eine Lücke verwendet werden kann. Es ist jedoch unwahrscheinlich, dass die Anforderungen genau der Größe einer Lücke entsprechen. Deshalb muss bei der Dimensionierung von DYNTEXTRAM in der Ressourcenanforderungsdatei der zusätzliche Speicherverbrauch durch die Fragmentierung mit einkalkuliert werden.

Zur Überwachung der Fragmentierung wird der Baustein "Speicher-Diagnose" eingesetzt. An seinen Ausgängen stellt er LONG-Werte mit den Größen von DYNTEXTRAM sowie des genutzten Speicherbereichs und der vorhandenen Lücken in Bytes bereit. Liegt an seinem BIT-Eingang ein HIGH-Signal an, wird die Defragmentierung (Garbage Collection) gestartet. Dabei werden die genutzten Abschnitte hintereinander geschoben, sodass alle Lücken geschlossen werden. Die Verweise in DYNTEXTDATA werden entsprechend angepasst. Abhängig von der Anzahl der DYNTEXTDATA-Elemente und dem Umfang der zu verschiebenden Abschnitte nimmt die Laufzeit für die Defragmentierung zu. Dies sollte bei der Implementierung einer automatischen Defragmentierungsstrategie berücksichtigt werden.

Sollte eine Speicheranforderung fehlschlagen, d.h. es konnte kein freier Abschnitt in der gewünschten Größe gefunden werden, so werden Offset und Größe im DYNTEXTDATA-Element mit 0 initialisiert. Nachfolgende Operationen und Bausteine interpretieren diesen Verweis dann als leeren Text und verarbeiten ihn entsprechend.