TIA Verzögerte/unstabile HMI-Verbindung mit absoluter Adressierung zur CPU

daloeff

Level-1
Beiträge
59
Reaktionspunkte
4
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,


wir haben ein Problem mit der HMI - CPU Verbindung. Folgendes im Vorhinein:
HMI: Comfort Panel 1500, CPU Anlage: 1517F-3 PN/DP, CPU Werkzeug: 1512SP1-PN. Die HMI ist mit der Anlagen CPU normal verbunden (in einem Projekt). Die Werkzeug CPU ist ein separates Projekt. Dadurch greift die HMI nur ABSOLUT auf die Werkzeug CPU zu. Es gibt nun mehrere Bilder für das Werkzeug, dass sich individuell, je nachdem wie die DBs auf der Werkzeug CPU konfiguriert sind zusammen setzt. Wir benützen dieses Verfahren schon längers und hatten nie Probleme. Jetzt haben wir eine Ansteuerung (Bildbaustein) für kleinere Motoren und eine neue Heizungsseite hinzugefügt. Jedoch haben wir hier nun das sporadische Problem, dass Tasten die mit "setze Bit wenn Taste gedrückt" belegt sind die Variable zwar im DB auf 1 setzen, jedoch nicht mehr auf 0 setzen, sprich die Taste bleibt hängen. Das selbe gibt es mit Eingabefelder, gibt man einen Wert ein bleibt der vorherige Wert stehen. Erst beim wiederholten mal wird der Wert übernommen. Bei einer anderen Seite, in der die gleichen Funktionen ebenfalls genutzt werden, funktioniert alles einwandfrei. Die aktualisierungsrate der Tags war am Anfang auf 100ms gesetzt. Ich habe versucht diese auf 1sek zu erhöhen, jedoch ohne Erfolg. Ich habe es ebenfalls im Simulator versucht, hier besteht das selbe Problem.
Benutzen wir evt. zu viele Variablen? Gibt es eine Begrenzung der absoluten Variablen pro Seite?
Wir verwenden den selben Bildbaustein (mit mehr Variablen, da mehr positionen) in einem anderen Projekt. Hier wird jedoch nicht absolut adressiert, da Panel und CPU im selben Projekt liegen. Läuft einwandfrei. Deshalb die Frage, ob es für die absoluten Variablen eine Begrenzung gibt?
Mein Verdacht geht darauf, dass im BB einfach zu viele Variablen für eine absolute Adressierung verwendet werden, jedoch habe ich von einer obergrenzen noch nchts gefunden.
Panel hat das neueste Firmware! Zykluszeit der Werkzeug CPU liegt bei ca 11ms

Anlagen screenshots:
Installierte Versionen
Projektierte Verbindungen
HMI Variablen Teil 1 (Diese Variablen sind mit dem Bildbaustein verbunden)
HMI Variablen Teil 2 (Diese Variablen sind mit dem Bildbaustein verbunden)

Danke!
 

Anhänge

  • 2016-04-22 14_35_52-Siemens  -  C__Users_s.bischofer_Documents_Automatisierung_Grammer_1537_Vacl.jpg
    2016-04-22 14_35_52-Siemens - C__Users_s.bischofer_Documents_Automatisierung_Grammer_1537_Vacl.jpg
    46 KB · Aufrufe: 59
  • 2016-04-22 14_49_16-SIMATIC WinCC Runtime Advanced.jpg
    2016-04-22 14_49_16-SIMATIC WinCC Runtime Advanced.jpg
    49,5 KB · Aufrufe: 54
  • 2016-04-22 15_37_05-C__Users_s.bischofer_Documents_Automatisierung_VacLam_Tools_Grammer_1538_BMW.png
    2016-04-22 15_37_05-C__Users_s.bischofer_Documents_Automatisierung_VacLam_Tools_Grammer_1538_BMW.png
    7,9 KB · Aufrufe: 45
  • 2016-04-22 15_39_48-Siemens  -  C__Users_s.bischofer_Documents_Automatisierung_Grammer_1537_Vacl.jpg
    2016-04-22 15_39_48-Siemens - C__Users_s.bischofer_Documents_Automatisierung_Grammer_1537_Vacl.jpg
    121,4 KB · Aufrufe: 40
  • 2016-04-22 15_40_04-Siemens  -  C__Users_s.bischofer_Documents_Automatisierung_Grammer_1537_Vacl.jpg
    2016-04-22 15_40_04-Siemens - C__Users_s.bischofer_Documents_Automatisierung_Grammer_1537_Vacl.jpg
    116,7 KB · Aufrufe: 53
