TIA TP700 Comfort Buttons bleiben hängen

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich frag mich halt nur, warum man von vorne herein die umständliche Variante mit doppeltem Projektierungsaufwand nimmtr

Ähhmm... Nochmal.

Weil Siemens anscheinend schon seit WinCC-Flex in seiner Hilfe stehen hat dass die Funktion "SetzBitWährendTasteGedrückt" nicht bei Steuerungen verwendet werden soll die den Datentyp Bool unterstützen. Also alle Simatic-Steuerungen.
Anscheinend ist der Befehel, wie PN/DP schon schrieb, nur für exotische Steuerungen gedacht welche diesen Typ nicht haben.

Insofern ist die Verwendung von Setze-/Rücksetze-Bit laut WinCC-Hilfe die korrekte Variante.
Es wird sogar ausdrücklich darauf hingewiesen stattdessen die Funktion "SetzeBit" zu nehmen.

Hinweis

Verwenden Sie diese Systemfunktion nicht, wenn die Steuerung BOOL-Variablen unterstützt.
Verwenden Sie statt dessen die Systemfunktion "SetzeBit".

 

[Slaine]

Also ich kenne die Problematik unter WinCC, WinCC Flexible und auch unter TIA. Ich habe mir daher angewöhnt, in der Visualisierung nur zu setzen (SetzeBitInVariable) und das Rücksetzen im Programmcode der SPS zu machen. Umgekehrt mache ich es bei den Meldungen. Die werden erst dann auf der SPS zurückgesetzt, wenn ich die Rückmeldung vom Panel bekommen habe, dass die Meldung auch wirklich da angekommen ist. Ist zwar etwas mehr Aufwand, aber dafür absolut zuverlässig.

Und statt den Taster gedrückt zu halten, würde ich lieber zwei einzelne Taster auf/zu nehmen. Tasten gedrückt zu halten ist imho ein absoluter Krampf. Egal, ob mit Maus oder am Touchpanel.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mich würde auch nicht wundern, wenn einige der Probleme mit nicht funktionierenden Tastbefehlen von einer nicht geeigneten Programmierung stammen. Insbesondere bei S7-400 Steuerungen oder S7-300 mit priorisierter BuB-Kommunikation muss man schon genau hinschauen wie man zu programmieren hat, damit es mit der Bedienung kompatibel ist.

Die Funktionen um ein Bit in einem Word oder Dword zu setzen sind doppelt problematisch, da hier ja immer das komplette Wort gelesen, dann das Bit einmaskiert und dann wieder das ganze Wort zurückgeschrieben wird. Wenn dann zwischen dem Lesen und Schreiben von HMI jemand in der SPS am Wort etwas modifiziert, wird dieses womöglich später wieder aufgehoben. Ich habe schon mehrere solche Programme gesehen, bei denen die Bedienung eigentlich nur zufällig funktioniert.
Die Funktion "SetzeBitWaehrendTasteGedrueckt" schreibt auch nur einmalig beim Drücken das Wort runter, und beim Loslassen nochmal.

 

[Ottmar]

Hi!

Also ich hatte noch nie Probleme mit der laut Siemens weniger geeigneten Methode.

Deswegen mein Unverständnis. Da verlasse ich mich doch lieber auf meine eigenen Erfahrungen, als pauschal irgendwas zu glauben, was von Siemens mal niedergeschrieben wurde.

Mich wundert nur die Inkonsequenz in diesem Thread. Denn sonst wird konsequent über alles was Big-S in die weite Welt schickt gemosert. Und hier ist ein Satz absolut bindend und rechtfertigt 100% mehr Projektierungsaufwand.

Aber gut. Das kann ja jeder gottseidank so machen wie er will.

Sorry.

Gruß,

Ottmar

 

[rostiger Nagel]

somit könne wir erst einmal festhalten, beide Funktionen funktionieren nicht Sauber.

Ist halt Siemens, ein einfaches setzen von Boolvariablen muss ja auch nicht unbedingt
bei einer SPS funktonieren. Da gibt es wichtigeres, zb. Farben bei den Engernieringsytem.

Hi!

Also ich hatte noch nie Probleme mit der laut Siemens weniger geeigneten Methode.

Deswegen mein Unverständnis. Da verlasse ich mich doch lieber auf meine eigenen Erfahrungen, als pauschal irgendwas zu glauben, was von Siemens mal niedergeschrieben wurde.

Mich wundert nur die Inkonsequenz in diesem Thread. Denn sonst wird konsequent über alles was Big-S in die weite Welt schickt gemosert. Und hier ist ein Satz absolut bindend und rechtfertigt 100% mehr Projektierungsaufwand.

Aber gut. Das kann ja jeder gottseidank so machen wie er will.

Sorry.

Gruß,

Ottmar

