# Inat OPC-Verbindung mit S5 CP1430TCP



## repök (21 Februar 2011)

Hallo erstmal,
die Verbindungen steht soweit. Nach mehreren S5 und S7 hin. Alles kein Problem. 
Nur bei einer Verbindung komt es vor, dass sich Varbiablen nicht mehr aktualisieren. Und dann nicht nur einzelne, sondern es werden dann ganze Bereiche nicht mehr aktualisiert. Beispiel: ein MW wird richtig geschrieben, durch die Änderung dieses MW müssten sich dann auch daten in einem DB ändern. Was in der SPS auch geschieht, aber der opc-server aktualisiert die Variblen nicht. Selbst der Test-Client von Rockwell bringt dann die falschen Werte.  
Schaut man dann mit Step5 in den DB, sind die Daten richtig. Step5 greift auf den CP, und dann über die "Affenschaukel" auf die AS511-Schnittstelle des AG zu.  
Es wurde schon alles getauscht, vom PC des Servers über NW-Kabel bis zum AG. Das verhalten bleibt gleich. Einzig der Switch ist noch der gleiche. Kann da irgendwas schieflaufen? Wobei alle anderen verbindungen fuktionieren ja. 
Nach jedem neustart des OPC-Servers  läuft die Verbindung mal 14 Tage dann wieder mal nur ein paar Stunden.
Die Verbindung hat jahrelang funtioniert. Nun ist essig. Wieso?

Der OPC-Client ist WinCC5.1. Er wird demnächst auf WinCC7 umgestellt. Wenn dan das Problem mit der Verbindung gelöst ist.


----------



## Dr. OPC (22 Februar 2011)

Das hört sich schräg an. 

Eine Sache würde ich noch überprüfen: wenn du mit einen anderen OPC Client (von einem anderen PC oder deinem Laptop) auf den Inat-Server zugreifst, bekommst du dann diese "fehlende" Datenänderung mit? (ist der Rockwell-Client auf der selben Maschine wie das WinCC5?)

Ziel: herausbekommen ob Inat-OPC-Server die Datenänderung noch mitbekommen hat, oder ob nur der WinCC-Client sie nicht mitbekommen hat.

Eine weitere Frage, welches Betriebssystem wird verwendet für den WinCC-OPC-Client, WinNT oder XP? Hintergrund: bei WinNT4 gab es mal ein Problem das Callbacks "verschluckt" wurden Stichwort: COM+Rollup Package.


----------



## repök (22 Februar 2011)

Nein, der Rockwell-Client und S5 ist an einem PC (bzw. PG), WinCC laüft auf einem anderen. Beide greifen über den selben switch auf den OPC-Server und die S5 zu.
Alles sehr suspekt.


----------



## Dr. OPC (23 Februar 2011)

Ok, damit scheit es also so zu sein das schon der Inat-OPC-Server die Datenänderung in der S5 nicht mitbekommt (und dementsprechend auch weder den Rockwell-Client noch den WinCC5-Client informieren kann)

Daraus ergibt sich das du beim Inat-Server und der Kommunikationsverbindung zur S5 weiter nach dem Problem suchen solltest. Ein Upgrade auf ein neueres WinCC bringt dir dann vermutlich nichts.

Die Kommunikation zwischen Inat-OPC-Server und der S5 läuft vermutlich über Send/Receive. Bei diesen Blockdiensten ist grundsätzlich auch möglich das du Daten verlieren kannst. Beispiel: die S5 ruft sehr schnell hintereinander mehrere Send-Bausteine auf. Der OPC-Server, als Partner dieser Kommunikationsverbindung, stellt intern einen "Receive-Block" bereit, der dann schnell hintereinander "überschrieben" wird. Wenn der OPC-Server sich seinen Receive-Puffer aber nur alle 2000ms "anschaut" könnte es sein dass der Puffer längst überschrieben wurde und der Wert längst wieder futsch ist, besonders dann wenn mit variabler Länge gesendet wird.

