# LibNoDave und das .NET Framework



## GvOdin (17 März 2008)

Hallo @all

Ich habe ein Programm geschrieben welches zyklisch (alle 60s) Daten aus einer  S7-CPU holt. Das funktioniert auch für ungefähr 45min ganz gut, aber dann kann LibNoDave den Port 102 (IsoOnTcp) nicht mehr öffnen.

Mir wurde nun von einem Kollegen zugetragen das dies ein Problem vom .NET Framework ist. Ist das so??? Wenn ja wie kann ich das Problem umgehen oder lösen?

Hardware: CPU317-PN/DP + CP343-1 Lean
Software: MS Visual Studio 2005 (VB.NET)

Vielen Dank im Vorraus


----------



## Rainer Hönle (17 März 2008)

Wie sieht prinzipiell die Funktion aus?
Öffnen, Lesen, Schließen?
Wird das Schließen immer durchlaufen? 
Wie sehen die Verbindungs-Resourcen auf der 317er aus? Sind wirklich alle freigegeben?
Worüber wird kommuniziert, über die 317er oder die CP343-1?


----------



## GvOdin (17 März 2008)

Aussehen der Funktion ist: Öffnen --> Lesen bzw. Schreiben --> Schließen 

Das Schließen wird immer durchlaufen, da bin ich mir auch sehr sicher.

Ich kommuniziere über den CP343-1 Lean, da ich irgendwo mal gelesen habe, dass das mit der 317 nicht geht.

Danke für die schnelle Antwort


----------



## Rainer Hönle (17 März 2008)

Über die 317-2PN/DP sollte das auch ohne die CP343-1 gehen. Einfach mal die IP-Adresse ändern und testen.
Aber noch einmal: Was zeigt Baugruppenzustand unter Kommunikation an, wenn die Verbindung nicht mehr aufgebaut werden kann?


----------



## afk (17 März 2008)

Bei libnodave gab (gibt ?) es ein Problem bei der Kommunikation per ISO-over-TCP, wenn die Verbindung ständig geöffnet und geschlossen wird, weil zumindest in älteren Versionen der Socket nicht geschlossen wurde, was dann dazu führt, das irgendwann die Resourcen ausgehen. Abhilfe schafft da das explizite Schließen des Sockets durch die ensprechende Funktion der Winsock-API, aber grundsätzlich wäre es performanter, die Verbindung einfach durchgehend geöffnet zu lassen.

Gruß Axel


----------



## MW (17 März 2008)

afk schrieb:


> Bei libnodave gab (gibt ?) es ein Problem bei der Kommunikation per ISO-over-TCP, wenn die Verbindung ständig geöffnet und geschlossen wird, weil zumindest in älteren Versionen der Socket nicht geschlossen wurde, was dann dazu führt, das irgendwann die Resourcen ausgehen. Abhilfe schafft da das explizite Schließen des Sockets durch die ensprechende Funktion der Winsock-API, aber grundsätzlich wäre es performanter, die Verbindung einfach durchgehend geöffnet zu lassen.
> 
> Gruß Axel


 
Sollte man also besser die Verbindungen offen lassen ???
Gibts da irgendeine Regel, wie man Auswählt ob man die Verbindung offen lässt oder jedesmal neu öffnet und schließt ???

Beispiel: 10 SPS´n a 1 Verbindung, alle 60 sek daten lesen, sollte man da besser die Verbindung halten oder immerwieder neu aufbauen ??


----------



## eloboy (17 März 2008)

Schau mal ob du nicht zufällig gleichzeitig schreiben und lesen versuchst.
Das war mein Problem.

Außerdem könntest du die Objekte noch manuel zerstören.


----------



## Ruud (17 März 2008)

Hallo,

Ich slieBe nur die verbindung wenn ich meine "application" schlieBe. Damit hatte ich noch nie probleme!



!!Es ist mein besten Deutsch!! gruss aus Holland


----------



## MW (17 März 2008)

Ruud schrieb:


> Hallo,
> 
> Ich slieBe nur die verbindung wenn ich meine "application" schlieBe. Damit hatte ich noch nie probleme!
> 
> !!Es ist mein besten Deutsch!! gruss aus Holland


 
//Scherzmode ON

