TIA Gesammten Datenbausstein auswerten

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mir ist immer noch schleierhaft, warum man so "komplizierte" Wege gehen soll. 1000 Bits auf min einer ist auf TRUE vergleichen geht mit ein paar Zeilen SCL Code. Und wenn einen diese paar Zeilen in ein Zykluszeitproblem treibt, sorry aber das kann ich nicht glauben. Daher mal bitte Fakten vom Beitrag #25 Schreiber

 

[fabey]

Wieviel ist eine "deutliche" Zykluszeitverlängerung? 1000 Bits in einer Schleife abfragen sollte einer 1500 CPU nicht wirklich was ausmachen.

Mir ist immer noch schleierhaft, warum man so "komplizierte" Wege gehen soll. 1000 Bits auf min einer ist auf TRUE vergleichen geht mit ein paar Zeilen SCL Code. Und wenn einen diese paar Zeilen in ein Zykluszeitproblem treibt, sorry aber das kann ich nicht glauben.

Der Baustein vergleicht von 800 Fehlerbits in einer for-Schleife ob der Fehler vorher schon da war mit Hilfe eines Zwischenspeichers in dem die Fehlerbits nach dem Vergleich per MOVE_BLK geschrieben wurden. So kann ein "FaultNew"-Bit gesetzt werden. Anschließend das gleiche nochmal mit 400 Warnungsbits. Also dient der Baustein nur dazu zu erkennen: "Es gibt eine neue Fehler / Warnung". Das ganze beansprucht mehr als 60ms Zykluszeit bei einer 1515F-2 PN.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Baustein vergleicht von 800 Fehlerbits in einer for-Schleife ob der Fehler vorher schon da war mit Hilfe eines Zwischenspeichers in dem die Fehlerbits nach dem Vergleich per MOVE_BLK geschrieben wurden. So kann ein "FaultNew"-Bit gesetzt werden. Anschließend das gleiche nochmal mit 400 Warnungsbits. Also dient der Baustein nur dazu zu erkennen: "Es gibt eine neue Fehler / Warnung". Das ganze beansprucht mehr als 60ms Zykluszeit bei einer 1515F-2 PN.

Das zweifle ich jetzt mal stark an. Wir haben Maschinen da werden hunderte DINT/REAL in FOR Schleifen behandelt und es gibt
keine spürbaren Auswirkungen.

Die von dir genannte CPU hat laut technischen Daten eine Bitverarbeitungszeit von 30 Nannosekunden.
Gehen wir jetzt einmal von einer FOR Schleife mit 10.000 Bitoperationen aus dann wären das 300.000 Nannosekunden = 0,3 Millisekunden

 

[Ralle]

Der Baustein vergleicht von 800 Fehlerbits in einer for-Schleife ob der Fehler vorher schon da war mit Hilfe eines Zwischenspeichers in dem die Fehlerbits nach dem Vergleich per MOVE_BLK geschrieben wurden. So kann ein "FaultNew"-Bit gesetzt werden. Anschließend das gleiche nochmal mit 400 Warnungsbits. Also dient der Baustein nur dazu zu erkennen: "Es gibt eine neue Fehler / Warnung". Das ganze beansprucht mehr als 60ms Zykluszeit bei einer 1515F-2 PN.

Dann solltest du das aber keinesfalls mit AWL prgrammieren, denn das ist das Langsamste, was man auf einer 1500-er überhaupt machen kann. Anders als bei den alten 300/400-er SPS wird AWL dort nur interpretiert.

 

[DeltaMikeAir]

Dann solltest du das aber keinesfalls mit AWL prgrammieren, denn das ist das Langsamste, was man auf einer 1500-er überhaupt machen kann. Anders als bei den alten 300/400-er SPS wird AWL dort nur interpretiert.

Beispiele wurden hier ja schon genannt, wie man das "modern und lesbar" macht
https://www.sps-forum.de/threads/gesammten-datenbausstein-auswerten.104720/#post-795850

 

[rlw]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
der TS ist ja schon seit 14 Tagen nicht mehr dabei, aber wenn ich den richtig verstanden habe, dann will er nur eine Auswertung auf einen Leuchtmelder legen um eine Sammelstörung anzuzeigen. Machen wir ja auch so, weil die Einzelmeldungen liegen auf Bits in einem dafür angelegten DB und die geben wir an WinCC oder TIA WinCC um sie dort zu protokollieren/archivieren
Um jetzt zu erkennen ob noch irgend ein Bit im DB gesetzt ist lesen wir wir in einer Schleife alle Datenwörter des DB und ODERIEREN diese.
Ist das Ergenis nicht null, liegt ein Fehler vor , also Lampe an. Sind bei 1024 Meldung nur 32 DDW.

 

[fabey]

Dann solltest du das aber keinesfalls mit AWL prgrammieren

Wo habe ich geschrieben dass es AWL ist? Es ist in SCL so ähnlich wie in @DeltaMikeAir vorherigem Beitrag in diesem Thema umgesetzt.

