[ S7-200 PC Access ] Verhalten bei Verbindungsabbruch

caret

Level-1
Beiträge
82
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich möchte mit Hilfe des S7-200 PC Access OPC Servers mehrere SPSen überwachen. Dazu habe ich die entsprechende Anzahl Zielsysteme sowie die zu beobachtenden Prozessvariablen im Configurator angelegt. Wenn ich nun aus jedem Zielsystem eine Prozessvariable (z.B. Systemzeit) in den mitgelieferten OPC Test Client ziehe und den Client starte kann ich Prozesswerte auch wunderbar beobachten (sprich: Uhren laufen). So weit so gut. Mein Problem ist nur: Sobald auch nur eine einzige Verbindung ausfällt (z.B. ausschalten einer SPS) bricht die Komunikation zu den anderen SPSen ebenfalls zusammen, d.h. im Test-Client werden gar keine Prozesswerte mehr aktualisiert (d.h. alle Uhren bleiben stehen). Insbesondere zeigt der Test-Client sogar noch für alle Prozessvariable (sprich auch alle Verbindungen) im Feld Qualität "gut" an, gerade so, als ob alles o.k. wäre. Woran liegt das? Gibt es da eine Lösung? Wenn nicht: Gibt es einen OPC Server der nicht komplett dicht macht sobald auch nur eine Verbindung weg ist?
In meiner Anwendung mit dem JEasyOPC Client kann ich übrigends das gleiche Verhalten beobachten, d.h. ich gehe davon aus, dass es ein OPC Server Problem ist und nicht eines des Clients.
 
Das hört sich sehr nach einem Problem des Protokolls unterhalb des OPC Servers an. Der Kommunikationstreiber verklemmt sich und nichts geht mehr. Ich habe bisher nur eine 200ter dran gehabt und das ging. Könnte mir vorstellen das wenn von mehreren einer ausfällt der Treiber versucht den "abtrünnigen" wiederzufinden und dabei lange Zeit in Verbindungstimeouts verbringt und somit die anderen Verbindungen nicht mehr (oder nur sehr selten) dran kommen.

Also versuche mal an den Verbindungsparametern herum zu drehen, und zwar tendenziell "runter", damit der Treiber schneller merkt das da was nicht stimmt.

Ansonsten würde ich mal probieren ob es beim Customer Support Infos gibt, eventuell eine neuere Version, oder so.

Von 300/400 kenne ich diese Probleme nicht, ganz im Gegenteil da gibt es sogar eine "schnelle Rückmeldung" bei Verbindungsfehlern und die anderen Teilnehmer werden (fast) überhaupt nicht beeinträchtigt. Dies ist übrigens ein Qualitätsmerkmal und sollte immer geprüft werden wenn man sich für einen OPC-Server Hersteller entscheidet.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das hört sich sehr nach einem Problem des Protokolls unterhalb des OPC Servers an. Der Kommunikationstreiber verklemmt sich und nichts geht mehr. Ich habe bisher nur eine 200ter dran gehabt und das ging. Könnte mir vorstellen das wenn von mehreren einer ausfällt der Treiber versucht den "abtrünnigen" wiederzufinden und dabei lange Zeit in Verbindungstimeouts verbringt und somit die anderen Verbindungen nicht mehr (oder nur sehr selten) dran kommen.
Würde sich mit der Beobachtung decken, dass der Server erst wieder anspringt wenn die SPS wieder da ist. Gerade so als wäre der Timeout auf unendlich.
Aber selbst wenn das ein Timeoutproblem ist: Ich hätte gedacht, dass die Verbindungen zu den Zielsystemen jeweils in einem eigenen Thread laufen. Macht einer die Grätsche kümmert das die anderen herzlich wenig.

Also versuche mal an den Verbindungsparametern herum zu drehen, und zwar tendenziell "runter", damit der Treiber schneller merkt das da was nicht stimmt.
Wie gesagt, für diesen Test verwende ich den im S7-200 PC Access integrierten Client. Da gibt es außer eine Zykluszeit für das Polling nichts einzustellen. Zumindest finde ich nichts. In meiner Anwendung benutze ich JEasyOPC, aber auch da habe ich keine Verbindungsparameter in dieser Richtung gefunden.

Ansonsten würde ich mal probieren ob es beim Customer Support Infos gibt, eventuell eine neuere Version, oder so.
Kundensupport ist immer lustig: "Hm ... ja ... kann sein. Ist uns bisher nicht aufgefallen. Wird ja nicht mehr sooft eingesetzt das Produkt. Wird ja auch von einer anderen Firma in Amerika entwickelt. Mal da eine Anfrage stellen. Dauert aber. Wollen sie nicht evtl. was anderes kaufen ..." Klingt für mich nich dannach, als ob sich von der Seite was tun würde.

Von 300/400 kenne ich diese Probleme nicht, ganz im Gegenteil da gibt es sogar eine "schnelle Rückmeldung" bei Verbindungsfehlern und die anderen Teilnehmer werden (fast) überhaupt nicht beeinträchtigt. Dies ist übrigens ein Qualitätsmerkmal und sollte immer geprüft werden wenn man sich für einen OPC-Server Hersteller entscheidet.
Ja, der Tipp ist sicherlich wertvoll. Obwohl ich das eher als grundliegendes Funktionsmerkmal und nicht eine Frage der Qualität sehen würde. <ironie>Oder gehen bei meinem Internet Service Provider gleich die Lichter aus, wenn ich meinen Rechner vom Netz nehme. </ironie> Ist halt mein erstes OPC Server Projekt, da hab ich solche Probleme eigentlich nicht erwartet, vor allem nicht von einem so namenhaften Hersteller wie Siemens.
 
Da kann ich dir nur uneingeschränkt zustimmen, von einen namhaften Hersteller erwartet man das die a) sowas in ihrem Test merken und b) natürlich eine Architektur implementieren, die das kann und sich nicht verklemmt.

Leider (ohne das oben gesagte zu verharmlosen) ist das bei anderen Herstellern noch viel schlimmer. Ich sage es mal so, einen OPC Server kann heute jeder programmieren (greade wenn er ein Toolkit nimmt), einen anständigen Kommunikationstreiber fast niemand. Da hört man dann oft OPC ist total der Mist, aber meist ist einfach nur der Kommunikationstreiber schlecht implementiert. Auch Aussagen wie "meiner ist der schnellste" habe ich schon oft gehört, ich ziehe dann erstmal eine SPS ab und plötlich ist es "der langsamste". Man muss halt wissen was man tut.

Auch wenn dir das akut nicht hilft, ich denke dieses Problem habe andere auch beobachtet, somit gibt es vielleicht eine Behebung. Der Customer Support ist nicht so schlecht wie immer gesagt wird...

Beim "feintunen" der Parameter dachte ich mehr an Einstellungen des Protokolls (nicht des OPC Servers). Soweit ich mich erinnere gibt es da verschiedene Wizzards und so etwas wie einen INIT-Baustein, der Server hat noch eine Konfigurationsdatei glaube ich. Aber du hast recht, so viele Einstellungen wie bei "NetPro" gibt es nicht.
 
Zurück
Oben