WinCC Unified Einzelne Variablen gehen nicht mehr

Gillton

Level-2
Beiträge
20
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich melde mich mal mit einem sehr banalen Problemen... :rolleyes:

Mein Kollege hat ein Projekt auf unserem Firmenstandard aufgesetzt und angepasst.
Die Variablen werden in einem FB bearbeitet und im DB werden die passenden Zustände/Werte angezeigt.
Die Visualisierung dieser z.B. boolschen Variablen befindet sich auf einem MTP1500 V20.0 mit hunderten anderen Variablen. Soweit so gut...

Nun tritt aber gerade bei diesem "abgepeckterem" Projekt das Problem auf, dass einige Variablen im HMI nicht erkannt und dargestellt werden, obwohl die Verbindung zur SPS besteht und alle anderen Elemente sauber angezeigt werden. -> Variable wechselt von false auf true und soll im HMI grün aufleuchten, jedoch tut sich da nix, obwohl ich im DB den Zustandswechsel beobachte.

Es betrifft nicht alle Variablen/Effekte/etc. sondern wirklich 1/2 Verknüpfungen auf einem Bild. Sobald man diese Variable aus der HMI Variablentabelle rauslöscht und direkt wieder über eine symbolische Verknüpfung einfügt und übersetzt, funktioniert die Darstellung wieder.

Hatte jemand schon mal ein solches Problem? (CPU als auch Visu werden zum testen simuliert)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nun tritt aber gerade bei diesem "abgepeckterem" Projekt das Problem auf, dass einige Variablen im HMI nicht erkannt und dargestellt werden, obwohl die Verbindung zur SPS besteht und alle anderen Elemente sauber angezeigt werden. -> Variable wechselt von false auf true und soll im HMI grün aufleuchten, jedoch tut sich da nix, obwohl ich im DB den Zustandswechsel beobachte.
Was meinst du mit "werden nicht erkannt und dargestellt"? Zeigen die ###### oder irgendwelche Fehlermeldungen?
Oder meinst du, dass die Variablen mit falschen, nicht plausiblen, eventuell auch wechselnden/blinkenden Werten dargestellt werden? Das könnte am Multitasking "HMI-Kommunikation nicht im Zykluskontrollpunkt" liegen. Werden den Variablen im SPS-Zyklus evtl. mehrmals Werte zugewiesen, z.B. erstmal initialisieren und vielleicht später den richtigen Wert zuweisen?
Gerade gestern gab es hier ein ähnliches Problem, was auch auf dem Multitasking der HMI-Kommunikation beruht:
 
Da gibts aktuell was bei Siemens auf der Seite...

Habe ich heute noch gesehen finde das aber grade nicht mehr. Bestimmt kan DMA den Link liefern...

Das Problem besteht irgendwie wenn der Variablenname in der CPU geändert wird...

Ich suche mal weiter...
 
