ENUM als Schleifenvariable gute oder schlechte Idee?

[PatrickSt]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dass die Source-Info-Class eine Events-EventClass ist habe ich schon rausgefunden.

Aber nutzt du im gesamten Projekt nur eine einzige Source-Info-Class (die dann für jeden Roboter in jeder Zelle einen eigenen Eintrag braucht), oder mehrere (also pro Zellentyp eine Klasse)?

 

[asci25]

Ich habe nur eine einzige SourceInfo-Klasse für mein gesamtes Projekt. Jeder instanzierte Baustein bekommt nur die SourceID, die dann auf eine EventId der SourceInfo referenziert.
Ich bin auch gerade beim Umstellen vom TC2- auf den TC3-Eventlogger. Ich benutze die TC2 SourceId's einfach weiter.

Ich habe mal nachgeschaut: Meine Sources-EventClass hat 682 Einträge, also habe ich 682 einzelne Objekte.

 

[Monsignore]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

Für mich würde das Heissen dass die Ereignissklasse zur Gruppierung dient. Mit den Ereignissen kann ich Type und das Ereigniss definieren. Wenn ich in den Ereignissen nur überbegriffe definieren kann ich diese beliebig oft verwenden und über Parameter dann noch die einzelnen Details wie BMK etc. Übergeben zur eindeutigen Identifizierung oder habe ich da einen kompletten Denkfehler?

 

[asci25]

... oder habe ich da einen kompletten Denkfehler?

Nein, hast Du nicht. Du hast nur die Source-Info vergessen, die mittlerweile auch lokalisierbar ist. Die Dreiteilung Source-Event-individuelle Datenfelder(BMK, Prozesswert, o.ä.) macht die Architektur perfekt fürs OOP.

 

[Monsignore]

Als Beispiel würde ich jetzt folgendes im TMC Editor anlegen:

• Eventclass = Alarme
  • Event = Pumpenstörung, ID1
  • Event = Fühlerstörung, ID2
  • Event = Wärmeerzeugerstörung ID3
• Eventclass = Warnung
  • Event = Temperaturunterschritten, ID1
  • Event = Temperaturüberschritten, ID2

Ich instanziere also immer wieder die gleiche Eventclasse+Event und mit ipArguments.AddString kann ich diese Meldungen dann genau spezifizieren. Habe ich daraus eine Nachteil den ich jetzt übersehe oder gehört das generell komplett anders aufgebaut?

Danke

 

