libnodave via S7Online macht Probleme nach Verbindungstrennung und erneuten Verbinden

[bool]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hab nun das verworfen die LibNodave zu ändern, hab nun in meiner erweiterten libnodave.net.dll die funktion libnodave.daveStrS7onlineError definiert.

Ruf die mal auf wenn dir S7Online -1 als Handle zurückgibt, oder wenn die Kommunikation nicht mehr funzt, um zu sehen ob der S7 Online Treiber einen fehler wirft.

Die Dll lade Ich in den anderen Thread wo Ich bereits die vorige Version hab!

Libnodave.dll kannst du dann wieder die orginale verwenden!

so, habe nun die neue libnodave.net.dll von Dir compiliert und eingebunden. Da wie erwähnt der Verbindungsaufbau an sich bei S7Online fehlerfrei durchläuft gibt auch die openS7online Funktion "0" zurück und damit die libnodave.daveStrS7onlineError auch "Kein Fehler".

Dass das mit dem nicht zurückgesetzten fds.rfd vermutlich nicht das Problem ist, konnte ich mich nun auch bei einem getesten MPI Adapter von PI überzeugen. Nach einem Disconnect war fds.rfd immer noch auf dem alten Wert, es konnte jedoch danach wieder erfolgreich verbunden und gelesen werden.

Das Problem vermute ich aber immer noch beim Verbindungsabbau des S7ONLINE und nicht unbedingt bei der Funktion "openS7online", da ich beobachtet hatte, dass der Adapter in "PG/PC Schnittstelle einstellen" nach dem Verbindungsabbau nicht umgestellt werden konnte, da sie noch immer reserviert war. Erst nach dem Beenden des Programmes konnte ich diese wieder umstellen. Das Problem liegt also wahrscheinlich eher bei der Funktion "res = libnodave.closeS7online(fds.rfd)"

Es ist aber natürlich trotzdem nicht korrekt, dass openS7online "0" zurück gibt und vorgibt es sei alles in Ordnung.

Gruss,

bool

 

[Jochen Kühner]

Jo...

Aber Ich sehe nicht was LibNoDave da falsch machen sollte am Close?? Wenn ich die Doku der FDL Programmierschnittstelle anschaue, macht es LibNoDave eigendlich richtig!

 

[argv_user]

Zuviel Werbung?
-> Hier kostenlos registrieren

,
Es ist aber natürlich trotzdem nicht korrekt, dass openS7online "0" zurück gibt und vorgibt es sei alles in Ordnung.

Ich les mir jetzt nicht extra den Quellcode von LibNoDave durch. Jochen meint, dass hier alles korrekt läuft, das wird wohl stimmen.

Also dann, bool:

Woher, denkst Du, kommt diese 0 ? Sicherlich hat doch die S7Online-Komponente, in die man leider nicht reinschauen kann, gemeldet, dass alles OK ist. Auch LibNoDave muss sich darauf verlassen können, dass angesprochene Unterprogramme (viel mehr sind ja die sogenannten Treiber auch nicht) korrekte Rückgabewerte liefern.

Würde mich wundern, wenn sich andere Bibliothen in der selben Umgebung wesentlich anders verhielten.

Und da ist noch die alte Geschichte mit der Bedenkzeit der S7. Je nachdem an welche man gerät, braucht die eine gewisse Zeit, bevor sie nach einem erfolgreichen Verbindungsabbau einen erneuten Aufbau wieder akzeptiert.

In der Hoffnung, nicht allzusehr daneben zu liegen, wünsche ich allen einen schönen Vatertag.

Gruß
argv_user

 

[bool]

habe soeben ein bischen im Archiv gestöbert und festgestellt, dass das Problem mit dem Freigeben des Adapters unter S7ONLINE bereits schon länger existiert, siehe http://www.sps-foren.de/showthread.php?t=10908

Dort wurde damit experimentiert closeport statt closeS7online zu verwenden. Ich habe dies probiert jedoch feststellen müssen, dass aucn damit der in PG/PC Schnittstelle eingestellte Adapter nicht wirklich wieder frei gegeben wird. Es kann nach dem ?Verbindungsabbau? und erneutem Aufbau zwar wieder kommuniziert werden, jedoch gehen dem Adaptertreiber nach spätestens dem achten Verbindungsabbau und Wiederaufbau die Resourcen aus, denn openS7online bringt dann Error "-202" und die Funktion libnodave.daveStrS7onlineError bringt dann "Resourcenengpaß im Treiber oder in der Lirary".