Schleife alle Datenwörter des DB

Habe ich nicht bei einem optimierten Baustein mit einem Fehlerbit-Array.

Woran kann das dann liegen, wenn die CPU es sehr gut schaffen müsste? Es sind wirklich nur die beiden for-Schleifen und die beiden MOVE_BLKs...

 

[rlw]

Habe ich nicht bei einem optimierten Baustein mit einem Fehlerbit-Array.

Optimierten DB will ich dabei nicht. Wie gesagt kein Array sondern Einzelbits. Sicherungen, MS-Schalter und sonstige Meldung sind auf Einzelbits gelegt, teilweise müssen die Fehler ja auch noch verknüpft werden ( Beispiel Drucküberwachung verzögert ein ).

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Baustein vergleicht von 800 Fehlerbits in einer for-Schleife ob der Fehler vorher schon da war mit Hilfe eines Zwischenspeichers in dem die Fehlerbits nach dem Vergleich per MOVE_BLK geschrieben wurden. So kann ein "FaultNew"-Bit gesetzt werden. Anschließend das gleiche nochmal mit 400 Warnungsbits. Also dient der Baustein nur dazu zu erkennen: "Es gibt eine neue Fehler / Warnung". Das ganze beansprucht mehr als 60ms Zykluszeit bei einer 1515F-2 PN.

Habe ich nicht bei einem optimierten Baustein mit einem Fehlerbit-Array.

Woran kann das dann liegen, wenn die CPU es sehr gut schaffen müsste? Es sind wirklich nur die beiden for-Schleifen und die beiden MOVE_BLKs...

Das sind doch dann schon 2 gleiche Fehlerbit-Arrays (am Besten vom gleichen udt), oder?

Die kann man doch bei 'ner S7-1x00 direkt vergleichen und zuweisen.
Da braucht man weder MOVE_BLK noch FOR:

FaultNew := FehlerbitArrayOld <> FehlerbitArray;
FehlerbitArrayOld := FehlerbitArray;

Optimiert/nicht optimiert spielt dabei keine Rolle.
Entscheidend ist doch nur, das die Struktur von neu und alt gleich sind.
Und genau dafür sind benutzerdefinierte PLC-Datentypen (udt).

 

[fabey]

Da braucht man weder MOVE_BLK noch FOR

Gerade getestet: Das MOVE_BLK hat es so sehr verlangsamt. Mit der einfachen Zuweisung geht es viel schneller. Das war anscheinend das Problem und nicht die for-Schleifen.

 

[vollmi]

Gerade getestet: Das MOVE_BLK hat es so sehr verlangsamt. Mit der einfachen Zuweisung geht es viel schneller. Das war anscheinend das Problem und nicht die for-Schleifen.

EIN MOVE_BLK Aufruf hat deine Zykluszeit um 60ms erhöht? Oder hast du den möglicherweise in der FOR Schleife aufgerufen?

 

[fabey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich kann nicht genau sagen woran es lag... Die MOVE_BLK waren nicht in der Schleife. Habe es so wie @hucki gesagt hat gemacht nun.

Vielen Dank an alle!

 

[hucki]

Ich kann nicht genau sagen woran es lag... Die MOVE_BLK waren nicht in der Schleife. Habe es so wie @hucki gesagt hat gemacht nun.

Bei noch mal drüber nachdenken bekommst Du mit dem ARRAY-Vergleich auf UNGLEICH auch eine Meldung beim Rücksetzen eines Fehler-BITs.
Du solltest also zum Detektieren weiterhin die Schleife mit dem Check der einzelnen BITs auf TRUE verwenden und nur zum Sichern des ARRAYs die direkte Zuweisung.

 

[DeltaMikeAir]

Bei noch mal drüber nachdenken bekommst Du mit dem ARRAY-Vergleich auf UNGLEICH auch eine Meldung beim Rücksetzen eines Fehler-BITs.
Du solltest also zum Detektieren weiterhin die Schleife mit dem Check der einzelnen BITs auf TRUE verwenden und nur zum Sichern des ARRAYs die direkte Zuweisung.

Ich verstehe es auch nicht. Es gibt so einfache Lösungen per FOR Schleife, warum da riesige Arrays für Vergleiche einrichten und hin und her vergleichen.

 

[rlw]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich verstehe es auch nicht. Es gibt so einfache Lösungen per FOR Schleife, warum da riesige Arrays für Vergleiche einrichten und hin und her vergleichen.

Wenn ich einen Altwert/Neuwert Vergleich brauche um eine Änderung zu erkennen oder eine Änderungsmitteilung an eine übergeordnete
Steuerung senden muss, dann Vergleiche ich. Wenn ich aber nur erkennen will ob ein Bereich nicht Null ist, dann ist eine For Schleife mit ein
bischen bolscher Verknüpfung völlig ausreichend .