Ahh, gibt kein "ch" und kein "ß" in Holland   

//Scherzmode OFF


----------



## beowonne (28 März 2008)

GvOdin schrieb:


> Hallo @all
> 
> Ich habe ein Programm geschrieben welches zyklisch (alle 60s) Daten aus einer S7-CPU holt. Das funktioniert auch für ungefähr 45min ganz gut, aber dann kann LibNoDave den Port 102 (IsoOnTcp) nicht mehr öffnen.
> 
> ...


 

Hallo,

habe das selbe Problem, verwende VB6 , hole aus 7CPU's je ein Merkerwort Hardware ist die selbe, Fehler tritt nach unterschiedlicher Laufzeit auf.


----------



## Ralle (29 März 2008)

Ich lasse die Verbindung grundsätzlich offen, schließe sie entweder, indem ich die Applikation Offline schalte, oder sie ganz beende. eine Regel gibt es sicherlich nicht, aber wenn im normalen Betrieb zu viele Verbindungsabbrüche auftreten sollten, könnte man darüber nachdenken. Bei tagelangen Tests hatte ich aber noch nie Probleme und auch keine Abstürze. In fast allen Fällen, war mein Programmcode schuld, wenn sich eine Applikation aufhängt. Das von afk beschriebene Verhalten ist m.E. abgestellt, aber du kannst es beobachten, wenn du den Taskmanager öffnest und die in der Prozessliste mal die Anzahl der Threads, der Handle etc. anschaust. Auch mal ansehen, on der Speicherbedarf deines Programmes mit der Zeit stark wächst, evtl. werden Recourcen nicht korrekt freigegeben.


----------



## afk (29 März 2008)

beowonne schrieb:


> ... habe das selbe Problem, verwende VB6 ...


Noch mal klar und deutlich:
Die Verbindung zur CPU sollte so lange wie möglich aufrecht erhalten werden. Der immer wieder neu erfolgende Verbindungsauf- und -abbau kostet auf beiden Seiten (PC und SPS) unnötig Resourcen.



Ralle schrieb:


> Das von afk beschriebene Verhalten ist m.E. abgestellt, aber du kannst es beobachten, wenn du den Taskmanager öffnest und die in der Prozessliste mal die Anzahl der Threads, der Handle etc. anschaust. Auch mal ansehen, on der Speicherbedarf deines Programmes mit der Zeit stark wächst, evtl. werden Recourcen nicht korrekt freigegeben.


Zumindest auf den Speicherbedarf des Programms hat es AFAIK keinen wirklich merkbaren Einfluß, wenn die Sockets nicht mehr freigegeben werden, und die Anzahl der Handles wird von vielen Faktoren beeinflußt, ist also leider auch kein eindeutiger Indikator für das Problem.


Gruß Axel


----------



## Ralle (29 März 2008)

afk schrieb:


> Zumindest auf den Speicherbedarf des Programms hat es AFAIK keinen wirklich merkbaren Einfluß, wenn die Sockets nicht mehr freigegeben werden, und die Anzahl der Handles wird von vielen Faktoren beeinflußt, ist also leider auch kein eindeutiger Indikator für das Problem.
> 
> 
> Gruß Axel


*ACK* 
Ich wollte nur nochmal darauf hinweisen, daß das Problem in den meißten Fällen nicht libnodave ist, sondern das Drumherum, das man selbst schreibt. 
Wenn man die Verbindung ständig auf- und abbaut und dazu noch selbst irgendwelche Recourcen reserviert und diese danach nicht korrekt freigibt, hat man auch so ein Ergebnis und meint fälschlich, es wäre libnodave.


----------



## beowonne (29 März 2008)

afk schrieb:


> Noch mal klar und deutlich:
> Die Verbindung zur CPU sollte so lange wie möglich aufrecht erhalten werden. Der immer wieder neu erfolgende Verbindungsauf- und -abbau kostet auf beiden Seiten (PC und SPS) unnötig Resourcen.
> 
> 
> ...



Werd  montag das auch versuchen  wollt damit nur sagen das es nicht am .NET liegt.   Beowonne


----------

