WinCC Unified Bit-Verarbeitung in Unified Faceplate

Zuviel Werbung?
-> Hier kostenlos registrieren
Jetzt hätte ich aber noch eine Frage.Hat man dann bei einm Faceplate immer eine HMI-Variable und ein SPS-Variable die zur Laufzeit an das entsprechende Faceplate angebunden wird?Die Datentypen sind dann gleich.Ein UDT_Instanz wegen mir aus.
 
Ich verwende eine Funktion von Siemens (SetzteBitin Variable)!
  • Falls in der Zwischenzeit (während das HMI liest und schreibt) die SPS andere Bits derselben Variable geändert hat, könnten diese Änderungen durch den Schreibvorgang des HMIs überschrieben werden.
  • Dies führt zu einem Zustand, bei dem ungewollte Änderungen an der DWORD-Variable auftreten, da nicht alle Bits mehr den korrekten Zustand haben.

Ich hatte neulich auch ein solches "Problem" und jetzt wo ich mir das alles nochmal durch den Kopf gehen lasse frage ich mich:

Warum gibt es diese Funktion SetzeBitInVariable ???
Bzw. warum legt Siemens da keine Beschränkung für gewisse Datentypen drauf? Oder gibt eine Meldung dazu?

So etwas kann sehr gefährlich werden bei einer Anlage in Betrieb (passende Szenarien kann sich sicher jeder selbst ausdenken).
Gerade weil es ja keine selbstgeschriebenen Skripte sind, sondern die super tollen und performanten Systemfunktionen von Siemens, welche sogar von Siemens empfohlen werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das stammt halt noch aus einer Zeit in der Siemens davon ausging, dass die Leute die Programmieren wissen was sie da tun.
Dann bin ich scheinbar nicht aus einer solchen Zeit...
Kannst du mir dann sagen wofür man diese Funktion SetzeBitInVariable damals benutzt hat, weil scheinbar ja nicht für solche Bitübertragungen in WORD/INT/ usw. ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
z.b. wenn nur das Panel Bit´s invertiert. Es also nur schreibende Zugriffe durch die Visu gibt.
Sobald Panel und SPS ( oder wer auch immer ) auf diese Variable schreiben, dann gibt es Probleme.
Ja das kann funktionieren, hab ich tatsächlich noch nie so eingesetzt.
Danke dir
 
Aber wahrscheinlich ist das auch damit behoben : eine Zeile vorne Weg die Variabel zu lesen... mit der Read() funktion.
Naja, du liest die Variable, Unified invertiert dir das gewünschte BIT und die Variable wird zurück geschrieben.
Wenn innerhalb dieser Zeit sich ein Bit in deiner Variable ändert ( also zwischen lesen und zurück schreiben ), dann wird
diese Änderung überschrieben!
 
Zuletzt bearbeitet:
um jetzt die Verwirrung noch zu steigern, wenn eine Variable in der SPS innerhalb eines SPS-Zyklus mehrmals mit unterschiedlichen Werten beschrieben wird, dann ist selbst das HMI-Lesen einer ganz normalen Bool-Variablen Zufall, da bei S7-400/1200/1500 nicht mehr im Zykluskontrollpunkt kommuniziert wird... Bei "InvertiereBit" kommt dann ganz großer Quatsch raus, deshalb würd ich "InvertiereBit" auch nie verwenden, sondern immer 2 Buttons im HMI anlegen, einen zum setzen und nen anderen zum rücksetzen...
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
WinCC Unified: Ergänzende Hinweise zu bestimmten Systemfunktionen für Variablenänderung

Kann gerade nicht testen... Aber wahrscheinlich ist das auch damit behoben : eine Zeile vorne Weg die Variabel zu lesen... mit der Read() funktion.
Naja, du liest die Variable, Unified invertiert dir das gewünschte BIT und die Variable wird zurück geschrieben.
Wenn inerhalb dieser Zeit sich ein Bit in deiner Variable ändert ( also zwischen lesen und zurück schreiben ), dann wird
diese Änderung überschrieben!
ich würde den Siemens FAQ so interpretieren:
- in unified liest die Funktion "SetzeBitInVariable" NICHT selbst das entsprechende DWORD aus der SPS
- deshalb musst Du im Script in der Zeile vorher händisch lesen
- oder das DWORD irgendwo im aktuellen Bild an nem EA-Feld haben...

