WinCC Tasten bleiben Hängen

batindeko

Level-2
Beiträge
106
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo an Alle,

ich habe bei einem Projekt folgendes Problem:

Ich benutze zwei Tasten im Tipp-Betrieb, um einen Antrieb (Motorventil) zu öffnen und zu schließen. Dafür habe ich im Bereich "Ereignisse" beim Drücken die Funktion (Setzebit = 1) und beim Loslassen die Funktion(Rücksetzebit = 0.)

Jetzt geschieht es aber manchmal, dass wenn ich die Taste loslasse, dass das Signal weiterhin anstehen bleibt. Das hat zur Folge, dass der Antrieb einfach so weiterfährt. Ich muss dann in dem Datenbaustein im SPS selber zurücksetzen.

Kann mir jemand sagen woran das liegen kann und wie ich es verhindern kann?

6AV2124-0XC02-0AX1 (TP2200 Comfort)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Grundsätzlich halte ich die Touchbedienung nicht für die richtige Auswahl für eine Tippfunktion.
1. gibt es Probleme, wenn die Taste verlassen wird oder die Kommunikation instabil ist
2. hat man mind. 100ms Latenz

Hier sollte man IMHO Direkttasten verwenden.
 
Ok. Aber ich lese überall das SetzeBitWährendTasteGedrückt nicht genutzt werden wenn Bool Variable unterstüzt wird
 
Irgendwie war da was, wenn man bei gedrückter Taste mit dem Finger von der Taste rutscht. Das ist dann kein richtiges "Loslassen" Da gibts auch irgend ne Einstellung, die das Verhalten ändern soll. Musst mal lesen und testen.
Bin auch kein Freund von Tipbetrieb über HMI. Dann schon lieber 2 Buttons für Ein Aus...
 
Der Klassiker: Tippbetrieb von Antrieben sollte man grundsätzlich nur mit der Direktasten‐Funktion machen. Bei Setzebit/Rücksetzebit/SetzeBitWährendTasteGedrückt ist nicht garantiert, dass das loslassen der Taste auch in der Steuerung ankommt! Wenn man trotzdem so unerschrocken ist und diese Softfunktionen nutzt, dann nur, wenn in der Nähe des HMI-Panels ein Notaus-Knopf ist, oder wenigstens eine Hardware-Stop-Taste (Öffner), die beim drücken ALLE Software-Tastenbits rücksetzt/löscht.
 
Setzebit/Rücksetzebit/SetzeBitWährendTasteGedrückt ist nicht garantiert, dass das loslassen der Taste auch in der Steuerung ankommt!
Trotzdem sehe ich da eher mal nen Problem bei den HMI-Buttons vom Siemens! Die gehn halt irgendwie manchmal nicht.
Das Problem Kommunikationsausfall hat man ja bei jeder (Hand-) Bedienung vom HMI. Beim Siemens geht aber grundsätzlich das Loslassen von Buttons nicht immer (unanhängig von Kommunikationsproblemen)...

Wenn dabei was schlimmes passieren kann, sollte aber grundsättlich auch irgendwie ne Verriegelung/Abschaltung in der SPS programmiert sein. Und wo der nächste Repschalter oder Notaustaster sitzt, sollte man sich vorher eh anschaun ;)

Grundsätzlich bei Siemens schon seit Jahrzehnten, HMI-Button setzt ein Bit in der SPS, SPS bearbeitet und setzt das Bit zurück. Diese nur vom HMI getoggelten Bit sind und waren schon immer Scheisse... schon alleine, weil viele Bediener die Angewohnheit nicht loswerden, überall sinnlos mehrfach drauf rumzuhämmern 🙈🤔🤣
 
Zuletzt bearbeitet:
Das Projektieren der Direkttasten ist m.W. auch in der TIA Hilfe erklärt. Dazu muss das HMI als Profibus-Slave oder Profinet-Device projektiert werden, was allerdings auch bewirkt, dass beim Stoppen der WinCC-Runtime ein Geräte-Ausfall an die CPU gemeldet wird, was zum STOP der CPU führen kann.
Bei den Direkttasten wird nicht beim drücken und beim loslassen jeweils nur eine Message an die CPU übertragen (Siemens: manchmal auch nicht), sondern der Status der Direkttasten wird zyklisch alle paar ms an die CPU übertragen und bei Kommunikationsausfall gehen die Eingangsbits automatisch in den sicheren Zustand (normalerweise 0-Zustand).
 
Irgendwie war da was, wenn man bei gedrückter Taste mit dem Finger von der Taste rutscht.
Bei älteren Firmware-Ständen der z.B. KTP600 war es so, dass wenn man auf einen Button mit der Funktion "SetzeBitWährendTasteGedrückt" drückt und dann mit den physikalischen Key-Tasten unten das Bild gewechselt hat, dann blieb die Funktion des Buttons weiterhin aktiv.
 
Zurück
Oben