Ich habe doch gemosert.

 

[silverfreaky]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich halte auch die Slaine Variante für richtig.In der Visualisierung werden Bits gesetzt.Sie Sps setzt das VisuBit zurück und setzt ihr internes Bit.
Man kann dann alle Schaltvorgänge nur noch mit Setze Bit machen.In der SPS gibt's einen FB der wertet das aus.Muss man halt bei vielen Schaltern Multiinstanzen
in einen FB knallen.Am besten den Baustein gleich mit Hand und Auto Modus.

 

[RONIN]

Mich wundert nur die Inkonsequenz in diesem Thread. Denn sonst wird konsequent über alles was Big-S in die weite Welt schickt gemosert. Und hier ist ein Satz absolut bindend und rechtfertigt 100% mehr Projektierungsaufwand

Wie du auch sicher gelesen hast stimmen meine Beobachtungen mit deinen überein. Auch ich nutze die Funktion öfters....

Zum Thema "mosern". Da bringst du was durcheinander. Ich mosere auch ständig wenn bei Siemens was nicht geht was eigentlich gehen sollte. Wenn Siemens aber schon selber mal sagt das was nicht geht... Hmm.. da werde ich zumindest hellhörig. :roll:

Wurde aber bis heute noch nicht auf die Passage aufmerksam gemacht, bin auch nie auf die Idee gekommen da rein zu schauen.
War für mich selbstverständlich dass dies die richtige Funktion ist, vor allem da Setze/Rücksetze schon mehrmals bei mir gezickt hat...
Die einzige schlaue Lösung ist womöglich keine der Varianten zu nehmen.

 

[Lipperlandstern]

Man kann den Fehler eigentlich ganz einfach simulieren : Taste drücken und Verbindung unterbrechen. Schon bleibt das Bit in der Steuerung gesetzt. Das kann auch vielleicht der Grund sein wRum manche das Problem oft und manche gar nicht kennen

 

[rr_zx]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen

Kann es sein, das ihr in der SPS die Variablen in einem FB über die InOut-Schnittstelle verwendet?
Das Problem hierbei ist, das der FB beim öffnen des Programms den kompletten InOut-Bereich kopiert. Danach wird beim abarbeiten des Programms nur im kopierten Bereich manipuliert, zum schluss wird der kopierte Bereich wieder zurückgeschrieben. Wenn jetzt genau während dieser Zeit eine Taste gedrückt wird, kann diese Trigger verloren gehen. Zwar wird ganz kurz die Variable gesetzt, aber beim Ende des FB wieder zurückgesetzt.

Viele Grüsse
Ralph

 

[PN/DP]

Kann es sein, daß beim Ereignis Drücken zuerst ein Skript eingetragen ist oder beim Ereignis Klicken etwas eingetragen ist? Da kann es nämlich passieren, daß die erwartete Abarbeitungsreihenfolge der Systemfunktionen nicht eingehalten wird. In dem Fall muß bei Loslassen vor dem RuecksetzeBit zuerst ein (Dummy-)Skript aufgerufen werden, damit das Rücksetzen in die niederpriore Skript-Warteschlange eingereiht wird und sich nicht vordrängeln kann. Dieses Vorgehen ist bei SetzeBitWaehrendTasteGedrueckt nicht möglich - vielleicht schreibt Siemens auch deshalb, daß SetzeBitWaehrendTasteGedrueckt nicht verwendet werden soll?

habe ich eine Funktion "Öffne Schieber solange Button gedrückt" es echt blöd wqenn da ein paar tonnen mehr raus kommen und man nur über NOT-Halt den Schieber zu bekommt.....

Ein erneutes Drücken und Loslassen der Schaltfläche bewirkt nichts?

Harald

 

[Ottmar]

Hi!

SetzeBitWährendTasteGedrückt setzt sich bestimmt aus den zwei skripten "drücken" und "loslassen" zusammen. Alles andere wäre ja umständlich...

Gruß,

Ottmar

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

... es ist Siemens und deshalb nicht einfach so einfach. Eigentlich müsste SetzeBitWaehrendTasteGedrueckt in SetzeBitInVariable und RuecksetzeBitInVariable compiliert werden, wobei es vermutlich nicht ganz das selbe ist - ich meine, vor dem RuecksetzeBitInVariable wird die Variable nicht nochmal gelesen, sondern es wird mit dem Wert von vor SetzeBitInVariable gearbeitet. Deshalb Anwendungs-Warnungen in der Hilfe. (das Verhalten sollte man sniffern können)
Ich kann mir aber vorstellen, daß SetzeBitWaehrendTasteGedrueckt automatisch in SetzeBit und RuecksetzeBit compiliert wird, wenn die angegebene Variable eine Bool-Variable ist, was erklären würde, warum die Nichtbeachtung der Empfehlung zur Nichtnutzung von SetzeBitWaehrendTasteGedrueckt folgenlos bleibt.