damit "SetzeBitInVariable" überhaupt funktioniert muss:
Externe Variablen:
  • Die Verbindung zur PLC ist aufgebaut
  • Die Erfassungsart der Variablen ist "Zyklisch im Betrieb"
  • (V16) Die Variable wird durch ein Objekt, z. B. ein E/A-Feld verwendet
  • (V17, V18) Die Variable wird an der Eigenschaft "Prozesswert" eines Objekts verwendet
Um diese Bedingungen zu erfüllen, projektieren Sie eines der folgenden Objekte in einem Bild, in dem eine der obigen Systemfunktionen aufgerufen wird:
  • Ein EA-Feld, das die zu ändernde Variable anzeigt
  • Ein Skript, welches die Variable ("Variablenname").Read() ausführt,

das gleiche Problem auch bei folgenden Funktionen:
  • SetzeBitInVariable
  • RücksetzeBitInVariable
  • VerringereVariable
  • ErhöheVariable
  • InvertiereBitInVariable
 
Zuletzt bearbeitet:
Was mir jetzt noch nicht klar ist.Wenn du für ein Faceplate einen UDT erstellst, hätte ich jetzt erwartet dass man direkt
einen Datensatz übergibt und der dann aktualisiert wird.Das Faceplate ist ja ein Objekt?
Ist das so richtig?
 
ich würde den Siemens FAQ so interpretieren:
- in unified liest die Funktion "SetzeBitInVariable" NICHT selbst das entsprechende DWORD aus der SPS
- deshalb musst Du im Script in der Zeile vorher händisch lesen
- oder das DWORD irgendwo im aktuellen Bild an nem EA-Feld haben...

damit "SetzeBitInVariable" überhaupt funktioniert muss:



das gleiche Problem auch bei folgenden Funktionen:
Leider hat das nicht funktioniert (auch nicht mit der vorherigen Read-Funktion). Ich habe jedoch festgestellt, dass das Problem eindeutig mit dem Lesevorgang zusammenhängt. Wenn ich das Faceplate schließe und erneut öffne, nachdem die DWORD-Variable in der SPS geändert wurde, wird die Visualisierung korrekt aktualisiert, da dann ein neuer Lesezyklus gestartet wird. Da es für das EA-Feld keinen manuellen Trigger gibt, bleibt nur abzuwarten, bis der nächste Lesezyklus erfolgt, was im Grunde mit dem Bildaufbau zusammenfällt.

Für mein DWORD werde ich es in 8 BOOL-Variablen aufteilen (für alle Bits, die ich auch in der SPS beschreiben muss) und die restlichen Bits als BYTE behandeln (diese werden nur gelesen, z. B. für Funktionen wie Blinken oder Enable)... Ich bin mir sicher das ich bei WinCC das Problem nicht hatte.
 
Das Problem ist kein Fehlverhalten, sondern ein prinzipielles Multitasking-Problem, weil bei der Kommunikation Zeit vergeht. Da dürfen verschiedene Task nur koordiniert dieselbe Variable beschreiben. Tun sie das unkoodiniert, dann kommt es zu dem beschriebenen Problem, dass Änderungen aus einer Task durch die andere Task überschrieben werden und so verloren gehen können.
Wenn du die Bits wahlfrei von beiden Seiten (HMI und PLC) setzen/rücksetzen willst, dann kannst/darfst du nicht SetzeBitInVariable verwenden.

