Kommentare zu einer Realisierung

kor

Level-2
Beiträge
37
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
WINCC: Kommentare zu einer Realisierung

Hallo

Ich bin ein relativ neuer benutzer von WinCc. Jetzt habe ich ein Projekt realisiert und möchte dazu eine komentar von Leuten die schon etwas besser im Umgang mit´WIncc sind.
Also folgendes:
Ich habe eine Lizenz für 512 tags. Da ich damit nicht auskommen würde, wenn ich alle Variablen so wie sie sind in Wincc integriere habe ich zu einem Trick gegriffen. Ich übertrage alle boolschen Variablen aus einem Datenbaustein der SPS mittels DWORD-Variable in wincc. Das heißt ich lege für jeweils 32 boolsche Variable ein Dword an, dass ich mit der entsprechende Adresse des Datenbausteines verlinke. Dazu schrieb ich für jede DWORD- Variable ein Globales Skript, welches bei änderungen getriggert wird. In diesem Skript zerlege ich das Dword in einzelne interne Variablen. Somit arbeite ich in Wincc mit den einzelnen (boolschen) internen Variablen und das Skript hält diese im Hintergrund aktuell.
Manche dieser Variablen sollen aber bidirektional sein, d.h. aus wincc herraus sollen Äbnderungen an die SPS geschickt werden. Dazu habe ich den Umgekehrten Weg eingeschlagen. Ich schrieb für jede boolsche Variable ein Skript, welches bei Änderung dieser Variable an die betreffende Stelle des DWORD seinen Wert schreibt. Somit arbeite ich weiterhin nur mit den internen Variablen und alles andere passiert im Hintergrund. Für die anschließende Visualisierung sehr übersichtlich finde ich.
ALLERDINGS ist das Anlegen der Skripten doch aufwändig. Von der SPS zu Wincc ist es nicht so schlimm, aber für die Variablen die bidirektional sein sollen muss ich jeweils ein Skript schreiben. So 100 waren das schon, zwar wird viel Kopiert und wenige Buchstaben geändert, aber es benötigt trozdem ein paar Stunden Zeit. ein weitere Nachteil der mir eingefallen ist. ist dass wenn ich interne Variablen umbenenne ich diese auch im Skript umbenennen muss (nehme nicht an das das automatisch geht)
Was hält ihr davon?

Lg


P.S. ich habe einrecht primitives Bild von dem Sachverhalt im Anhang gepostet.
 

Anhänge

  • forum_krit.jpg
    forum_krit.jpg
    47,9 KB · Aufrufe: 56
Zuletzt bearbeitet:
Wenn du die Bits aus Kostengründen in eine DWORD Variable schreibst,
dann trenne wenigstens die Richtung SPS->WinCC und WinCC->SPS sauber auf.
Sonst ist das Verwirrspiel bei anschließender Pflege der Software perfekt.

Ich würde mit eine Funktion bauen die als Eingangsparameter DWORD hat und als Ausgangsparameter die 16 bzw. 32 Bits hat.
Dies in beide Richtungen also einmal Bits zusammensetzen und einmal Auseinander pflücken.
Dann kann von "aussen" die jeweilige Variable angeschaltet werden.

Gruss Micha
 
Was viel gemacht wird, und meiner Meinung nach auch sauber umgesetzt werden kann ist die Zusammenfassung in Statuswort und Befehlswort pro Antriebsobjekt.
Bei uns hat dann jeder Antriebstyp dazu ein Word oder Dword. Die Auftrennung in einzelne Bits geschieht aber nicht durch zerlegen und umrangieren auf interne Variablen, sondern in den Bildobjekten, also Faceplates und den zugehörigen Bedienmasken.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

aus meiner Sicht wird damit auch eine Menge unnötige Kommunikationslast erzeugt. Es müssen ja ständig sämtliche DWord-Variablen zyklisch gelesen werden, um eine Änderung zu erkennen.
 
aus meiner Sicht wird damit auch eine Menge unnötige Kommunikationslast erzeugt. Es müssen ja ständig sämtliche DWord-Variablen zyklisch gelesen werden, um eine Änderung zu erkennen.

Für ein Bit wird auch immer ein komplettes Byte gelesen, die 3 Bytes mehr machen dann anteilig gesehen im Protokoll nicht mehr viel aus.
Ich habe in meinem Status-Dword auch die Triggerbits für Alarm-/Stör-/Betriebsmeldungen liegen, das wird eh zyklisch eingelesen auch wenn ein Bild nicht aufgerufen ist.
 
