ENUM als Schleifenvariable gute oder schlechte Idee?

M

mgl

Level-2
Beiträge
94
Reaktionspunkte
12
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen,

ich möchte gern wissen ob man sich bei der Deklaration auf die "automatischen" Inkremente verlassen kann und den Enum auch als Array Index verwenden kann.

Beispiel:

Code: 
TYPE E_Colors :
(   
    RED := 0,
    GREEN,        // 1 ?
    BLUE,           // 2 ?
    YELLOW       // 3 ?
);
END_TYPE

VAR
    aColors    : ARRAY[0..3] OF String := ['rot','grün','blau','gelb'];
    sBlue    : STRING;
END_VAR;


sBlue := aColors[E_Colors.BLUE];

Kann man so sicher Zugreifen oder verwendet der Compiler da Zufallszahlen?

In der InfoSys wird bei ENUMs automatisch das Attribut 'strict' hinzugefügt, damit es einen Compilerfehler bei FOR-Schleifen und so. Aber wenn man die ENUM ordentlich deklariert, also entweder ganz ohne Initialisierung oder nur der Initialisierung des ersten Elements, könnte es doch funktionieren.
 
Sind das nur so deine Gedanken, oder hast Du eine konkrete Frage?

Zumindest Enums ohne Wert haben keine Zufallswerte sondern immer Vorgängerwert +1.

Strict musst Du entfernen, wenn du den Enum numerisch weiterverwenden willst. Nur, ob das ein guter Stil ist, liegt im Auge des Betrachters.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wahrscheinlich hast du Recht. Auch im Hinblick auf die Zukunft, wenn dann der nächste Programmierer kommt und das ENUM so verändert, dass es nicht mehr ins Array passt.

Ich habe überlegt da mit Meldungen etwas zu machen. Normal würde ich eine Union machen aus WORD und Struktur-Bits um die Fehler namentlich zuzuweisen. Stattdessen ein Array zu nehmen und mit ENUM das Fehlerbit-Namentlich zuzuweisen um dann in einer Schleife drauf zugreifen zu können. Werde das ganze jetzt aber ohne Array nutzen, da ich das doch nicht so umsetzen kann.

Kurz zu meiner Konzepterklärung:
Wenn ich einen Aktorbaustein habe, dann müsste ich für jede Instanz Fehler-Events anlegen und dementsprechend auch die Texte und Übersetzungen. Das möchte ich nicht. Daher lege ich je 100 Warnungen, Alarme und Info Events an, die wenn eine Meldung auftritt mit dem Platzhalter-Text aus der SPS befüllt werden. Die Texte lese ich je nach Sprachanwahl dann aus mehreren CSV-Dateien.

Das soll die Kosten für Übersetzer bzw. das Fehleranfällige hantieren mit der Excel ersparen.

Gedacht war erst für jede Fehlermeldung im Aktor einen Text zu verwenden und daher pro Fehler-Bit einen Textstring zu verwenden. Aber das ist so gar nicht notwendig, da ich den selben Fehlertext für Warnung und Alarm verwenden kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
georg28 schrieb:
Mit dem Eventkogger kann man hier einiges machen. Benötigt aber auch einiges an Einarbeitung und Zeit dies dann so entsprechend aufzuziehen
Zum Vergrößern anklicken....
Ja, aber wenn man das hinter sich hat und die eine oder andere Klippe umschifft hat ist der Event Logger klasse.
Übrigens gibt es von Beckhoff ein Ecxel Plugin mit der komfortabel Events angelegt und bearbeitet werden.
Die Version die ich genutzt hatte, hatte allerdings die "Macke", dass man die vom Plugin erzeugte Datei zweimal erzeugen musste, damit die vorherige GUID an der entsprechenden Stelle angelegt wurde.
Kann gerne mal ein Beispielprojekt für 4024 mit der TE/TF2000 HMI zur Verfügung stellen.
 
asci25 schrieb:
Der TC3-Eventlogger ist in der Version 4024 noch nicht fähig für die objektorientierte Programmierung, so wie es der TC2-Eventlogger schon immer konnte. Das Problem hat Beckhoff erst in der 4026 gelöst. https://infosys.beckhoff.com/content/1031/tc3_eventlogger/14990289547.html?id=6079810766865870793

Das sollte man bei der Einarbeitung wissen. OOP-Programmierer stoßen sonst auf eine schwerwiegende Limitierung.
Zum Vergrößern anklicken....
Das ist SOOO bezeichnend für Beckhoff, dass man sowas nur durch einen Kommentar in einem SPS Forum erfährt.... Das ist auch eine sehr elementare Eigenschaft eines Meldesystems und Beckhoff bewirbt es einfach nicht.

Meine Lösung war es immer das Event um ein anderes Event zu erweitern... Natürlich ist dieser Weg von Beckhoff besser, weil es auch einen "offiziellen" Charakter hat.

Code: 
fbAlarm.ipArguments.AddEventReferenceEx(stLocalizedEventEntry);
 