Wenn die Kommunikation zwischen OPC-Server und S5 mit Fetch/Write realisiert wird sollte es derartige Probleme eigentlich nicht geben.


----------



## repök (23 Februar 2011)

Also die S5 arbeitet mit Fetch/Write. Könnte sich das Problem beheben wenn man die Verbindung auf TCP (also ohne ISO) umstellt? Den Switch möchte ich als Fehlerquelle mal auschliessen, da ich gestern den Port gewechselt habe und das Problem "mitgewandert" ist.


----------



## Dr. OPC (23 Februar 2011)

Also den Switch würde ich auch ausschließen, ebenso die Transportschicht, ob TCP oder ISO dürfte keinen Unterschied machen.

Wenn Du sagst die S5 macht Fetch/Write dann bedeutet das der OPC Server macht (aktiv) Fetch/Write hin zur S5, oder wie? Das solltest du genau prüfen, denn wenn die S5 (aktiv) "Write" in Richtung OPC Server macht, dann könnte es ein Problem mit Datenüberschreibern geben. Umgekehrt, wenn der OPC-Server aktiv die Daten holt "Fetch" sollte es keine Probleme geben.

Hast du mal probeweise einen anderen OPC Server versucht, z.B. SimaticNET?


----------



## repök (23 Februar 2011)

Der OPC-Server baut die Verbindung aktiv auf, im CP steht alles auf [P] also passiv. 
Was ich gerade noch festgestellt habe:
Es werden ca. 40 Real Werte als Block geholt. Diese waren ausgegraut (also inaktiv). Dann betätige ich eine Taste in WinCC (es wird ein MW in die Steuerung geschrieben) und die Items werden wieder aktiv geschaltet. Obwohl diese Werte (allesamt in der Oberfläche mit der Taste) eigentlich ständig aktualisiert werden müssten, da es sich um Istwert anzeigen handelt.

Einen anderen OPC-Server habe ich noch nicht probiert,da ich alle Variabeln in WinCC "umstricken"  müsste.


----------



## Dr. OPC (23 Februar 2011)

> Diese waren ausgegraut (also inaktiv). Dann betätige ich eine Taste in WinCC (es wird ein MW in die Steuerung geschrieben) und die Items werden wieder aktiv geschaltet. Obwohl diese Werte (allesamt in der Oberfläche mit der Taste) eigentlich ständig aktualisiert werden müssten, da es sich um Istwert anzeigen handelt.


Wenn sie in der Oberfläche verwendet werden und trotzdem "grau" sind dann bedeutet das: es wurden seit Verbindungsaufbau noch keine Werte geliefert. Anscheinend kommen die erst nachdem der Merker geschrieben wird. Ich vermute das dann die S5 erst die Daten zum OPC Server sendet. Auch wen die Verbindungseite der S5 "passiv" ist, bedeutet das noch nicht das die nicht selber (nachdem die Verbindung aufgebaut ist) die initiative ergreift und selber "Write" in Richtung OPC Server aufruft.

Unabhängig vom "grau" oder "nicht grau" in WinCC erklärt es aber nicht warum der Rockwell-Client auch keine Wereteänderung bekommt.


----------



## repök (23 Februar 2011)

Diese Werte wurden vom OPC-Server als Inaktiv gekennzeichnet (also Grau), was ja eigentlich nicht seien kann, da der Rockwell-Client ja auch eine anfrage schicken müsste. 
Warum die Werte dann auf Aktiv wechseln sobald da ein Bit in die Steuerung geschrieben wird, das würde mich jetzt mal interessieren.


----------



## Dr. OPC (23 Februar 2011)

> Warum die Werte dann auf Aktiv wechseln sobald da ein Bit in die Steuerung geschrieben wird, das würde mich jetzt mal interessieren