Zuviel Werbung?
-> Hier kostenlos registrieren
Jip, die Variablen sind automatisch auf Zyklisch im Betrieb gestellt bei Absoluter Adressierung. Hier gibt's die Option "auf Anforderung" nicht. Jedoch hab ich herausgefunden, dass es etwas im Programm der Werkzeug CPU sein muss. Wenn ich den Motor FB deaktiviere bleibt die Variable (Jogging_pos) im DB nicht mehr "hängen". Jedoch wird diese Variable im Motor FB als UDT in INOUT übergeben und im FB nur 1x gelesen und einmal mit einem -(R) falls der Handbetrieb deaktiviert (doch das ist nicht der Fall) wird zurückgesetzt. Ich kann mir hier beim besten willen nicht zusammen reimen, wie das einen Einfluss aufs Zusammenspiel HMI - CPU haben kann. Es könnte schon sein, dass es ein sync Problem gibt, verstehe es aber nicht, da die Variable nicht beschrieben sondern nur gelesen wird.
 
Wir benützen dieses Verfahren schon längers und hatten nie Probleme.
mit S7-1500? Oder war das "nie Probleme" mit S7-300?

Dein Problem klingt so, als ob der FB am Ende auf die per IN_OUT übergebene Struktur (UDT) zurückschreibt - macht er vielleicht eine lokale Kopie? Dann würde sich genau Dein Problembild ergeben, wenn die HMI dann in die SPS schreibt, während die FB-Instanz gerade läuft. Bei S7-300 schrieb die HMI normalerweise nur im Zykluskontrollpunkt ins Programm, bei S7-1500 unterbricht und schreibt die HMI vermutlich jederzeit.

Wird bei der S7-1500 der UDT an FB-IN_OUT per Pointer übergeben oder per Value?

Harald
 
Hallo,

mit "nie Probleme" meinte ich, dass wir diese Variante mit eigenständigem Programm auf der Werkzeug CPU schon längers nutzen und so einfache Zylinderansteuerungen realisieren. D.h. im HMI gibt es einen Bildbaustein für einen Zylinder. Dieser greift absolut auf DBxDBXx.x zu. Z.B. zeitliche Parameter wann der Zylinder in AS und in GS fahren soll werden ebenalls so übergeben. Die Abarbeitung läuft dann auf der Werkzeug CPU eigenständig mit den Parametern vom HMI ab. (Ist eigentlich einfach aber etwas schwierig zu erklären)

Ich hab mal ein paar screenshots von der Motoransteuerung gemacht um es zu verdeutlichen wie ich es aufgebaut habe:

1.Bild: DB an dem der BB der HMI angeschlossen ist. Hierauf wird absolut zugegriffen. Die Variabel Cmd_JogPlus/Cmd_JogMinus werden im HMI gesetzt wenn Taste gedrückt wird.

2.Bild: Der Motor FB hier wird die Struktur als INOUT unter HMI übergeben.

3.Bild: Cmd_JogPlus/Cmd_JogMinus werden gelesen und damit der command in gang gesetzt.

4.Bild: Hier wird Cmd_JogPlus/Cmd_JogMinus resettet falls die Manual Steuerung deaktiviert wird.

Ich finde den den Punkt mit schreiben beim "Zykluskontrollpunkt" sehr interessant. Da die HMI nur eine Verbindung (2 verschiedene Projekte) auf eine IP Adresse hat und fixe absolute Adressen hat, gibt es hier wahrscheinlich keinen Zykluskontrollpunkt?!
 