Gruss,

bool

 

[Jochen Kühner]

habe soeben ein bischen im Archiv gestöbert und festgestellt, dass das Problem mit dem Freigeben des Adapters unter S7ONLINE bereits schon länger existiert, siehe http://www.sps-foren.de/showthread.php?t=10908

Dort wurde damit experimentiert closeport statt closeS7online zu verwenden. Ich habe dies probiert jedoch feststellen müssen, dass aucn damit der in PG/PC Schnittstelle eingestellte Adapter nicht wirklich wieder frei gegeben wird. Es kann nach dem ?Verbindungsabbau? und erneutem Aufbau zwar wieder kommuniziert werden, jedoch gehen dem Adaptertreiber nach spätestens dem achten Verbindungsabbau und Wiederaufbau die Resourcen aus, denn openS7online bringt dann Error "-202" und die Funktion libnodave.daveStrS7onlineError bringt dann "Resourcenengpaß im Treiber oder in der Lirary".

Gruss,

bool

Das mit closeport kann nicht funktionieren, da in der libnodave mit closeport nichts aus der s7onlinx.dll aufgerufen wird, und diese dll ist für dieses Protokoll zuständig. und closes7online ruft einfach nur scp_close der s7onlinx.dll auf, genau so ist es auch in der von mir verlinkten pdf beschrieben, deshalb sehe ich nicht was da falsch sein soll!

Aber probier mal ob mit accon aglink das gleiche problem besteht, so wie ich das gesehn habe nutzen die auch die s7onlinx.dll...

 

[Question_mark]

Zuviel Werbung?
-> Hier kostenlos registrieren

...

Hallo,

Aber probier mal ob mit accon aglink das gleiche problem besteht, so wie ich das gesehn habe nutzen die auch die s7onlinx.dll...

Beim AGLink besteht dieses Problem nicht, das kann ich Dir versichern ..

Gruß

Question_mark

 

[Jochen Kühner]

So...

@bool
Hab mal noch an der S7Online Schnittstelle der LibNodave rumgeschraubt und hie rund da was verändert, vielleicht magst du ja meine Änderungen mal testen... (vielleicht Helfen Sie ja bei deinem problem) Bei mir macht das testen im Moment probleme, das die S7Onlinx welche von libnodave verwendet wird mit meinem Netlink Treiber unter .net wohl abstürzt (macht accon aglink aber auch!, daher tippe ich auch auf ein treiberprob)

 

[bool]

@bool
Hab mal noch an der S7Online Schnittstelle der LibNodave rumgeschraubt und hie rund da was verändert, vielleicht magst du ja meine Änderungen mal testen... (vielleicht Helfen Sie ja bei deinem problem) Bei mir macht das testen im Moment probleme, das die S7Onlinx welche von libnodave verwendet wird mit meinem Netlink Treiber unter .net wohl abstürzt (macht accon aglink aber auch!, daher tippe ich auch auf ein treiberprob)

Hallo Jochen,

Danke für die Info, werde ich gerne die Tage ausprobieren.
Sind die Libnodave.dll und libnodave.net.cs im Anhang Deines Posts http://sps-forum.de/showpost.php?p=262280&postcount=1 noch die aktuelle/letzte Version? Ich frage, da ich die libnodave.net.cs ja dann für mein VB.net Projekt in libnodave.net.dll compilieren muss. Welche Anpassungen bezüglich der S7Online Verbindungsaufbau und Abbau wurden dort vorgenommen? Gibt es eigentlich inzwischen auch eine closeS7online() Variante bei welcher ich beim Schliessen der Verbindung das FensterHandle übergeben kann welche zuvor bei openS7online() angegeben wurde?

Gruss,

bool

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

jo...

Hallo Jochen,