Zuviel Werbung?
-> Hier kostenlos registrieren
asci25 schrieb:
Der TC3-Eventlogger ist in der Version 4024 noch nicht fähig für die objektorientierte Programmierung, so wie es der TC2-Eventlogger schon immer konnte. Das Problem hat Beckhoff erst in der 4026 gelöst. https://infosys.beckhoff.com/content/1031/tc3_eventlogger/14990289547.html?id=6079810766865870793

Das sollte man bei der Einarbeitung wissen. OOP-Programmierer stoßen sonst auf eine schwerwiegende Limitierung.
Zum Vergrößern anklicken....
Ich habe gerade mal im Infosys nachgesehen, das Excel Package ist da jetzt sogar aufgeführt. Kann es im Moment nicht testen, aber ich bin gespannt, ob Beckhoff die eine Macke mit der GUID (Alte GUID wird erst nach zweimal speichern abgelegt) beseitigt hat.
Was ich auf Anhieb nicht gesehen habe sind Eingabemöglichkeiten für "Cause" und "Remedy". Die gab es bei der Version in TC3.4024, wurden dort aber nicht unterstützt.
Weißt Du was von, kann gerade nicht selber nachsehen.
 
oliver.tonn schrieb:
Was ich auf Anhieb nicht gesehen habe sind Eingabemöglichkeiten für "Cause" und "Remedy". Die gab es bei der Version in TC3.4024, wurden dort aber nicht unterstützt.
Weißt Du was von, kann gerade nicht selber nachsehen.
Zum Vergrößern anklicken....
Die Abfrage davon (auch bspw. vom Kommentar) funktioniert nun in der SPS. Nutzen wir seit kurzem.

Edit: Die Übersetzungsoptionen dort sind aber noch nicht so eindeutig gestaltet. Bei anderen Eingabefeldern hat man ja sonst das kleine Rechteck am Ende. Bei Cause/Remedy fehlt das. Man kann dort aber auch direkt die Keys für die Übersetzung eintragen und dann wird das in der Übersetzungsliste nachgeschlagen.
 
oliver.tonn schrieb:
Weißt Du was von, kann gerade nicht selber nachsehen.
Zum Vergrößern anklicken....
Nein leider nicht. Ich arbeite bisher mit dem TC2-Eventlogger. Meine ersten Tests mit dem 4026er Eventlogger habe ich erst mal wieder zurückgestellt. Im Testprojekt hat es mit der Internationalisierung der Quellen funktioniert. In meiner komplexen SPS-Umgebung allerdings nicht. Da will ich jetzt noch ein paar Versionen abwarten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
asci25 schrieb:
Hast Du schon mal überlegt, den TwinCAT Eventlogger einzusetzen?
Zum Vergrößern anklicken....
Das Problem ist doch beim Eventlogger, dass ich da die EventId angeben muss und eben keine zwei Events mit dem gleichen Id getriggert werden können. Das heißt für mich wenn ich einen Aktorbaustein habe mit 10 Meldungen, wobei ich theoretisch nur 5 Meldetexte brauche, muss ich 10 Events anlegen und bei 10 Aktoren sind dass dann 100 Events. Bei 100 Aktoren 1000 und dementsprechend müssen auch die Texte dann generiert werden oder sehe ich das falsch?
 
Zuletzt bearbeitet:
mgl schrieb:
Das Problem ist doch beim Eventlogger, dass ich da die EventId angeben muss und eben keine zwei Events mit dem gleichen Id getriggert werden können. Das heißt für mich wenn ich einen Aktorbaustein habe mit 10 Meldungen, wobei ich theoretisch nur 5 Meldetexte brauche, muss ich 10 Events anlegen und bei 10 Aktoren sind dass dann 100 Events. Bei 100 Aktoren 1000 und dementsprechend müssen auch die Texte dann generiert werden oder sehe ich das falsch?
Zum Vergrößern anklicken....

Das stimmt so nicht.

Wenn Du einen Aktor-Baustein mit 10 Meldungen hast, dann legst Du auch nur 10 Meldungen in den benötigten Sprachen an. Dabei ist es egal, wie viele Instanzen Du von dem Baustein erzeugst. Um die Bausteine voneinander zu unterscheiden hast Du dann noch die Source-Info. Die legst Du einmal je Instanz an. Wenn Du dann noch instanzspezifische Texte, wie z.B. Betriebsmittelkennzeichen mit unterbringen musst, kommen Felder in den Meldetext, die Du dann von der SPS aus beschreibst. Betriebsmittelkennzeichen musst Du ja nicht internationalisieren.

Das Konzept Eventlogger ist schon ziemlich durchdacht, finde ich. Und nachdem das Problem der Internationalisierung der Source-Info behoben wurde, kann man den TC3-Eventlogger jetzt auch gut nutzen.
 

Similar threads

A
Lösungsansätze für eine "STRING_TO_ENUM"-Funktion
Antworten
3
Aufrufe
846
Guga
G
Zurück
Oben