Wir haben hier im Forum seit vielen Jahren immer wieder die speziellen Verhaltensweisen der Systemfunktionen SetzeBitInVariable, RücksetzeBitInVariable, SetzeBitWährendTasteGedrückt ... thematisiert (siehe Forumssuche nach SetzeBitinVariable). Wegen dem Multitasking-Charakter der HMI-Kommunikation, verschärft durch die eine Weile dauernde Kommunikationszeit, kann bei diesen Funktionen prinzipiell nicht garantiert werden, dass sich die Funktionen immer wie erwartet verhalten, wenn auf die Variablen unkoordiniert (ohne Handshake) von HMI und PLC geschrieben wird. Leider muss man feststellen, dass diese Funktionen immer wieder von Anwendern unbedarft verwendet werden, ohne die speziellen Problematiken zu kennen oder wenigstens zu erahnen ... und irgendwann wird festgestellt, dass da manchmal was schiefgeht ... Dabei braucht doch einfach nur die Beschreibung der Funktionen in der Siemens Dokumentation aufmerksam gelesen zu werden.

Schon in der ProTool-Hilfe stand vor mehr als 20 Jahren:
Bit_setzen_in_Variable
Hinweis
ProTool schreibt bei Verwendung dieser Funktion nach der Änderung des gewünschten Bits die gesamte Variable zurück, ohne zu prüfen, ob sich andere Bits der Variablen zwischenzeitlich geändert haben. Deshalb darf von anderer Stelle nur lesender Zugriff auf diese Variable erfolgen. Dies gilt auch für den Wert in der Steuerung. Dies bedeutet auch, dass keine weiteren Bitmanipulationen dieser Variable erlaubt sind.

Der Hinweis steht seitdem auch in jeder WinCC flexible und WinCC TIA Version, z.B. aktuell für V19:
Systemhandbuch TIA V19 Teil 14 Prozesse visualisieren (Seite 1664), SetzeBitInVariable / SetBitInTag
SetzeBitInVariable (RT Advanced, Basic Panels, Panels, Comfort Panels)
(...)
Die Systemfunktion überträgt nach der Änderung des angegebenen Bits die gesamte Variable wieder an die Steuerung. Es wird nicht geprüft, ob sich zwischenzeitlich andere Bits in der Variablen geändert haben. Bediener und Steuerung dürfen auf die angegebene Variable nur lesend zugreifen, bis die Variable wieder an die Steuerung übertragen wurde.
Hinweis
Verwenden Sie diese Systemfunktion nicht, wenn die Steuerung BOOL-Variablen unterstützt.
Verwenden Sie statt dessen die Systemfunktion "SetzeBit".

Nun für WinCC Unfied ist der Hinweis nochmal verschärft formuliert:
Systemhandbuch WinCC Unified V19 Kapitel 9.2.52 (Seite 1118)
9.2.52 SetzeBitInVariable
Beschreibung
Setzt das Bit mit der angegebenen Nummer in der Variablen auf 1 (True).
Die Systemfunktion überträgt nach der Änderung des angegebenen Bits die gesamte Variable wieder an die PLC. Es wird nicht geprüft, ob sich zwischenzeitlich andere Bits in der Variablen geändert haben. HMI-Gerät und PLC dürfen auf die angegebene Variable nur lesend zugreifen, bis die Variable wieder an die PLC übertragen wurde.(...)
Hinweis
Die Systemfunktion wird mit dem letzten bekannten Prozesswert ausgeführt. Da dieser Prozesswert nicht in allen Fällen aktuell gehalten werden kann, ist es verboten, dass dieser von mehreren Quellen geschrieben wird (z. B. vom HMI-Gerät über Skripte und von der PLC). Damit wird sichergestellt, dass der Wert der geändert wird, auch tatsächlich dem Prozesswert entspricht.
(fette Markierung von mir)

In WinCC Unified gibt es übrigens auch neue Systemfunktionen z.B. LeseUndSetzeBitInVariable / ReadAndSetBitInTag. Die LeseUnd...-Funktionen lesen explizit den aktuellen Wert der Variable aus der PLC vor der Manipulation, doch auch da gelten die Restriktionen für Schreibzugriffe.
 
Zurück
Oben