Danke für die Info, werde ich gerne die Tage ausprobieren.
Sind die Libnodave.dll und libnodave.net.cs im Anhang Deines Posts http://sps-forum.de/showpost.php?p=262280&postcount=1 noch die aktuelle/letzte Version? Ich frage, da ich die libnodave.net.cs ja dann für mein VB.net Projekt in libnodave.net.dll compilieren muss. Welche Anpassungen bezüglich der S7Online Verbindungsaufbau und Abbau wurden dort vorgenommen? Gibt es eigentlich inzwischen auch eine closeS7online() Variante bei welcher ich beim Schliessen der Verbindung das FensterHandle übergeben kann welche zuvor bei openS7online() angegeben wurde?

Gruss,

bool

ich stell am monatag wenn ichs getestet habe nochmal ne version online. nein , eine close variante mit handle gibt es nicht (und denke ich wird es auch nie geben). Das handle in den funktionen ist eigendlich dazu da, wenn man die asynchrone scp_send funktion der s7onlinex.dll verwendet, das das fenster mit der hwnd die nachrichten in die winproc bekommt!

 

[Jochen Kühner]

So..

So hab nun meine geänderte libnodave hochgeladen. Probiers mal mit der...

http://www.sps-forum.de/showthread.php?t=36363

Kannst auch mein Beispiel Programm zum testen nehmen (Ist in meinem ConnectionLibrary enthalten)

 

[bool]

Problem gelöst !!!

Ich hatte gemäss einem ergoogleten Beispiel die S7Online Verbindung mt einer Schleife aufgebaut in welcher die Funktion fds.rfd=openS7Online() aufgerufen wurde bis das Ergebnis > 0 ist.

fds.rfd=0 darf hier aber nicht ausgeschlossen werden.

Ausserdem ist an dieser Stelle eine Schleifenfunktion wohl eher nicht zu empfehlen, zumindest nicht wenn in der Schleife nicht alle aufgebauten Verbindungen (hier fds.rfd=0) wieder sauber abgebaut werden.

Tests grade eben haben auf jeden Fall bestätigt, dass mit fds.rdf=0 sowohl ein Lesen während dieser bestehenden Verbindung, als auch ein erneuter Verbindungsaufbau nach einer Verbindungstrennung über S7Online möglich ist.

siehe auch folgenden Thread in welchem das Thema zwischenzeitlich weiterdiskutiert wurde und schliesslich zu dieser Erkenntnis geführt hat:

http://sps-forum.net/showthread.php?p=266220&posted=1#post266220

Viele Grüsse und Danke an alle die mich in den letzten Tagen/Wochen bei der Lösungsfindung unterstützt haben,

bool

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hatte gemäss einem ergoogleten Beispiel die S7Online Verbindung mt einer Schleife aufgebaut in welcher die Funktion fds.rfd=openS7Online() aufgerufen wurde bis das Ergebnis > 0 ist.

fds.rfd=0 darf hier aber nicht ausgeschlossen werden.

Ausserdem ist an dieser Stelle eine Schleifenfunktion wohl eher nicht zu empfehlen, zumindest nicht wenn in der Schleife nicht alle aufgebauten Verbindungen (hier fds.rfd=0) wieder sauber abgebaut werden.

Tests grade eben haben auf jeden Fall bestätigt, dass mit fds.rdf=0 sowohl ein Lesen während dieser bestehenden Verbindung, als auch ein erneuter Verbindungsaufbau nach einer Verbindungstrennung über S7Online möglich ist.

siehe auch folgenden Thread in welchem das Thema zwischenzeitlich weiterdiskutiert wurde und schliesslich zu dieser Erkenntnis geführt hat:

http://sps-forum.net/showthread.php?p=266220&posted=1#post266220

Viele Grüsse und Danke an alle die mich in den letzten Tagen/Wochen bei der Lösungsfindung unterstützt haben,

bool

Noch eine Frage, geht der abbau und das Editieren nun auch mit der orginalen libnodave richtig, oder sind die Änderungen welche Ich für den disconnect eingebaut habe nötig?

 

[bool]

Noch eine Frage, geht der abbau und das Editieren nun auch mit der orginalen libnodave richtig, oder sind die Änderungen welche Ich für den disconnect eingebaut habe nötig?