Anhänge

  • 2016-04-25 11_38_06-C__Users_s.bischofer_Documents_Automatisierung_VacLam_Tools_Grammer_1538_BMW.jpg
    2016-04-25 11_38_06-C__Users_s.bischofer_Documents_Automatisierung_VacLam_Tools_Grammer_1538_BMW.jpg
    93,6 KB · Aufrufe: 23
  • 2016-04-25 11_38_23-C__Users_s.bischofer_Documents_Automatisierung_VacLam_Tools_Grammer_1538_BMW.jpg
    2016-04-25 11_38_23-C__Users_s.bischofer_Documents_Automatisierung_VacLam_Tools_Grammer_1538_BMW.jpg
    49,7 KB · Aufrufe: 22
  • 2016-04-25 11_38_49-C__Users_s.bischofer_Documents_Automatisierung_VacLam_Tools_Grammer_1538_BMW.jpg
    2016-04-25 11_38_49-C__Users_s.bischofer_Documents_Automatisierung_VacLam_Tools_Grammer_1538_BMW.jpg
    65,9 KB · Aufrufe: 22
  • 2016-04-25 11_39_09-C__Users_s.bischofer_Documents_Automatisierung_VacLam_Tools_Grammer_1538_BMW.jpg
    2016-04-25 11_39_09-C__Users_s.bischofer_Documents_Automatisierung_VacLam_Tools_Grammer_1538_BMW.jpg
    72,6 KB · Aufrufe: 19
Zuviel Werbung?
-> Hier kostenlos registrieren
#En_Man ist TEMP - bekommt es immer einen korrekten Wert zugewiesen?
Gibt es in dem FB (oder überhaupt im Programm) indirekte Adressierung, welche fehlerhaft sein könnte?

Der Zykluskontrollpunkt hat nichts mit IP-Adressen und Zieladressen im Datenspeicher der SPS zu tun, sondern mit dem Betriebssystem der SPS, wann es HMI-Schreib-/Lesezugriffe ausführt.
So wie es ein Prozessabbild der Eingänge und Ausgänge gibt, gab es in der S7-300 auch ein "Prozessabbild" der S7-Kommunikation. Schreib-/Lesezugriffe von externen Kommunikationspartnern (HMI, PG, andere SPS) fanden nur im Zykluskontrollpunkt außerhalb der Laufzeit des OB1 statt und Werte von S7-Kommunikations-Variablen waren die ganze OB1-Laufzeit über gleich.
Jetzt in der S7-1500 kann die Kommunikation aus Performancegründen jederzeit den OB1 unterbrechen und Werte in DB ändern und den OB1 fortsetzen. Die Werte der Kommunikationsvariablen können sich also im OB1 ändern, wenn man zweimal zugreift kann das verschiedene Ergebnisse liefern - deshalb dürfen Kommunikationsvariablen eigentlich nur genau 1 mal im Zyklus gelesen werden, also am besten erstmal umkopieren und dann nur mit den Kopien arbeiten - so hat man sich seinen eigenen Zykluskontrollpunkt und sein eigenes Prozessabbild der Kommunikation geschaffen.

Ein zweiter Fallstrick ist die Anbindung von einfachen Variablen an IN_OUT, weil diese am Ende eines FC/FB wieder von der Bausteinschnittstelle in die angeschlossenen Variablen zurückkopiert werden, ohne Rücksicht, ob vielleicht während der Bausteinlaufzeit ein Schreibzugriff auf die angeschlossene Variable stattgefunden hat. Bei IN_OUT-Übergabe von Strukturen oder UDT dürfte das aber nicht passieren, weil diese als Pointer übergeben werden und nicht zurückkopiert werden (sollten). Bei der S7-1500 kenne ich mich aber nicht aus (vielleicht gibt es da auch noch kreative Firmware-Bugs?)

Harald
 
CPU Werkzeug: 1512SP1-PN.