[Glon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dein .AddString ist nicht übersetzbar.

Am besten:
Eventklasse: Pumpe
- Sicherungsfall
- Überdruck
- usw

Eventklasse: Temperatur
- Übertemp.
- Untertemp.
- Leitungsbruch

Eventklasse: Locations
- Pumpe 1
- Temperaturfühler 3

Dann deinen Pumpembaustein mit den spezifischen Alarmen schreiben und jeweils mit .AddEventReferenceEx um die Location erweitern. Die Location ist nicht hard-coded sondern wird dem Baustein per Schnittstelle übergeben.

Die Standardbausteine + Eventklassen in die Bibo und die Eventklasse Locations ist Projektspezifisch

Somit ist alles Übersetzungsfähig.

 

[PatrickSt]

Eine Anmerkung noch zu der Nachricht von Glon:

Wieder etwas neues gelernt. Für die Übergabe der Location gibt es scheinbar zwei Wege:
Der erste ist hier beschrieben und geht über den FB_TcSourceInfo.
Den zweiten weg über die .AddEventReferenceEx ist hier ganz unten beschrieben (mit Beispielprojekt).

Beim ersten Weg ist die Localization getrennt vom eigentlichen Fehlertext, taucht auch in der HMI, oder im Fenster 'Logged Events' in einer eigenen Spalte auf.

Beim zweiten Weg musst du in jeder Fehlermeldung einen Platz vorsehen, an der du später das 'ReferenceEvent' hinzufügen kannst. Das scheint mir etwas umständlich.

 

[asci25]

Die Eventklasse sollte sich an den Grenzen des Objektes orientieren. Dann hast Du eine Eventklasse je Objekt.
Meine Empfehlung ist: Orientiere Dich bei der Festlegung des Objektes an realen Objekten und mache es nicht zu kleinteilig. Wenn zwei Objekte sich eine gleiche Funktion (z.B. eine Temperaturmessung und -normierung) teilen, kann man die auch kapseln.
Aber die Eventklasse sollte ich am Objekt orientieren.

Die Frage zu dem Vorschlag von Glon wäre:
Gehört die Temperaturmessung zum Objekt Pumpe oder ist es wirklich was eigenständiges? Daraus ergibt sich, ob es u.U. auch sinnvoll wäre die Eventklassen Pumpe und Temperatur zusammenzufassen.

Und AddString nimmst Du bitte nur als Datenfeld für Werte oder BMK's, also Dinge, die Du nicht übersetzen musst.

 

[Glon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich stand vor dem folgenden Problem: Das eigene Meldesystem muss dem TC3_EventLogger weichen (wegen TE2000).

Ich habe viele Standardbausteine (Analog, Servo, Kamera usw.), deren Fehlermeldungen ich standardisieren möchte (auch sprachlich). Ich brauche aber zwingend ein übersetzbares Ortskennzeichen.

Das habe ich mit FB_TcSourceInfo nicht hinbekommen. Die SourceInfo wird immer in einer festen Sprache hinterlegt. Was super merkwürdig ist.
Das bedeutet: Man schaltet in der Visu die Sprache um, aber die SourceInfo bleibt beispielsweise in Englisch.

Genau das ist aber mit .AddEventReferenceEx möglich. Ich finde das unlogisch und würde die SourceInfo lieber dafür nutzen.

Ein weiterer Nachteil ist, dass die Debugging-Möglichkeit mit dem Pfad im PLC-Programm wegfällt, wenn die SourceInfo überschrieben wird. (Ja, könnte man ggf. auch als Metadaten dem Alarm mitgeben.)

 

[PatrickSt]

Ich stand vor dem folgenden Problem: Das eigene Meldesystem muss dem TC3_EventLogger weichen (wegen TE2000).

Ich habe viele Standardbausteine (Analog, Servo, Kamera usw.), deren Fehlermeldungen ich standardisieren möchte (auch sprachlich). Ich brauche aber zwingend ein übersetzbares Ortskennzeichen.

Das habe ich mit FB_TcSourceInfo nicht hinbekommen. Die SourceInfo wird immer in einer festen Sprache hinterlegt. Was super merkwürdig ist.
Das bedeutet: Man schaltet in der Visu die Sprache um, aber die SourceInfo bleibt beispielsweise in Englisch.

Genau das ist aber mit .AddEventReferenceEx möglich. Ich finde das unlogisch und würde die SourceInfo lieber dafür nutzen.

Ein weiterer Nachteil ist, dass die Debugging-Möglichkeit mit dem Pfad im PLC-Programm wegfällt, wenn die SourceInfo überschrieben wird. (Ja, könnte man ggf. auch als Metadaten dem Alarm mitgeben.)

Dass die SourceInfo in einer festen Sprache ist stimmt so aber nicht. Ich bin gerade am implementieren der SourceInfo in meinem Projekt, aber das funktioniert definitiv. Zumindest ab einer gewissen TwinCAT-Version. Welche weiß ich auf Anhieb nicht.

 

[asci25]

Das habe ich mit FB_TcSourceInfo nicht hinbekommen.

Ich habe aus diesem Grund vor einem Jahr die Umstellung auf den TC3-Eventlogger gestoppt, obwohl das Feature seit der 3.2.4026 verfügbar ist und war beim TC2 Eventlogger in der 4024 geblieben. Aber jetzt geht es, ich habe in den letzten Tagen die Umstellung auf den TC3 Eventlogger mit der 3.2.4026 vollzogen. Es funktioniert jetzt. Zumindest in meiner .NET Visu. Wie es in der TE2000 ist, werden die Tests bei einem Kunden von mir zeigen, der zu meinem SPS-Programm eine eigene TE2000 Visu gezimmert hat.

 

[Pippen]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich stand vor dem folgenden Problem: Das eigene Meldesystem muss dem TC3_EventLogger weichen (wegen TE2000).

Ich habe viele Standardbausteine (Analog, Servo, Kamera usw.), deren Fehlermeldungen ich standardisieren möchte (auch sprachlich). Ich brauche aber zwingend ein übersetzbares Ortskennzeichen.

Das habe ich mit FB_TcSourceInfo nicht hinbekommen. Die SourceInfo wird immer in einer festen Sprache hinterlegt. Was super merkwürdig ist.
Das bedeutet: Man schaltet in der Visu die Sprache um, aber die SourceInfo bleibt beispielsweise in Englisch.

Genau das ist aber mit .AddEventReferenceEx möglich. Ich finde das unlogisch und würde die SourceInfo lieber dafür nutzen.

Ein weiterer Nachteil ist, dass die Debugging-Möglichkeit mit dem Pfad im PLC-Programm wegfällt, wenn die SourceInfo überschrieben wird. (Ja, könnte man ggf. auch als Metadaten dem Alarm mitgeben.)

Wieso musste das eigene Meldesystem dem Tc3_EventLogger weichen, wegenTE2000?

Wir sind aktuell auch gerade daran zu prüfen, ob TE2000 etwas für uns wäre. Wir haben auch ein eigene Meldesystem. In diesem Bereich haben wir noch keine Tests mit dem TE2000 gemacht. Ich verstehe aber nicht, wieso man dazu nicht das eigene Meldesystem verwenden könnte.

 

[asci25]

Wieso musste das eigene Meldesystem dem Tc3_EventLogger weichen, wegenTE2000?

TC3 Eventlogger schlägt eigenes Meldesystem um Welten.

Aber, wenn ihr euer eigenes Meldesystem behalten wollt, könnt Ihr das tun. Doch den TC3-Eventlogger kann ich euch nur wärmstens ans Herz legen. Wenn ihr aber eine WinCC-ähnliches Meldesystem in der TE2000 sucht, werdet ihr vergeblich suchen. Das müsst Ihr selbst erstellen.

 

[PatrickSt]

Wie es in der TE2000 ist, werden die Tests bei einem Kunden von mir zeigen, der zu meinem SPS-Programm eine eigene TE2000 Visu gezimmert hat.

Wenn man herausgefunden hat, dass die Source info im Feld "params::localizedSourceName" steht, dann geht es in der TE2000 ganz einfach



sieht dann online so aus:


und wenn man auf deutsch umschaltet:

 

[Pippen]

Zuviel Werbung?
-> Hier kostenlos registrieren

TC3 Eventlogger schlägt eigenes Meldesystem um Welten.

Aber, wenn ihr euer eigenes Meldesystem behalten wollt, könnt Ihr das tun. Doch den TC3-Eventlogger kann ich euch nur wärmstens ans Herz legen. Wenn ihr aber eine WinCC-ähnliches Meldesystem in der TE2000 sucht, werdet ihr vergeblich suchen. Das müsst Ihr selbst erstellen.

Was ist denn so genial an diesem Tc3 EventLogger? Was konnte er mehr als euer Meldesystem? Ich selber kenne den Tc3 EventLogger noch nicht. Ich habe auch schon davon gehört und auch schon das eine oder andere darüber gelesen. Wenn ich aber jeweils lese, dass man so Events anlegt "indem im System-Baum unter "Type System" im TMC-Editor neue Event Classes definiert werden". Dann stellen sich mir bereits die Nackenhaare. Das ist für mich keine richtige Programmierung. Ich traue auch all diesen Editoren (obwohl ich schon fast 20 Jahre mit Beckhoff arbeite) nicht so richtig, weil ich immer wieder negative Erfahrungen gemacht habe. Sowas kann man doch auch mit reiner Programmierung lösen (FB's mit Methoden und Attributen). Das wäre mir viel sympathischer, denn so könnte man solche Events auch aus einem anderen Tool importieren, indem man automatisch Code importiert. Bei solchen Editoren ist das entweder nicht möglich oder nur umständlich.
Aber wenn der Tc3 Eventlogger wirklich so viel besser ist als unser Meldesystem müsste man ihn sich vielleicht doch mal anschauen.

Was überzeugt Dich denn am meisten vom Tc3 Eventlogger?

 

[roboticBeet]

.AddEventReferenceEx

Danke für den Hinweis. So wie es aussieht kann man damit endlich einen Error Stack / Error Propagation umsetzen durch die Verkettung/Referenzierung von Meldungen. Gucke ich mir mal an.

Was ist denn so genial an diesem Tc3 EventLogger?

Du hast direkt recht gute Javascript Klassen fürs TE2000, eine Anbindung an OPC UA Alarms&Conditions, eine gute Performance, Mehrsprachigkeit und mittlerweile auch Metainformationen, bspw. zu möglichen Ursachen und deren Behebung.

Sowas kann man doch auch mit reiner Programmierung lösen (FB's mit Methoden und Attributen)

In der TMC-Datei werden lediglich die Meldungen mit der Meldeschweren und den lokalisierten Texten definiert. Das Handling der Meldungen geschieht komplett in der PLC.
Edit: Also nicht im Stile eines grafischen Editors, in welchem man möglicherweise auch im Editor das entsprechende Meldebit usw. auswählt und sich somit das Meldesystem "nur" zusammeklickt.

 

[asci25]

Sowas kann man doch auch mit reiner Programmierung lösen (FB's mit Methoden und Attributen).

Das macht man doch auch so. Auch beim Eventlogger. Die EventClasses brauchst Du doch nur, damit Du auch die Meldetexte, Hilfelinks, Übersetzungen, Quelleninfo usw. platzieren kannst.

Ich setze schon ewig den TC2 Eventlogger ein.

Das wäre mir viel sympathischer, denn so könnte man solche Events auch aus einem anderen Tool importieren, indem man automatisch Code importiert.

Es gibt ein Excel-Plugin.

Außerdem kannst Du mit etwas Programmiergeschick die TMC-Datei auch selbst erzeugen und als Shared TMC in das SPS-Projekt einbinden. Ich mache das z.B. mit meiner Visu so, sobald die Visukonfiguration fertig ist, schmeißt die Visu auf Knopfdruck die fertigen Meldungen als TMC aus, die ich nur noch einbinde. Null Arbeit mit dem Meldungssystem.

Und mein wichtigster Punkt: Das Meldesystem ist komplett unabhängig von der Visu. Alle Meldungen können systemweit mit einem entsprechenden Client abgerufen werden. Typisch Clients sind: Die Meldungsliste in der Entwicklungsumgebung, die Alarmtabelle im TE2000 oder einem anderen HMI-System, oder was eigenes programmiertes, wie bei mir in der .net-Visu. Egal mit was du kommst, Du hast immer alle Meldungen zur Verfügung. Das fand ich schon beim TC2-Eventlogger genial.

Allerdings was der Editor nicht berauschend, ich habe die XML-Dateien immer direkt bearbeitet und den XML-Formatter genutzt. Das war wesentlich einfacher. Den TMC-Editor nehme ich auch nicht, der ist ähnlich unkomfortabel.

 

[Glon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn man herausgefunden hat, dass die Source info im Feld "params::localizedSourceName" steht, dann geht es in der TE2000 ganz einfach

Anhang anzeigen 93954

sieht dann online so aus:
Anhang anzeigen 93955

und wenn man auf deutsch umschaltet:
Anhang anzeigen 93956

Ich werde Mal wieder verrückt... Ich habe sehr viele Mails mit Beckhoff ausgetauscht und telefoniert. Aber diese Info konnte mir keiner geben...

Das werde ich direkt mal morgen testen.

@Beckhoff:
Ihr habt so geniale Produkte!
Versteckt die nicht hinter einer schlechten Doku! Zeigt eure Release Notes und Changelogs!

 

[Glon]

Wenn man herausgefunden hat, dass die Source info im Feld "params::localizedSourceName" steht, dann geht es in der TE2000 ganz einfach

Ich bekomme es nicht Dynamisch in der PLC hin.

IF xCreate THEN
    xCreate := FALSE;
    fbSourceInfo.Clear();
    fbSourceInfo.guid := Global.TC_EVENTS.TranslationEventClass.Door.uuidEventClass;
    fbSourceInfo.nId := Global.TC_EVENTS.TranslationEventClass.Door.nEventId;
    fbSourceInfo.sName := 'Door';
    HRESULT:= fbAlarm.CreateEx(TC_EVENTS.StandardEventClass.Problem_1, 0,fbSourceInfo);
END_IF

Ohne die Zeile funktioniert es nicht.

fbSourceInfo.sName := 'Door';

Bei sName muss der Translation Key rein.



Ich habe allerdings noch keinen Weg gefunden, diesen Translation Key zur PLC-Laufzeit abzufragen.

Wie machst du das?
Bisher ergibt es gar keinen Sinn.

Meine Idee ist folgende:
Es gibt Standardalarme, die um eine projektspezifische Quelle erweitert werden.
Meine Kollegen nehmen dann beispielsweise den Motor-Baustein und übergeben diesem per Schnittstelle die SourceInfo.

Wenn der sName (Translation Key) jedoch hardcoded übergeben werden muss, ergeben sich etliche Fehlermöglichkeiten.

 

[asci25]

Vorschlag aus der Praxis:

Nur eine einzige SourceEventclass verwenden, alle Sources als Events anlegen.
Den Translationkey numerisch nutzen, dann kann man den an der Bausteinschnittstelle incrementell hochgerechnet übergeben. Dann lässt sich das wunderbar objektorientiert über mehrere Ebenen verwenden.

So mache ich das, ein Beispiel:

fbMain
    |
    fbSystem
    |   | EventId:= 1000
    |    fbRemote
    |    |   | EventId:=EventId(fbSystem) + 1
    |    fbEnvironment
    |    |   | EventId:=EventId(fbSystem) + 10
    |    afbEtherCatDiagnosis[1..6]
    |        | EventId:=EventId(fbSystem) + 99 + (Index)
    |
    fbLoadAreaA
    |    | EventId:= 10000
    |    fbProcessCtrl
    |    |    | EventId:=EventId(fbLoadAreaA) + 200
    |    fbLoadHandling
    |        | EventId:=EventId(fbLoadAreaA) + 320
    |  
    fbLoadAreaB
        | EventId:= 20000
        fbProcessCtrl
        |    | EventId:=EventId(fbLoadAreaB) + 200
        fbLoadHandling
            | EventId:=EventId(fbLoadAreaB) + 320

fbLoadAreaA und fbLoadAreaB sind übrigens der gleiche Funktionsbaustein in zwei unterschiedlichen Instanzen. Die Darstellung ist stark vereinfacht.

Dann wandelst Du die EventId in einen String um und übergibst den an den FB_TcSourceInfo

//Set source info
        afbTcSourceInfo[nGlobalLoopIndex].Clear();
         afbTcSourceInfo[nGlobalLoopIndex].guid             := TC_EVENT_CLASSES.Sources;
        afbTcSourceInfo[nGlobalLoopIndex].ExtendName(concat('SD_' ,UDINT_TO_STRING(gastEventList[nGlobalLoopIndex].stEventLog.stEventData.SourceId)));
        afbTcSourceInfo[nGlobalLoopIndex].nId             := gastEventList[nGlobalLoopIndex].stEventLog.stEventData.SourceId;

Den gibst Du dann Deinem Event mit:

//Create the alarm
        afbTcV2Alarm[nGlobalLoopIndex].Create(
            eventClass            := gastEventList[nGlobalLoopIndex].gEventClass,
            nEventId            := gastEventList[nGlobalLoopIndex].stEventLog.stEventData.Id,
            eSeverity            := F_CreateSeverityFromTc2(gastEventList[nGlobalLoopIndex].stEventLog.stEventData.Class),
            bWithConfirmation    := FALSE,          
            ipSourceInfo        := afbTcSourceInfo[nGlobalLoopIndex]);

Und so sieht meine SourceEventClass aus