Habe grad mal die originale libnodave.dll und libnodave.net.dll (plus PtrToStringAnsi Anpassung) von libnodave Version 0.8.4.5 genommen und nen kurzen Kommunikationstest mit mehreren Reconnects gemacht und siehe da es funktionierte, und das obwohl noch die alte openS7online() Funktion verwendet wird, welcher noch nicht das Window-Handle übergegebn wird.
Nach dem Disconnect wurde ausserdem der verwendete Adapter wieder korrekt freigegeben. In meinem Fall scheint tatsächlich alles an dem doppelten openS7online() Funktionsaufruf gehangen zu haben.

Gruss,

bool

 

[Jochen Kühner]

Habe grad mal die originale libnodave.dll und libnodave.net.dll (plus PtrToStringAnsi Anpassung) von libnodave Version 0.8.4.5 genommen und nen kurzen Kommunikationstest mit mehreren Reconnects gemacht und siehe da es funktionierte, und das obwohl noch die alte openS7online() Funktion verwendet wird, welcher noch nicht das Window-Handle übergegebn wird.
Nach dem Disconnect wurde ausserdem der verwendete Adapter wieder korrekt freigegeben. In meinem Fall scheint tatsächlich alles an dem doppelten openS7online() Funktionsaufruf gehangen zu haben.

Gruss,

bool

Das mit dem Windowshandle hat soweit Ich das sehe auch nichts zu bedeuten. Laut doku wird das handle ja nur gebraucht wenn man die asychronen scp_recieve funktionen der s7onlinx.dll verwendet, was libnodave aber nicht tut!

 

[bool]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe nun nachdem der Reconnect nach Verbindungsabbruch unter Verwendung des S7Online Protokolls nun tadellos funktioniert (Danke an dieser Stelle nochmals an J.K.) nun noch ein kleines Problem beim Verbindungsabbruch (S7Online über CP5611 und RS232->MPI) selbst festgestellt.

Ich bekomme hin und wieder eine Speicherverletzung durch die Funktionen dc.getU8(), dc.getU16(), dc.getU32(), etc.... Dies habe ich bislang eigentlich nur bei S7Online Verbindungen über MPI Adapter festgestellt, bei Etherentverbindung gab es bislang noch keine Meldung bezüglich einer Speicherverletzung beim Ziehen des Netzwerkkabels.
Inzwischen habe ich die Auswertung der Funktion res=dc.useResult(rs, 0) mit berücksichtigt und dadurch herausbekommen, dass es vorkommen kann, dass die vorangehende Lesefunktion res = dc.execReadRequest(multireadPDU01, rs) eigentlich "0" (ok) zurück gibt, die Funktion useResult() aber den Wert -126 (this result contains no data), also Fehler meldet.

Dies passiert nicht immer sondern so wie es ausschaut eher zufällig, je nachdem in welchem Moment das MPI Kabel gezogen wird. Ich hatte die Speicherverletzung zwar mit der Exceptionbehandlung via try...catch abgefangen, ist aber natürlich nicht die sauberste Lösung Jetzt überprüfe ich vor der Ausführung der get***() Funktionen ob die useResult() <> "0" meldet und reagiere dann ebenfalls nach x Fehlern in Folge mit einem Reconnect.

Ist dies bei Euch ebenfalls so nachvollziehbar und gibt es ggf. eine bessere Variante Verbindungsfehler zur SPS zu detektieren?

Gruss,

bool

 

[Jochen Kühner]

Habe nun nachdem der Reconnect nach Verbindungsabbruch unter Verwendung des S7Online Protokolls nun tadellos funktioniert (Danke an dieser Stelle nochmals an J.K.) nun noch ein kleines Problem beim Verbindungsabbruch (S7Online über CP5611 und RS232->MPI) selbst festgestellt.

Ich bekomme hin und wieder eine Speicherverletzung durch die Funktionen dc.getU8(), dc.getU16(), dc.getU32(), etc.... Dies habe ich bislang eigentlich nur bei S7Online Verbindungen über MPI Adapter festgestellt, bei Etherentverbindung gab es bislang noch keine Meldung bezüglich einer Speicherverletzung beim Ziehen des Netzwerkkabels.
Inzwischen habe ich die Auswertung der Funktion res=dc.useResult(rs, 0) mit berücksichtigt und dadurch herausbekommen, dass es vorkommen kann, dass die vorangehende Lesefunktion res = dc.execReadRequest(multireadPDU01, rs) eigentlich "0" (ok) zurück gibt, die Funktion useResult() aber den Wert -126 (this result contains no data), also Fehler meldet.