Harald

 

[JesperMP]

Lustig, auch mit andere HMI Software (RSView) kenne ich Probleme mit Taster die bit-aktiv-wärend-taste-aktiv funktionalität haben.
Ich glaube es ist ein fundamentale Problem, das der Bedienerschnittstelle in HMI Programme Ereignissgesteuert sind. Das macht Funktione die eigentlich Zyklisch sind grundsätslich unsicher.

Also ich kenne die Problematik unter WinCC, WinCC Flexible und auch unter TIA. Ich habe mir daher angewöhnt, in der Visualisierung nur zu setzen (SetzeBitInVariable) und das Rücksetzen im Programmcode der SPS zu machen. Umgekehrt mache ich es bei den Meldungen. Die werden erst dann auf der SPS zurückgesetzt, wenn ich die Rückmeldung vom Panel bekommen habe, dass die Meldung auch wirklich da angekommen ist. Ist zwar etwas mehr Aufwand, aber dafür absolut zuverlässig.

Und statt den Taster gedrückt zu halten, würde ich lieber zwei einzelne Taster auf/zu nehmen. Tasten gedrückt zu halten ist imho ein absoluter Krampf. Egal, ob mit Maus oder am Touchpanel.

+1 !
Alle meine Taster sind genau so programmiert, mit einige Ausnahmen.
Für die Ausnahmen (Test Funktione für Ventile z.B.) habe ich sicherheitshalber mehrere Sicherheitsfunktione so das der Tastenvariabel nicht in den aktivierte Stellung bleiben kann.
Etwa wie, Bild wird Verlassen --> alle die in das Bild "bit-aktiv-wärend-taste-aktiv" Variabeln ausschalten. Plus, max-timer für alle "bit-aktiv-wärend-taste-aktiv" Variabeln.

 

[rostiger Nagel]

... es ist Siemens und deshalb nicht einfach so einfach. Eigentlich müsste SetzeBitWaehrendTasteGedrueckt in SetzeBitInVariable und RuecksetzeBitInVariable compiliert werden, wobei es vermutlich nicht ganz das selbe ist - ich meine, vor dem RuecksetzeBitInVariable wird die Variable nicht nochmal gelesen, sondern es wird mit dem Wert von vor SetzeBitInVariable gearbeitet. Deshalb Anwendungs-Warnungen in der Hilfe. (das Verhalten sollte man sniffern können)
Ich kann mir aber vorstellen, daß SetzeBitWaehrendTasteGedrueckt automatisch in SetzeBit und RuecksetzeBit compiliert wird, wenn die angegebene Variable eine Bool-Variable ist, was erklären würde, warum die Nichtbeachtung der Empfehlung zur Nichtnutzung von SetzeBitWaehrendTasteGedrueckt folgenlos bleibt.

Harald

Mal ganz ehrlich sollte es mir als User egal sein was Siemens da macht, es hat einfach zu funktionieren.

Es kann doch nicht so schwer sein, das über das Engeerniering System erkannt wird, der User möchte
ein Bit aus einen Wort setzen oder ein Bit als Bool und dann hat die Software entsprechend zu funktonieren.

Grundsätzlich fehlt also die Funktion "SetzeBitWährendTasteGedrücktAlsBool",
wahrscheinlich liegt es daran das diese Funktion beim Tastendruck am häufigsten gebraucht wird, hat sich
Siemens gedacht 'Lassen wir einfach mal fehlen'. So können wir User seit ProTool Zeiten mit einer ständig
ändernden nicht Funktionstüchtigen Eigenschaft rumärgern.

 

[Softi79]

Zuviel Werbung?
-> Hier kostenlos registrieren

@rostiger Nagel: Seh ich auch so icst mir doch egal wie und was Siemens da macht, wenn es die Funktion gibt dann muss diese einfach funktionieren.
Vermutung von Siemens Hotline ist: Der Fokus auf die Schaltfläche geht verloren weil z.B. ein Script ausgeführt wird oder der Aufgabenplaner dazwischen funkt.... Den Aufgabenplaner nutzen wir nicht und die der Fehler tritt bei Funktionen auf mit und ohne Script....
Ein "Dummy" Script einzufügen damit die Prios bei Siemens wieder passen mag eine Lösung sein, aber ehrlich da weiger ich mich fast schon sowas zu machen und dann musst in 10 Jahren wieder jemand erklären warum das in der Software steht.

Bei Sütron und Beckhoff haben wir diese Probleme nicht und auch bei den alten TP177 / OP17 etc. hatten wir das Problem nicht.
Aber irgendwelche Funktionen scheinen wir zu nutzen die andere nicht nutzen .... So viele Meldungen gibt es zu dem Problem TIA / TP700 nicht...


