# Verbindungsproblem durch Libnodave ???



## MW (22 April 2008)

Hab mal wieder ein Problem was scheinbar mit einer Libnodave ISO_TCP Verbindung zusammen hängt.

Zum Umfeld: 

1 CPU: 315-2DP mit CP 343-1
Auf diese CPU greift ein kleines Progamm mittels Libnodave zu und liest 
alle 500 ms ca 200 Byte. Funktioniert problemlos.

2 CPU: 314C-2DP mit CP 343-1
Diese CPU liest aus der ersten mittels S7-Verbindung (GET) über 
Ethernet.

Es kommt nun sporadisch zu einem Verbindungsabbruch zwischen CPU 1 und CPU 2. Die verbindung wird von CPU 2 aufgebaut, dies gelingt ihr aber nicht solange die Libnodave Anwendung aktiv ist. Beende ich die Libnodave-verbindung, baut CPU 2 die Verbindung sofort wieder auf und es läuft. Nun kann ich die Libnodave anwendung auch wieder laufen lassen.


Woran kann das liegen, dass die erste CPU die Verbindung nicht annimmt ??


----------



## MW (24 April 2008)

Hat denn keiner ne Idee ???


PS: hab vielleicht auch das falsche Forum erwischt   Simatic wäre wohl treffender gewesen


----------



## argv_user (24 April 2008)

Projektier mal bei der CPU1 noch jeweils eine passive ISO_ON_TCP-Verbindung zum Lesen und eine zum Schreiben.

Wichtig: eindeutige TSAPs vergeben.


----------



## MW (24 April 2008)

argv_user schrieb:


> Projektier mal bei der CPU1 noch jeweils eine passive ISO_ON_TCP-Verbindung zum Lesen und eine zum Schreiben.


Erstmal danke für die Antwort

Kann ich frühestens am WE mal probieren, aber wofür sollen diese Verbindungen dann gut sein, damit der CP die S7-Verbindung annimmt ??


----------



## argv_user (24 April 2008)

Soweit mir bekannt ist gibt es eine Defaultverbindung.
Und wenn die belegt ist, muss der nächste halt warten...


----------



## MW (11 Mai 2008)

*Update*



argv_user schrieb:


> Projektier mal bei der CPU1 noch jeweils eine passive ISO_ON_TCP-Verbindung zum Lesen und eine zum Schreiben.


 
Hab ich gemacht  (ich hoffe du meintest unspezifizierte Verbindungen)

Das Problem mit den S7-Verbindungen konnt ich noch nicht überprüfen ob es verschwunden ist, habe aber jetzt etwas anderes festgestellt, wenn ich mit dem PG online eine VAT beobachte (auch über Ethernet) und die Libnodave Kommunikation starte (diese läuft auf einem anderen PC), bricht am PG sofort die Beobachten Funktion zusammen ("Verbindung wurde abgebrochen"). Gleiches passiert wenn ich die "Spezialdiagnose" des CP´s aufgerufen habe. Solange nun die Libnodave verbindung steht, kann mit dem PG weder der Beobachtenmodus noch die Diagnose des CP´s aufgerufen werden ("Keine Verbindung zur Baugruppe"). 

Ich vermute nun, dass das Problem mit dem CP zusammen hängt, da ja nicht mal die Diagnose von ihm Funktioniert. Hat jemand eine idee bzw. Lösung dafür oder kann das mal einer an einer änhlichen Anwendung testen ???

CPU: 315-2DP   (6ES7 315-2AG10-0AB0)
CP:   343-1     (6GK7 343-1EX20-0XE0) 

PG-Verbindungsresourcen der CPU sind jetzt 3 reserviert


----------



## MW (15 Mai 2008)

:icon_question: :icon_question: 

Ist mein Problem wirklich so Kompliziert, dass keine ne idee hat, oder is es so einfach und ihr lacht euch kaputt


edit: wo sind denn nur die Profis (wie Zottel, Ralle, Q_M usw.) wenn man sie braucht :icon_frown:


----------



## alfonsmoeller (1 November 2008)

*Verbindungsprobleme*

Besteht das Problem immer noch ?

Ich würde mal in der HW-Konfig unter Kommunikation die Anzahl der zulässigen Verbindungen erhöhen. Ansonsten muß man an der CPU garnichts machen. Das ist ja eben das gute an LIBNODAVE.

Die Anwendungen die ich geschrieben habe brauchen nicht einmal auf dem jeweiligen PC installiert werden, sondern brauchen nur in ein Verzeichnis kopiert werden. Ziel - IP festlegen, und dann kanns losgehen. Habe die bei uns im Hausnetz ausprobiert mit CPU315 2-DP mit der 317 und mit WinAC. Im Netz befinden sich ca. 50 PC's und im Testfeld einige verschieden AG's.

Mich hat gewundert wie auskunftsfreudig doch alle AG's waren. Man muß sie nur richtig fragen. Schreiben funktioniert natürlich genauso gut.


----------



## MW (1 November 2008)

alfonsmoeller schrieb:


> Besteht das Problem immer noch ?



Nein, das Problem hat sich erledigt (siehe hier), Ursache für dieses Problem war eine falsche Einstellung am CP.


----------