Ja, mag sein. Kommt halt auf die Menge und den Bus an und wer da noch alles mit dranhängt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Viele Statusbits in der SPS zu DWORD zusammenfassen und in der HMI als nur 1 DWORD-Variable/Tag lesen empfinde ich als OK (und kann auch die Kommunikationslast signifikant verringern). Der Zugriff auf ein Bit in einem DWORD wird sogar an vielen Stellen in WinCC (flexible) direkt unterstützt. Man muß nicht das Sammel-DWORD zyklisch lesen und auf Einzel-Bool-Tags aufdröseln. Allerdings geht bei dem Zusammenfassen die Symbolik und Dokumentation der Funktion der Einzelbits verloren.

Schreibbits oder bidirektionale Bits in der HMI zusammenfassen geht aber gar nicht. Vor allem, weil bei jedem Schreiben eines Bits in die SPS auch unbeteiligte Bits beschrieben werden. Da geht jede "Multitasking"-Fähigkeit verloren. Selbst wenn man vor dem Schreiben erst das komplette DWORD aus der SPS ausliest, das gewünschte Bit manipuliert und das DWORD in die SPS zurückschreibt, dann vergeht Zeit, in der sich das Ziel-DWORD in der SPS unerwartet verändert haben kann. Das ergibt dann oft hübsche "unerklärliche" Phänomene, z.B. wenn der Operator zu schnell klickt.

Harald
 
Schreibbits oder bidirektionale Bits in der HMI zusammenfassen geht aber gar nicht. Vor allem, weil bei jedem Schreiben eines Bits in die SPS auch unbeteiligte Bits beschrieben werden. Da geht jede "Multitasking"-Fähigkeit verloren. Selbst wenn man vor dem Schreiben erst das komplette DWORD aus der SPS ausliest, das gewünschte Bit manipuliert und das DWORD in die SPS zurückschreibt, dann vergeht Zeit, in der sich das Ziel-DWORD in der SPS unerwartet verändert haben kann. Das ergibt dann oft hübsche "unerklärliche" Phänomene, z.B. wenn der Operator zu schnell klickt.

Bei mir ist dieses Befehlswort exklusiv für Befehle reserviert. Vom HMI wird dieses Wort nur geschrieben und nicht gelesen. Alle Befehle werden 1-Aktiv geschrieben, und nach Abarbeitung im SPS-Programm wieder auf 0 zurückgesetzt.
Bei allen mir bekannten Visus werden Schreibbefehle unverzüglich an die Steuerung abgesetzt, und landen nicht in einer Warteschlange.
Wenn der Bediener einen Antrieb ein- und dann sofort wieder ausschaltet, wird direkt hintereinander z.B. 16#1 und dann 16#2 in die SPS geschrieben. (wenn Bit 0 für ein und Bit 1 für ausschalten ist). Da die SPS die Befehle auch in dieser Reihenfolge bekommt und abarbeitet, ist meiner Meinung nach die korrekte Reihenfolge gewährleistet.
 
Hmm, selbst bei write-only-Tags würde ich nicht darauf vertrauen, daß alle Schreibaufträge in der SPS ankommen. Wenn es einen wie auch immer gearteten "Kommunikationsengpass" gibt, könnte es dann nicht passieren, daß das HMI dann nur die letzte Zuweisung an das Tag tatsächlich in die SPS schreibt? Oder mehrere Schreibtelegramme innerhalb des selben OB1-Zyklus in der SPS ankommen und deshalb nur das letzte gilt?

Die Problematik mit dem erst-lesen-dann-schreiben (oder nur-schreiben) wollte ich für den TE erwähnen, weil ich nicht sehe, ob er das schon erkannt hat und beachtet. Die Problematik ist ja nicht ganz so trivial wie das Schreiben auf Einzelbits.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo

Danke für eure Antworten. Ich entnehme dem, mein Konzept noch verbesserungswürdig ist aber für den beginn durchaus akzeptabel. Bin selber nicht glücklich, voralem mit meinen schriebzugriffen welche ich sicher in zukunft anders organisieren werde.

Lg
 
Zuletzt bearbeitet:
Wenn Du Dir das WinCC Beispielprojekt genauer angesehen hättest, hättest Du auch die Lösung mit den Status und Steuerworten gefunden... Ich hab das Gefühl, du realisierst genau das, was dort gezeigt wird, nur auf viel längerem Weg ... Die meisten Dinge werden wir Dir hier ähnlich empfehlen.

Gruß.
 
Wenn du dich an Steuer- und Stautswort hältst, dann fällt auch dieser Quatsch mit den Scripten und den bidirektionellen Variablen weg.
Auf Steuerungsseite kannst du das wunderbar in UDTs packen und im WinCC kannst du mit Faceplates arbeiten.
Dann hast du a) weniger Aufwand und b) ist es verständlich und wartbar.

Gruß
Dieter
 
Zurück
Oben