Dynamische Texte
Anfügen
Erzeugen
Get
Konverter
Länge
Mid
Schalter
Set[i]
Speicher-Diagnose
Suchen
Text-Ressource Laden
Vergleicher
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.