bei symbolischem Zugriff auf Variablen der PLC wäre das doch normal. Dann muss man HMI übersetzen und in Panel laden und gut is
Im Normalfall ja aber bei Unified V20 gibt es da anscheinend ein Problem (siehe Screenshot in #5). So wie ich das PDF von Tia V20 Update 3 interpretiere, ist das Problem im aktuellen Update 3 auch noch drin.

Wobei ich nicht glaube, dass dies das Problem des Fragestellers ist.
 
Zuletzt bearbeitet:
Mit "nicht erkannt und falsch dargestellt" meinte ich, dass ich im DB eine Variable beobachte und diese sich ändert, während im HMI unter einer Dynamisierung sich nichts verändert (z.B wird mit einer Bool die Farbe geändert).
Bei E/A-Feldern taucht das Warndreieck im Element auf und das Element selbst ist ausgegraut (gleiche Ansicht wie bei Komm.verlust).
Bei anderen Elementen wird die Dynamisierung einfach nicht ausgeführt.

Zum Thema Zykluskontrollpunkt bin ich etwas verwirrt. Wir nutzen die 1500er Serie, und müssten somit was tun? Einen bestimmten Zyklus für die HMI-Kommunikation vorgeben oder die I/Os lesen?

An den PLC-Datentypen wird nichts geändert. Wenn wir z.B ein HMI Bild mit einem P&ID darstellen, nehmen wir eine Vorlage und passen einzelne Dynamisierungen an. Beim Testen kommt es nun vor, dass einige Dynamisierungen nicht mehr angezeigt werden, bis die betroffene Variable im HMI neu eingebunden wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das mit dem Zykluskontrollpunkt ist nicht so das Thema wenn man halbwegs ordentlich arbeitet.

Merken tut's man eh nur wenn eine Variable im Programm an mehreren Stellen hin und her geändert und diese dann am HMI angezeigt wird.

Beispiel:
Am anfang des SPS-Zyklus wird eine Variable mit 0 beschrieben weil man will diese initialisieren.
Dann erhält sie im weiteren Programm neue Werte z.B. 5 dann 18 dann 3 usw.

Das HMI greift nun nicht mehr wie früher zu 300'er Zeiten zwischen dem Schreiben der Ausgänge und dem Lesen der Eingänge auf die Variablen zu, sondern irgendwo im Zyklus, halt dann wenn grad Zeit ist, unabhängig vom SPS-Zyklus. Dabei kann es zu "falsch" angezeigten Variablen kommen, verständlicher Weise.
 
Das mit dem Zykluskontrollpunkt ist nicht so das Thema wenn man halbwegs ordentlich arbeitet.

Merken tut's man eh nur wenn eine Variable im Programm an mehreren Stellen hin und her geändert und diese dann am HMI angezeigt wird.

Beispiel:
Am anfang des SPS-Zyklus wird eine Variable mit 0 beschrieben weil man will diese initialisieren.
Dann erhält sie im weiteren Programm neue Werte z.B. 5 dann 18 dann 3 usw.

Das HMI greift nun nicht mehr wie früher zu 300'er Zeiten zwischen dem Schreiben der Ausgänge und dem Lesen der Eingänge auf die Variablen zu, sondern irgendwo im Zyklus, halt dann wenn grad Zeit ist, unabhängig vom SPS-Zyklus. Dabei kann es zu "falsch" angezeigten Variablen kommen, verständlicher Weise.
Danke für die Aufklärung!
Mir fällt kein Fall ein, indem wir eine Variable im gleichen Zyklus mehrfach beschreiben. Dies ist durch unterschiedliche Zustände abgesichert.
Ich bin mir auch nicht sicher, wieso das Problem gerade in diesem neusten Projekt so drastisch auftaucht. Wir hatten noch nie solche Fehler, und schon gar nicht bei bislang 10+ Variablen in einem einzigen Projekt.
Und wenn das HMI asynchron auf die SPS zugreift, müsste dann nicht im nächsten Zyklus der Wert wieder eingelesen worden sein (HMI-Aktualisierung)?
 
Zum Thema Zykluskontrollpunkt bin ich etwas verwirrt.
Details wurden hier im Forum schon einige Male erörtert
Oft ist auch ein Problem, dass HMI-Variablen an Bausteine an IN_OUT per Value übergeben werden, dann wird nach Ende des Bausteins der Wert des Übergabeparameters in die HMI-Variable zurückkopiert. Wenn während der Bearbeitung des Bausteins das HMI das SPS-Programm unterbricht und die HMI-Variable ändert, dann wird die Änderung nach Fortsetzung des SPS-Programms überschrieben und geht unerkannt verloren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mir fällt kein Fall ein, indem wir eine Variable im gleichen Zyklus mehrfach beschreiben.
Oft werden Bits in Status-BYTES (oder WORD oder DWORD, "Bitstring") kopiert. Oft wird da zunächst die ganze Bitstring-Variable auf 0 initialisiert und dann die einzelnen Bits hineinkopiert. Wenn man den Vorgang nicht mit einer (temporären) Hilfsvariable macht und erst am Ende das Ergebnis in die HMI-Variable kopiert, sondern direkt mit der HMI-Variable macht, dann kann die HMI-Kommunikation zwischen Initialisierung und Endergebnis die Variable lesen und am HMI wird (zeitweise) ein falscher Wert angezeigt.
 
Oft ist auch ein Problem, dass HMI-Variablen an Bausteine an IN_OUT per Value übergeben werden
Wenn eine HMI-Variable per Referenz übergeben wird (IN oder IN_OUT), dann hat man auch ein Problem, wenn der Wert im Baustein mehrmals gelesen wird, z.B. erst auf Grenzwerte prüfen und danach die Variable nochmal lesen. Dann könnte die HMI-Kommunikation nach der Prüfung einen (evtl. unzulässigen) Wert in die Variable schreiben und das SPS-Programm verarbeitet diesen Wert ungeprüft. Oder bei verschiedenen Verarbeitungen werden verschiedene Werte verarbeitet. Merke: Eingangswerte im Baustein nur ein einziges Mal lesen und bei Bedarf an mehrfacher Verwendung auf interne Variablen umkopieren, quasi ein Prozessabbild (Schnappschuss) der Variable erstellen.
 
Mit "nicht erkannt und falsch dargestellt" meinte ich, dass ich im DB eine Variable beobachte und diese sich ändert, während im HMI unter einer Dynamisierung sich nichts verändert (z.B wird mit einer Bool die Farbe geändert).
Bei E/A-Feldern taucht das Warndreieck im Element auf und das Element selbst ist ausgegraut (gleiche Ansicht wie bei Komm.verlust).
Bei anderen Elementen wird die Dynamisierung einfach nicht ausgeführt.
Mit dem Zykluskontrollpunktproblem hat Dein Problem vermutlich nichts zu tun...

Irgend ein Kommunikationsproblem mit optimierten DBs sicherlich...

Immer wenn Du irgendwo (SPS oder HMI) etwas änderst, musst Du die SPS Änderungsübersetzen und Änderungsladen sowie das HMI Gesamtübersetzen und Laden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit dem Zykluskontrollpunktproblem hat Dein Problem vermutlich nichts zu tun...
Ja, das scheint tatsächlich eher ein Bug zu sein. Wobei Siemens nur was bei Verwendung von "Anwenderdatentypen" schreibt. siehe Beitrag #5

Aber interessant, wie wenig heutzutage das Zykluskontrollpunkt-Problem auf dem Schirm ist, genauso wie die speziellen Eigenschaften von Datentypen (z.B. REAL). TIA macht es anscheinend zu leicht, unbedarft irgendwas zusammenzuklicken und mit nur einem Testfall zu testen und wenn der ohne Fehlermeldung gut geht, dann raus damit zum Kunde...
 
Ja, das scheint tatsächlich eher ein Bug zu sein. Wobei Siemens nur was bei Verwendung von "Anwenderdatentypen" schreibt. siehe Beitrag #5

Aber interessant, wie wenig heutzutage das Zykluskontrollpunkt-Problem auf dem Schirm ist, genauso wie die speziellen Eigenschaften von Datentypen (z.B. REAL). TIA macht es anscheinend zu leicht, unbedarft irgendwas zusammenzuklicken und mit nur einem Testfall zu testen und wenn der ohne Fehlermeldung gut geht, dann raus damit zum Kunde...
In meinem Fall bin ich frisch auf den Markt gekommen. Uns wurde während des Technikers auch (bis auf AWL) nichts älteres bzw weit verbreitetes gelehrt. Wir hatten direkt mit V17/V18 und 1500er SPS gearbeitet. Ich merke selbst, wie viel Wissen mir in Sachen Programmierung fehlt. Aber diese Themen aufzuarbeiten ist nicht leicht, wenn man über die Existenz einer Information nichts weiß :(

Für das Projekt wird derzeit folgende Software verwendet:
- TIA Portal v20.00.00.00_95.01.00.01
- WinCC Unified PC v20.00.00.00.00_00.00.90.11
- PLCSIM v20.00.00.00_20.05.00.00
 
Zurück
Oben