Jedoch haben wir hier nun das sporadische Problem, dass Tasten die mit "setze Bit wenn Taste gedrückt" belegt sind die Variable zwar im DB auf 1 setzen, jedoch nicht mehr auf 0 setzen, sprich die Taste bleibt hängen. Das selbe gibt es mit Eingabefelder, gibt man einen Wert ein bleibt der vorherige Wert stehen.

Erst beim wiederholten mal wird der Wert übernommen.
Jedoch wird diese Variable im Motor FB als UDT in INOUT übergeben
Klingt für mich auch nach einem Problem mit dem Timing der HMI-Zugriffe (fehlender Kontrollpunkt auf der 1500).

Dein Problem klingt so, als ob der FB am Ende auf die per IN_OUT übergebene Struktur (UDT) zurückschreibt - macht er vielleicht eine lokale Kopie?
Wird bei der S7-1500 der UDT an FB-IN_OUT per Pointer übergeben oder per Value?
@Harald:
Bei der 1500 hängt das davon ab was dem INOUT übergeben wird.
Wird einem "optimierten FB" am INOUT ein UDT übergeben der sich in einem "optimierten" DB befindet, dann erfolgt der Zugriff "per Reference".
Wird einem "optimierten FB" am INOUT ein UDT der sich im "nicht optimierten" Bereich befindet, dann wird dem FB eine Kopie übergeben und der Zugriff erfolgt "per Value".
Und umgekehrt, sobald es einen Übergang gibt hat man "by Value".

Als FB-Ersteller weiß man also nie so genau wie man die Werte übergeben bekommt... ;)
Für einen beiden Fälle steht's hier, den umgekehrten Fall hab ich noch nirgendst beschrieben gesehen...
https://support.industry.siemens.com/cs/de/de/view/109011420/71500818699


Da daloeff mit absoluten Adressen arbeitet wird also auf jeden Fall beim FB-Aufruf eine lokale Kopie des UDT erstellt.
Dann kann passieren was Harald oben angesprochen hat...
Jedoch wird diese Variable im Motor FB als UDT in INOUT übergeben und im FB nur 1x gelesen und einmal mit einem -(R) falls der Handbetrieb deaktiviert (doch das ist nicht der Fall) wird zurückgesetzt. Ich kann mir hier beim besten willen nicht zusammen reimen, wie das einen Einfluss aufs Zusammenspiel HMI - CPU haben kann.
Folgendes kann passieren:
  1. BitX hat in deinem UDT den Zustand 0.
  2. Beim FB-Aufruf wird eine lokale Kopie des UDTs erstellt mit welcher der FB arbeitet. BitX ist darin 0
  3. Mitten in der Abarbeitung des FB setzt die HMI das BitX auf 1. Wohlgemerkt nur im DB und nicht in der lokalen Kopie des DB. Wann und wo im Programmablauf das passiert ist Zufall.
  4. Der FB arbeitet aber mit der lokalen Kopie des BitX welches 0 ist.
  5. Am Ende des FB wird die lokale Kopie auf den UDT im Datenbaustein zurückkopiert.
  6. BitX welches im DB den Wert 1 hatte wird wieder mit 0 überschrieben und der FB hat die 1 nie gesehen.

Das nächste Problem habt ihr eventuell wenn ihr einen Wert von der HMI zweimal im Zyklus lest. Das kann unterschiedliche Werte bringen wenn die HMI ihn in der Zwischenzeit ändert.
Wenn ihr 1500 programmiert müsst ihr euch über dieses Thema ernsthafte Gedanken machen, sonst werdet ihr auf alle möglichen Schwierigkeiten stoßen.

Abgesehen davon würde ich eher ausschließen dass die Anzahl der Variablen, der absolute Zugriff oder sonstwas in der Art dein Problem auslöst. Sofern Siemens nicht wieder irgendwo wilde Bugs reingeschustert hat.
Wenn dir irgendwo ein Bit hängt, versuch mal die Zykluszeit der CPU zu verlängern. Dann würde man möglicherweise den Programm-Punkt an dem ein Schreib-Lesevorgang der HMI passiert verschieben und über den längeren Zyklus die Wahrscheinlichkeit verringern dass der Zugriff an einem für dich ungünstigen Zeitpunkt passiert. Das könntest du einfach versuchen um eventuell fest zu stellen ob es wirklich das oben beschriebene Problem ist.
 
