TIA anzahl bits mit wert "true" zählen

Beiträge
21
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
hallo,

ich habe in tia v16 (cpu 1510) einen db mit 128 störmeldebits. die bits in diesem db sind nich nicht als array deklariert, sondern "einzeln" (jedes bit muss einen bezeichner erhalten).

wie kann ich zählen wieviele bits den zustand true haben?

das heisst ich möchte zählen wieviele störungen aktuell anstehen.

danke, mfg
 
Die Bits irgendwie in ein Bool-Array bringen (kopieren) oder mit einem Array überlagern (AT), dann kann man in einer Schleife die Bits indiziert ansprechen und zählen.
Oder den DB auf "Standard"-Zugriff einstellen (nicht "optimiert"), dann kann man die Bits über die Speicheradressen ansprechen (DBX/DBB/DBW/DBD).

Harald
 
Im Grunde reicht es, das Bitfeld an einen nicht-optimierten Baustein zu übergeben (an einen Input-Parameter mit der Struktur des Bitfeldes) und den Input-Parameter mit einem Bool-Array per AT zu überlagern.

Harald
 
wie kann ich zählen wieviele bits den zustand true haben?
Wie genau muss das Ergebnis sein?
Wenn Dich nur interessiert, ob mehr oder weiniger als z.B. 10 der vielen Bits den Zustand True haben, könntest Du die Zählerei abbrechen, sobald Du 11-mal True gezählt hast.

Obwohl es hier um MeldungsBits geht und hoffentlich nie mehr als 50% der Bits True sein werden:
wenn man die Anzahl der True-Bits haben will und man weiss, dass normalerweise die meisten der Bits True sein dürften, könnte man auch die Bits mit dem Zustand False zählen und diese Zahl von der GesamtZahl der Bits subtrahieren.

Falls Du jeweils 32 Bits in 1 DD (DatenDoppelWort) stehen hast, kannst Du prüfen ob das DD gleich oder ungleich 0 ist.
Ist es 0, so muss das DD nicht näher untersucht werden und Du kannst direkt das nächste DD unter die Lupe nehmen.
Dieses Verfahren spart erheblich Zeit, wenn nur sehr wenige der Bits True sind.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dieses Verfahren spart erheblich Zeit, wenn nur sehr wenige der Bits True sind.
Zeit sparen ist bei SPS aber eher unklug, wenn es dann bei unvorhergesehenen/"unwahrscheinlichen" Zuständen (z.B. Meldeschwällen) zu schwankender Zykluszeit oder gar zur erheblichen Erhöhung der Zykluszeit führt. Besser sind Algorithmen, die unabhängig von den Daten immer gleich lange brauchen - da weiß man gleich nach dem Einspielen des Programms wie hoch die Zykluszeit wird, und nicht erst nach hochsporadischem unwahrscheinlichem unglücklichem Zusammentreffen von Ereignissen...

Harald
 
Falls Du jeweils 32 Bits in 1 DD (DatenDoppelWort) stehen hast, kannst Du prüfen ob das DD gleich oder ungleich 0 ist.
Und bei TIA sollte man vorerst auch von "optimierter" Datenablage ausgehen, bei der man dann nicht an die eventuellen DD heran konmt, in denen die Bits sich befinden könnten.
Daher die hier häufig angesprochene Übergabe in definierte Strukturen.
 
die bits in diesem db sind nich nicht als array deklariert, sondern "einzeln" (jedes bit muss einen bezeichner erhalten).
Ich nutze lieber Array plus globale Konstante als Bezeichner, z.B.:
MyFault["MyFuse"]... MyFault["MySwitch"]...
Ist IMHO genauso lautsprechend, wie einzelne Symbole im STRUCT.

Und die Kommentare der einzelnen Arrayfelder können ja mittlerweile auch verschieden ausgeführt werden.


Was aber dabei noch nervt, dass die Konstanten nicht auch gleich für's HMI gelten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
kannst dir das mal anschauen. ich benutze das auch u.A. dafür
der db darf nicht optimiert sein.

der hintergrund zu der bitauswahl.
ich definiere störungen mit dem geraden bit. das folgende ungerade bit dient zur quittierung der störung in der hmi
aber welche bits gezählt werden kann man am in ja auswählen
 
Zuletzt bearbeitet:
Zeit sparen ist bei SPS aber eher unklug, ... Besser sind Algorithmen, die unabhängig von den Daten immer gleich lange brauchen - da weiß man gleich nach dem Einspielen des Programms wie hoch die Zykluszeit wird, ...
Sicher doch. Dessen muss man sich bewusst sein und das stelle ich nicht in Abrede.
Ich denke dabei an das Vorhandensein vieler solcher "besseren" Algorithmen in einem Progamm, die bei gleichzeitiger Aktivität zwar gleichmässig, aber in Summe eben doch allzu sehr die ZyklusZeit in die Länge ziehen.
So gesehen ist man doch schon mal in der ZwangsLage, sich z.B. über ein vorzeitiges Abbrechen einer Schleife Gedanken zu machen und diese Gedanken auch in die Praxis umzusetzen. Solange man aber weiss, was man da tut, worauf man sich einlässt und, dass man ggfs auch GegenMassnahmen treffen muss ... in welcher Form auch immer.
Ich hatte zu S5-Zeiten sehr mit laaangen und z.T. auch mit mehr oder weniger schwankenden ZyklusZeiten zu kämpfen (und ein einziges Mal sogar mit einer zu kurzen ZyklusZeit!).
Von den ZyklusZeiten, in denen ihr euch heute tummelt, konnte ich damals nur träumen. Aber das ändert nichts an den GrundPrinzipien.

Eine Aktion mit konstanter Dauer, die aber nur gelegentlich bzw. alle n Zyklen stattfindet, führt ebenfalls zu Schwankungen der ZyklusZeit.

Daher die hier häufig angesprochene Übergabe in definierte Strukturen.
Ja, ebendrum. "Hier häufig angesprochen" und ich wollte nicht auch noch ein weiteres Mal in dieselbe Kerbe hauen. Die NichtErwähnung bedeutet aber nicht, dass ich anderer Meinung bin. ;)
 
Zurück
Oben