Mich auch ! Aber es bestätigt meine anfängliche Vermutung dass das Problem irgendwo zwischen S5 und OPC Server besteht, die Verbindung fällt anscheined runter.

Ich vermute das es eine Verbindung ist, die erst bei "Bedarf" aufgebaut wird. Und das passiert erst wenn jemand sie "benutzt" also z.B. einen Wert schreibt. Dann bleibt sie aufgebaut (z.B. 15 Sekunden lang) und wird dann wieder abgebaut wenn sie nicht verwendet wird, es sei denn es wird permanent kommuniziert.

Das würde auch zu deinem Fehlerbild passen das es machmal 14Tage funktioniert und machmal nur wenige Stunden. Je nach dem wann eine Pause in der Kommunikation entsteht und ob danach wieder mit einem initialen "write" nach einer längeren Pause die Verbindung neu aufgebaut wird oder eben nicht und alles "grau" wird weil die Verbindung zur S5 abgebaut wurde.

Bei WinCC als Client hast du noch das Problem das die Werte beim OPC Server nicht permanent angefragt werden (sondern nur wenn das entsprechende WinCC Bild in dem sie angezeigt werden auch im Vordergrund ist), und der OPC Server somit keine Veranlassung hat zyklisch "fetch" zu rufen. Auch der Rockwell-Client hat nichts davon wenn er nur Werte "lesen" will und der "fetch" auf eine abgebaute Verbindung geht halt nicht (er müsste auch erstmal schreiben).

Kannst Du in der S5 irgendein Byte benutzen um alle paar Sekunden mal draufschreiben nur um die Verbindung aufrecht zu erhalten? Beim SimaticNET Server konnte man in Netpro einstellen ob eine Verbindung "bei Bedarf" oder "permanent" aufrecht erhalten werden soll, ob das beim Inat geht weiss ich aber nicht.


----------



## repök (23 Februar 2011)

Das wäre jetzt interessant, weil da hängen noch 5 weitere S5 und 4 S7 dran. Bei allen anderen funktioniert die Kommuniktion einwandfrei. nur bei dieser einen verbindung halt nicht. ich wüsste nicht das die anderen spsn ständig schreiben würden. aber ich werde das mal abklopfen.

schönen dank schonmal für deine mühe!


----------



## Dr. OPC (4 März 2011)

> ich wüsste nicht das die anderen spsn ständig schreiben würden.


das muss ja auch nicht zwingend so sein. Vielleicht sind deren Variablen permanent angezeigt und dusch das dauernde Fetch bleibt die Verbindung oben, oder bei denen ist die Verbindung anders konfiguriert.

Bei den S7 vermute ich das ohnehin kein Fetch/Write gemacht wird sondern S7-Protokoll Put/Get. 

Du solltest die Verbindungskonfiguration der S5en mal vergleichen (nicht nur in der S5 sonder auch auf der Inat-OPC Seite), vielleicht gibt es da Unterschiede. Ansonsten mit dem Rockwell-Client mal versuchen ob du Werte bekommst wenn du was geschrieben hast, und wie sich das in Vergleich mit einer anderen S5 verhält.


----------



## repök (6 März 2011)

*Hat sich gelöst!*

Aus einem script wurden variablen aus einer s7  und einer s5 getauscht. so eine art kommunikation. dies geschah jede sekunde. dadurch das wincc die vars immer aktiv und inaktiv schaltete, hat sich der opc-server wohl zu sehr mit diesen vars beschäftigt. nun habe ich eine dierekte verbindung zwischen den steuerungen aufgebaut, und die sache läuft wieder rund. 
wieso inat mir das nicht früher sagen konnte, weiss ich nicht. denn die haben die protokolle vom  opc-server bekommen.  und da steht deutlich drin was wann akitv und inaktiv geschaltet wird. vielen dank an den "kompetenten" service von inat. 
@dr.opc:dank dir nochmal. das hat mir schon sehr weiter geholfen.


----------