Gruß Softi

 

[PN/DP]

Aber irgendwelche Funktionen scheinen wir zu nutzen die andere nicht nutzen .... So viele Meldungen gibt es zu dem Problem TIA / TP700 nicht...

Vielleicht ist es ja auch so, daß überhaupt nur wenige Leute diese unsicheren Funktionen nutzen?
Tipp-Betrieb ("solangeTasteGedrückt" oder "Setze"+"Ruecksetze bei Loslassen") mit nur einmaliger Event-Übertragung über Kommunikationsbus ist auch ohne Bugs eine unsichere Sache.

Wenn man einen dauernden Tastendruck über Bus übertragen muß, dann als DP- oder PN-Direkttaste, da wird der Zustand der Taste zyklisch übertragen und die Kommunikation überwacht und im Fehlerfall das Tastenbit in der Steuerung automatisch in den Failsafe-Zustand gebracht.

Ich habe für mich entschieden, daß ich generell im HMI nur Bits setze und in der SPS nach der Verarbeitung rücksetze. Deshalb habe ich noch nie ein derartiges Problem gehabt.

Harald

 

[Softi79]

Hi PN/DP,

wir haben die Zuverlässigkeit bis jetzt nie in Frage gestellt, da es funktioniert hat, wir werden jetzt die Software überarbeiten und es genau so machen Bit in Oberfläche setzen und nach Verarbeitung in der SPS zurück setzen.

bei ca. 5 Funktionen brauchen wir die Funktion "Mache solange Button gedrückt" wo kann ich die "DP- oder PN-Direkttaste" anlegen bei einem TP700?
bzw. Verknüpfen in nächster Zeit zusätzlich einen Hardwaretaster.

Gruß Softi

 

[IBFS]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe für mich entschieden, daß ich generell im HMI nur Bits setze und in der SPS nach der Verarbeitung rücksetze. Deshalb habe ich noch nie ein derartiges Problem gehabt.

Das ist mir auch die liebste Variante!

 

[PN/DP]

wo kann ich die "DP- oder PN-Direkttaste" anlegen bei einem TP700?

In der Gerätekonfiguration
Allgemein > PROFINET Schnittstelle > Betriebsart > I-Device-Kommunikation

Siehe meinen Link auf das Siemens Anwendungsbeispiel in Beitrag #3,
in der Dokumentation-PDF des Anwendungsbeispiels Kapitel 4.2.1 Seite 25

dann mache das wenigstens als Profinet-Direkttaste, da wird zumindest die Kommunikation überwacht.
Anwendungsbeispiel: Direkttasten Anwendung bei Touch- und Key Panels

Harald

 

[Softi79]

Ohje Ohje da sind aber viele Einschränkungen und Merkmale

Einschränkungen für PROFINET IO-Direkttasten
• Direkttasten sind auch dann aktiv, wenn sich das Bediengerät in der Betriebsart „Offline“ befindet.
• Wird eine externe Applikation, wie Pocket Internet Explorer oder Control Panel gestartet, so wird diese im Vordergrund aktiv und legt die Runtime in den Hintergrund. Das Bit für die Funktion „DirekttasteBildnummer“ ist nicht mehr gesetzt und die Tasten oder Schaltflächen mit der projektierten Funktion „Direkttaste“ lösen das zugehörige Bit in der Steuerung nicht mehr aus.
• Die gleichzeitige Verwendung von PROFINET IO-Direkttasten und PROFIBUS DP-Direkttasten ist nicht möglich.
• Wenn die Kommunikation über PROFINET IO freigegeben wird, ist die Benutzung der seriellen Schnittstelle nicht zulässig.
• Sie können Direkttasten nur am lokalen Bediengerät bedienen. Am Sm@rtClient ist die Bedienung der Taste/Schaltfläche für die Direkttaste möglich. Es wird aber kein Bit im E/A-Bereich der CPU gesetzt.
• Direkttasten, die einer Schaltfläche zugeordnet sind, werden nur durch Touch-Bedienung getriggert. Ein Auslösen durch Mausklick, z. B. bei angeschlossener USB-Maus, ist nicht möglich.
• Direkttasten werden bei Touch-Bedienung unabhängig von einem projektierten Kennwortschutz getriggert.
• Bildobjekte, die sich in Runtime über der Schaltfläche mit der Systemfunktion „Direkttaste“ befinden, verdecken die Schaltfläche zwar optisch. Die Bildobjekte verhindern jedoch nicht die Auslösung der Systemfunktion „Direkttaste“.
• Bei Bediengeräten mit Touch-Bedienung dürfen Sie Schaltflächen, die Sie als Direkttasten verwenden, nicht wie folgt über Skripte verändern:
– verschieben
– in der Größe verändern
– ausblenden
– gegen Bedienung sperren