Dies passiert nicht immer sondern so wie es ausschaut eher zufällig, je nachdem in welchem Moment das MPI Kabel gezogen wird. Ich hatte die Speicherverletzung zwar mit der Exceptionbehandlung via try...catch abgefangen, ist aber natürlich nicht die sauberste Lösung Jetzt überprüfe ich vor der Ausführung der get***() Funktionen ob die useResult() <> "0" meldet und reagiere dann ebenfalls nach x Fehlern in Folge mit einem Reconnect.

Ist dies bei Euch ebenfalls so nachvollziehbar und gibt es ggf. eine bessere Variante Verbindungsfehler zur SPS zu detektieren?

Gruss,

bool

So wie Ich das sehe Wertet libnodave beim ausführen von Funktionen an s7onlinx.dll nur den rückgabewert der funktion aus, aber nicht die zurückgegeben daten.

Vieleicht kannst du ja mit meinen Wrapper sehen was nach einem verbindungsabbruch anderst von s7online zurück kommt, als wenn die verbindung noch besteht!

Dazu kann dir auch meine excel Tabelle aus folgenden Thread (http://www.sps-forum.de/showthread.php?t=36719) helfen. Da gibt es eine Tabelle LibNoDave Kommunikation, und ein Script (aa) mit welchem du die daten aus der log.txt in die einzelnen tabellenzeilen eintragen lassen kannst.

 

[Jochen Kühner]

Noch zur Info:

Noch zur Info.

Über s7online läuft eine Anfrage nach Daten immer über 4 telegramme ab. (hoffe Ich erzähle jetzt keinen stuss)

scp_send aufruf mit der pdu um daten zu lesen.
scp_recieve quittung des telegrammes
scp_send aufruf um die daten abzufragen
scp_recieve aufruf mit den empfangen daten.

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und nochmal was...

Ich denke man muss die Daten des ersten scp_recieves analysieren, ob da ein fehler kommt.

Habe gerade auch nochmal in die libnodave geschaut, es wird nicht mal der rückgabewert der funktionen scp_send und scp_recieve ausgewertet!

 

[bool]

Ich denke man muss die Daten des ersten scp_recieves analysieren, ob da ein fehler kommt.

Habe gerade auch nochmal in die libnodave geschaut, es wird nicht mal der rückgabewert der funktionen scp_send und scp_recieve ausgewertet!

Hallo Jochen,

Danke für die (wie gewohnt) schnelle und informative Rückmeldung.

Ich denke mal, das ist halt wahrscheinlich einer der Gründe warum die S7Online Kommunikation noch Entwicklungsstatus hat.

Gerne werde ich im Rahmen meiner eingeschränkten Möglichkeiten als Hochspracheneinsteiger meinen Teil dazu beitragen und mir die Telegramme ebenfalls einmal ansehen und versuchen Unterschiede in den Telegrammen festzustellen.

Gruss,

bool

 

[Jochen Kühner]

Hallo Jochen,

Danke für die (wie gewohnt) schnelle und informative Rückmeldung.

Ich denke mal, das ist halt wahrscheinlich einer der Gründe warum die S7Online Kommunikation noch Entwicklungsstatus hat.

Gerne werde ich im Rahmen meiner eingeschränkten Möglichkeiten als Hochspracheneinsteiger meinen Teil dazu beitragen und mir die Telegramme ebenfalls einmal ansehen und versuchen Unterschiede in den Telegrammen festzustellen.

Gruss,

bool

Hab in libnodave mal noch Logging Meldungen eingebaut das die Rückgabewerte von scp_send und scp_recieve ausgegeben werden.

Das kannst du mit meinem Connection Lib Testen. Dazu einfach in der Connect Funktion der LibNoDaveConnection.cs die Zeile //libnodave.daveSetDebug(0x1ffff); auskomentieren. Dann kannst du wenn du meine Connection Lib startest die Debug Daten im Ausgabe Fenster sehen!