LibNoDave und das .NET Framework

[GvOdin]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

Ü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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

... 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.

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]

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]

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.





Gruß Axel

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