Zuletzt bearbeitet:
Ok, danke! Habs kapiert auf was Ihr hinaus wollt. Habs jetzt nur mal schnell getestet und den UDT vor dem Baustein auf eine Statischen UDT kopiert und diesen an dem Baustein angehängt.

Und siehe da, jetzt funktionierts!

Normalerweise arbeiten wir nur mit optimierten Bausteinen, die nicht optimierten benutzen wir nur in den Werkzeugprogrammen, da diese eigenständige Projekte sind und nicht im Anlagenprojekt mit drin. Um darauf zuzugreifen verwenden wir die absolute Adressierung.

Hab mir gedacht, ich splitte den UDT auf in Cmd und HMI. Also die Befehle kommen in den Cmd und können nur gelesen werden, der Rest in den HMI für Anzeigewerte, Animationen usw.
Wär für mich jetzt die einfachste Lösung oder habt Ihr noch einen Tipp?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hab mir gedacht, ich splitte den UDT auf in Cmd und HMI. Also die Befehle kommen in den Cmd und können nur gelesen werden, der Rest in den HMI für Anzeigewerte, Animationen usw.
Wär für mich jetzt die einfachste Lösung oder habt Ihr noch einen Tipp?
Damit bisst du schon am richtigen Weg. Die strikte Trennung von Lese und Schreibzugriffen zwischen HMI und SPS, sowie dass nur einmalige Lesen/Schreiben, ist meiner Meinung nach der einzig vernünftige Weg.


Normalerweise arbeiten wir nur mit optimierten Bausteinen, die nicht optimierten benutzen wir nur in den Werkzeugprogrammen, da diese eigenständige Projekte sind und nicht im Anlagenprojekt mit drin. Um darauf zuzugreifen verwenden wir die absolute Adressierung.
Anmerken muss ich aber dass das Problem an sich nichts mit den "nicht optimierten" Datenbausteinen zu tun hat.
Der Wechsel von "Optimiert" auf "Standard" führt in deinem Fall (ich gehe davon aus dass dein FB als "optimiert" erstellt wurde) dazu, dass der INOUT-Zugriff des FB auf den UDT von perRef auf perVal wechselt.
Nicht strukturierten Datentypen (also normale WORDs, REALs, etc.) werden immer als perVal übergeben. Kann also ebenfalls zu dem Problem führen.
Im Umkehrschluss heißt der perRef Zugriff auf den UDT natürlich auch, dass wenn du den Wert am Anfang des FBs liest, dass dieser bei einem weiteren lesen schon von der HMI geändert worden sein kann.

Das gesagte gilt nicht nur für FB-INOUT sondern überall im SPS-Programm auch für jeden anderen Wert.
Alle Werte die mit der HMI zusammenhängen können sich mitten im Code ändern, dein Code muss immer damit klar kommen.

Für den Lesevorgang der HMI von Anzeigwerten aus der SPS gilt das selbe. Ein vorgehen ala...
Code:
L      0.0
T      #HMI_Anzeige_Messwert


---------------------------> Wenn die HMI hier liest, dann erscheint eine 0 am Display


U      #Messwertfehler
SPB    Ma01


L      Messwert
T      #HMI_Anzeige_Messwert  


Ma01 : Nop 0
Kann dazu führen dass der Anzeigewert am HMI flackert...


Einfach gesagt. Die HMI schreibt/liest wann sie will und oft wann es dir am wenigsten passt. Also Vorsicht. ;)
 
