# Kommunikation hängt ...



## RobiHerb (3 November 2009)

Ich schreibe gerade mit libnodave und .NET/WPF in C# eine erste Testapplikation zur S7 Verbindung (MPI 2 S7/314, alles original Siemens). 

Natürlich ist die Applikation noch mit Fehlern und so kommt es vor, dass ich im Debugger gelegentlich den Prozess einfach beende. Danach habe ich beim Neustart der PC Applikation gelegentlich das Problem, dass die Kommunikation nicht mehr aufzubauen ist. Abhilfe: S7 ausschalten und Luft holen und wieder einschalten. Wo mache ich den Fehler, kann man beim StartUp des PC Programms irgendwie was resetten, muss man beim ShutDown des PC Programms notwendig was zumachen?


----------



## argv_user (3 November 2009)

RobiHerb schrieb:


> Ich schreibe gerade mit libnodave und .NET/WPF in C# eine erste Testapplikation zur S7 Verbindung (MPI 2 S7/314, alles original Siemens).
> 
> Natürlich ist die Applikation noch mit Fehlern und so kommt es vor, dass ich im Debugger gelegentlich den Prozess einfach beende. Danach habe ich beim Neustart der PC Applikation gelegentlich das Problem, dass die Kommunikation nicht mehr aufzubauen ist. Abhilfe: S7 ausschalten und Luft holen und wieder einschalten. Wo mache ich den Fehler, kann man beim StartUp des PC Programms irgendwie was resetten, muss man beim ShutDown des PC Programms notwendig was zumachen?



Die Verbindung sollte ordentlich abgebaut werden.

Das Problem liegt auf der S7-Seite: Einmal aufgebaute Verbindungen bleiben für eine gewisse Zeit belegt, selbst wenn der PC die TCP-Verbindung schließt. Das AG braucht etwas Zeit, bis es das mitbekommt. Rechne mal mit etwa einer Minute.


----------



## RobiHerb (3 November 2009)

*Nicht gelöst ...*



argv_user schrieb:


> Die Verbindung sollte ordentlich abgebaut werden.
> 
> Das Problem liegt auf der S7-Seite: Einmal aufgebaute Verbindungen bleiben für eine gewisse Zeit belegt, selbst wenn der PC die TCP-Verbindung schließt. Das AG braucht etwas Zeit, bis es das mitbekommt. Rechne mal mit etwa einer Minute.



Auch nach 30 Minuten hat die SPS keine Lust zu antworten, es ist übrigens ein MPI Adapter, über den die Kommunikation läuft.


----------



## Rainer Hönle (3 November 2009)

Liegt dies am Adapter oder an der SPS? Was passiert, wenn nur der Adapter aus- und wieder eingesteckt wird? Um was für einen Adapter handelt es sich? Was zeigen die LEDs?


----------



## pvbrowser (3 November 2009)

RobiHerb schrieb:


> Natürlich ist die Applikation noch mit Fehlern und so kommt es vor, dass ich im Debugger gelegentlich den Prozess einfach beende.



In diesem Falle wird die TCP Verbindung einfach abgewürgt.

Damit der Partner das mitbekommt, muss ein Lebenszeichen Telegramm vorhanden sein.

Versuche bitte mal in
openSocket.c von libnodave
nach
    fd = socket(AF_INET, SOCK_STREAM, 0);
ein
  int option = 1;
  setsockopt(fd,SOL_SOCKET,SO_KEEPALIVE(const char *) &option,sizeof(option));
einzufügen


----------



## Rainer Hönle (3 November 2009)

pvbrowser schrieb:


> In diesem Falle wird die TCP Verbindung einfach abgewürgt.
> 
> Damit der Partner das mitbekommt, muss ein Lebenszeichen Telegramm vorhanden sein.
> 
> ...


Hallo Rainer,
er hat einen PC-Adapter keine TCP/IP-Verbindung.


----------



## Indi.An-er (4 November 2009)

RobiHerb schrieb:


> Auch nach 30 Minuten hat die SPS keine Lust zu antworten, es ist übrigens ein MPI Adapter, über den die Kommunikation läuft.



Das ist eindeutig zu lang, selbst wenn Du die Verbindung direkt im Handshake gekappt hättest.

Ich kann mich an ein ähnliches Verhalten errinnern. Damals lag es an der virtuellen seriellen Schnittstelle des USB-Serial-Adapters. Die können es scheinbar nicht so gut ab, wenn mitten in der Kommunikation mit dem Debuggen aufgehört wird. Ansonsten würde ich einmal den MPI-Adapter durchstarten. 
Das Du es schaffst mit einem undefinierten Abbruch der Verbindung die SPS derart abzuschiessen sodass ein Urstart notwendig ist, ist mir noch nicht passiert. 
Gerade weil du von C# aus Libnodave eingebunden hast, durchläufst du das Kommunikationshandshake nicht im Einzelschritt und kannst eigentlich auch nicht an der falschen Stelle das Debuggen abbrechen. Zumindestens wäre es sehr schwer und würde nicht andauernd auftreten, so wie Du es geschildert hast.


----------



## RobiHerb (4 November 2009)

*Hardware*



Rainer Hönle schrieb:


> Liegt dies am Adapter oder an der SPS? Was passiert, wenn nur der Adapter aus- und wieder eingesteckt wird? Um was für einen Adapter handelt es sich? Was zeigen die LEDs?




Ich vermute inzwischen auch, dass es der Adapter sein kann. Wenn ich den Adapter von der SPS trenne, und wieder anstecke, geht es wieder.

Der Adapter ist ein Original Siemens RS232 Type 
PC-Adapter V5.0 6ES7 972-0CA22-0XA0

Es ist kein USB im Spiel selbst der PC ist ein Siemens-Fujitsu mit XP.


----------



## Rainer Hönle (4 November 2009)

Der 5.0er hat ja schon einige Tage auf dem Buckel. Schon mit einem aktuellen getestet?


----------



## RobiHerb (4 November 2009)

*Hardware*



Rainer Hönle schrieb:


> Der 5.0er hat ja schon einige Tage auf dem Buckel. Schon mit einem aktuellen getestet?



Wie man so sagt, er ist bei einem Projekt vom Lastwagen gefallen (vergessen worden). Einen neueren habe ich nicht. 

Übrigens mit AG-Link meine ich vor Jahren das gleiche Problem gehabt zu haben, müsste mal die alte Applikation wieder rauskramen.


----------



## Rainer Hönle (4 November 2009)

Dann einfach mal die aktuelle Version von AGLink testen ;-) Wenn es aber ein Adapterproblem ist, dann sehe ich da auch wenig Chancen für eine Besserung.


----------

