TIA Frage zur Triggervarible bei Bit Meldungen

Zuviel Werbung?
-> Hier kostenlos registrieren
? Das Word selber hat aber doch schon seine 16 Bit also kann ich doch schon direkt mit den Bits vom Word als Melde-trigger arbeiten... ich sehe kein Vorteil das ganze dann noch in ein array zu schreiben... Variable error1 Type word ... im Programm für gewünschte Meldung error1.%X0 bis 15 setzen und Meldung wird im hmi angezeigt... wenn ich jetzt noch mehr Meldungen Brauch lege ich einfach im DB eine weitere Variable bsp. Error2 Type word an und schon hab ich nicht mehr 16 sondern 32 Melde-trigger... warum hier ein array benutzen ???
Gruß
Kumpelblase
 
Moin Kumpelblase,
der Onkel macht das wahrscheinlich aus dem selben Grund wie ich, es spart ganz einfach arbeit :ROFLMAO:
Jedes neue Word was man anlegt, muss ja sowohl in der SPS als auch im HMI angelegt werden. Und wenn man nicht nur 16 oder 32, sondern mehrere Hundert Meldungen hat, dann ist es einfach einfacher, nur eine Array-Grenze im DB und im HMI zu erhöhen, als endlos neue Variablen anzulegen. Außerdem verbraucht das Array im HMI nur einen einzigen Tag - zwei einzelne Störworte verbrauchen schon zwei Tags. Und zu guter letzt ist es für mich persönlich einfacher in der SPS mit einem Array zu arbeiten um bspw. die Anzahl aller Störungen zu zählen oder eine Summenstörung auszugeben, weil sich ein Array schön in einer Schleife durchsuchen lässt.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,
Ihr nutzt aber jedes Word (16bit) vom array komplett aus oder? Wie sieht dann den der Befehl in der Steuerung aus? Error_db.error[0].error.%X0 ? als Beispiel? Hab mir da nie Gedanken drüber gemacht da tia wie Excel arbeitet was das vermehren (hehehe) von variablen angeht. Selbst bei 1000 Meldungen. Es geht ja kein Mensch (hoffe ich zumindest) hin und unterteilt sein Programm nicht in Stationen.... ich gehe normal hin und arbeite mit 3bis5 Word pro station wo ich in der Symbolik gleich die Station mit beschrifte. Macht das suchen am ende deutlich einfacher. Und ob ich jetzt einfach in der Tabelle die weiteren vari. ziehe oder mein array um 10 erhöhe hm..... okay das thema mit den Power Tags ist ein gutes Argument. Finde wie gesagt nur die Übersicht leider extrem darunter.
Gruß
Kumpelblase
 
jupp, ich nutze nahezu alle Bits im Word. Manchmal lasse ich ein paar Lücken als Reserve, wenn ich glaube, da kommen noch ähnliche Störungen hinzu. Den Zugriff mache ich nicht via Slice, sondern ich habe einen 16-Bit zu 1 Word Baustein, der die Einzelnen Störungen als Eingänge bekommt und ein Word aus dem Array als Ausgang. Das ist hier intern historisch begründet und ich habe mich noch nicht von diesem Konzept trennen können/wollen. Grundsätzlich hast du aber natürlich recht - einzelne "sprechende" Bezeichner haben auch was für sich. Das muss halt jeder selbst entscheiden. In meinen Störtexten steht als Präfix immer sowas wie "S2.7" - womit ich weis, dass es sich um das Störword 2 Bit 7 handelt. So kann ich dann in meinem 16-Bit zu 1 Word-Konverter nach dem Word 2 und dem Bit 7 suchen und von dort rückwärts via Querverweise nach der Ursache der Störung suchen... aber wie gesagt, da verfolgt jeder eigene Konzepte.
Deshalb finde ich persönlich das Konzept vom "neuen" Program_Alarm ganz gut, das Löst viele der angesprochenen Probleme.
 
.. der Onkel macht das wahrscheinlich aus dem selben Grund wie ich, es spart ganz einfach arbeit :ROFLMAO:
Genau, es spart Arbeit und vor allem Zeit. Allerdings ziehe ich hierfür im DB keine ARRAYS auf.

Kumpelblase, versuche mal, die Variablendeklarationen am HMI und in der PLC geistig auseinander zu halten. Ich hatte es eigentlich schon kurz erwähnt. Am HMI wird eine Variable angelegt als Array of Word. Das sind z.Bsp. 16Word. Dieses Array ist im Prinzip ein Zeiger auf die entsprechende Adresse in der PLC, wo die Störmeldebits angelegt sind. In der PLC gibt es unter dieser Adresse einen Datenbaustein mit 256 boolschen Variablen (16Word = 256Bool). Diese sind NICHT in einem Array angelegt! Jedes dieser Bits ist sehr sorgfältig mit Symbol und Kommentar versehen! Wenn es an der Anlage nur 10 Meldungen gibt, dann ist der Rest dieser 256 Bits ganz einfach Reserve. Gibt es sehr viele Meldungen, so gibt es einen zweiten oder auch dritten Meldebereich a 256 Meldungen. So handhabe ich das zumindest in meinen Fällen. Dann gibt es noch die Quittierbits, die ebenfalls in diesen Datenbaustein liegen. Meldungen ohne Quittierung sind natürlich einfacher zu handeln.

Somit kopiere ich nur noch die Kommentare aus dem DB als Meldetexte in die HMI-Projektierung und versorge die Variablen im DB mit den entsprechenden Ereignissen. An der eigentlichen Struktur muss normalerweise niemals mehr etwas geändert werden.

Diese Struktur verwende ich bereits aus den Zeiten als Protool noch State of the Art war. Dort mussten die Triggerbits und die zugehörigen Quittierbits zwangsweise in aufeinanderfolgenden Datenbereichen liegen. Ist das heute in Flexible bzw. TIA nicht mehr so? Ich kenne es eigentlich gar nicht anders. Es war es eigentlich immer ganz sinnvoll, bei Systemwechseln das Meldesystem bei zu behalten.

 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin
Meinst du multiplexen?
Wie legst du ne interne vari. als array of word an?
Als externe mit absoluter Zugriff ... wie gibst du den Bereich des DB's ein?
Hast du vielleicht ein Beispiel?
Ps. Oder machst du das ganze über Verbindung Bereichszeiger.
Gruß
Kumpelblase
 
Okay hab es,
Es ist keine interne hmi vari sondern ne plc vari die über absoluten Zugriff auf den DB zugreift. Verstehe hm. Schön ist dabei das man seine Meldungen im Programm über bit bearbeitet und man so sehr schön mit den kommentar seine hmi Meldung bauen kann und man schön im PC Programm schauen kann wenn der Fehler gesetzt wurde wo er herkommt(Querverweise). Aber irgendwie hab ich Probleme (zumindest in der simu) das mein hmi die Meldungen verzögert anzeigt ( und es liegt nicht am Erfassungszyklus 100ms) werd es mal auf Hardware testen.
Gruß
Kumpelblase
 
Wenn du eh dabei bist deine Meldungen zu überarbeiten, dann solltest du dir der Vollständigkeit halber auch den Program_Alarm-Baustein von Siemens mal anschauen (einfach in der Hilfe "Program_Alarm" suchen).
Das wäre ein komplett anderes/neues Konzept für das erzeugen der Meldungen und hat auch gewissen Charme.
 
Zurück
Oben