Zuletzt bearbeitet:
Danke an alle für die Beiträge, gut zu wissen wo das Problem liegt.
Dann fällts auch leichter ne Lösung zu finden! :sm24:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Und für welchen Anwendungszweck braucht man das? :)
Für den Programmierer gibt es (zumindest was mir bekannt ist) keinen Vorteil.
Der muss sich schließlich selber darum kümmern dass die Sychronisationspunkte zwischen HMI und SPS passen und das nirgenst Probleme entstehen.
Was im Endeffekt zusätzliche Arbeit ist und mögl. Probleme schafft wenn man wo nicht aufpasst. Probleme die dadurch entstehen sind oft sehr schwer zu diagnostizieren.

Machen tut man das weil...
  • Die HMI-Kommunikation schneller geht da die HMI nicht mehr warten muss bis er OB1-Zyklus der SPS vorbei is
  • Es sowas bei der 400er auch schon nicht gegeben hat und man das wahrscheinlich blind für die 1500 übernommen hat.

Den Performacevorteil bezahlt man aber damit dass ggf. auf der SPS mehr Datenpunkte und Zeit (z.B. zum Erstellen einer lokalen Kopie der Datenpunkte) gebraucht wird.
Ich persönlich hatte nix gegen die Lösung mit dem Zykluskontrollpunkt auf der 300. War deutlich bequemer.
 
Zuletzt bearbeitet:
Ein Anliegen hätte ich noch:
Wie geht man am besten vor, wenn ich z.B. einen Sollwert begrenzen will (0-100°C) und das auf der PLC Seite? Wenn ich es mit der LIMIT Funktion löse kann das oben genannte Problem auftreten. Auf der HMI Seite kann ich es auch nicht lösen, da die HMI UDT's nur mit konstanten begrenzt werden können (ich benötige jedoch Variable Grenzen).
Irgendwelche Vorschläge?

Danke!
 
Code:
IF SOLLWERT_VISU >= LIMIT_MAX THEN
    SOLLWERT_SPS := LIMIT_MAX;
ELSIF SOLLWERT_VISU <= LIMIT_MIN THEN
    SOLLWERT_SPS := LIMIT_MIN;
ELSE
    SOLLWERT_SPS := SOLLWERT_VISU;
END_IF;

Zum Bleistift.

Grüße

Marcel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Code:
IF SOLLWERT_VISU >= LIMIT_MAX THEN
[COLOR=#ff0000]------------------------------------------------------< HIER[/COLOR]
ELSIF SOLLWERT_VISU <= LIMIT_MIN THEN
Wenn wir ganz gemein nach Murphys gehen könnte dir die HMI hier noch einen Wert größer LIMIT_MAX unterjubeln... ;)
(Sofern der Code vom Compiler beim IF und ELSEIF die Var zweimal aus dem DB liest)
Hält die Sache aber spannend, wie nen Lottogewinn.

Eher sowas...
Code:
#SetPoint_Internal := LIMIT(MN:=0.0, IN:=#SetPoint, MX:=100.0);
#SetPoint:= #SetPoint_Internal;

//Ab hier dann irgenwas mit #SetPoint_Internal
Das zurückschreiben auf den Wert ermöglicht natürlich wieder dass eine HMI-Eingabe verloren geht...
 
Zuletzt bearbeitet:
Wie geht man am besten vor, wenn ich z.B. einen Sollwert begrenzen will (0-100°C) und das auf der PLC Seite? Wenn ich es mit der LIMIT Funktion löse kann das oben genannte Problem auftreten.
Das Problem hatten wir vor 2 Jahren schonmal diskutiert. Da habe ich auch eine Function gezeigt, mit der das Limitieren der HMI-Variable funktionieren sollte. Grundsatz:
Das PLC-Programm arbeitet mit einer Kopie der HMI-Variable, welche nur ein einziges mal gelesen wird.

Das PLC-Programm schreibt nur dann auf die HMI-Variable wenn es zur Korrektur nötig ist
Weiter unten hatte ich da auch noch die Idee geäußert, durch sperren der Interrupts eventuell den Zugriff der HMI-Kommunikation zu sperren. Anscheinend hat das wohl noch niemand ausprobiert.

Wäre auch mal interessant zu schauen, ob und was für eine Lösung Siemens empfiehlt?

Harald
 
Zurück
Oben