# libnodave via S7Online macht Probleme nach Verbindungstrennung und erneuten Verbinden



## bool (8 Mai 2010)

Hallo zusammen,

inzwischen bin ich dabei mit dem S7Online Protokoll zu experimentieren und habe dieses prinzipiell mit dem PCMCIA CP5511 MPI/Profibus Adapter zum laufen bekommen. Den Verbindungsauf und Abbau habe ich gemäss diverser Programmbeispiele folgendermassen vorgenommen:


Verbindungsaufbau (wichtigsten Funktionen aus dem Code extrahiert):
fds.rfd = libnodave.openS7online(S7Online_accesspoint)
fds.wfd = fds.rfd
di = New libnodave.daveInterface(fds, "IF1", S7Online_localAddress, libnodave.daveProtoS7online, nodaveBaudrate)
di.setTimeout(1000)
res = di.initAdapter
dc = New libnodave.daveConnection(di, S7Online_remoteAddress, S7Online_rack, S7Online_slot)
res = dc.connectPLC

Verbindungsabbau (wichtigsten Funktionen aus dem Code extrahiert):

res = dc.disconnectPLC()
di.disconnectAdapter()
'res = libnodave.closePort(fds.rfd)
'WriteDebugInfo("Close S7Online Connection: closePort() ... (res=" & CStr(res) & " - " & libnodave.daveStrerror(res) & ")")
res = libnodave.closeS7online(fds.rfd)
WriteDebugInfo("Close S7Online Connection: closeS7online() ... (res=" & CStr(res) & " - " & libnodave.daveStrerror(res) & ")")

Für mich stellen sich nun folgende Fragen:

Muss ich beim Verbindungsabbau die Funktion 
a) libnodave.closeS7online(fds.rfd) oder 
b) libnodave.closePort(fds.rfd) ausführen 
oder sogar beide?
Bei dem von mir als Vorlage verwendeten Programmbeispiel wurde Variante b) verwendet aber wofür gibt es dann a)?

Warum funktioniert das Lesen nur nach dem ersten Verbindungsaufbau und ab dem zweiten Verbindungsaufbau nicht mehr?

Dann bekomme ich vom dc.execReadRequest() nur noch eine "-128"
Leider funktioniert bei mir ausserdem die Funktion "libnodave.daveStrerror(res)" nicht richtig, ich bekomme leider den Fehlertext nicht im Klartext sondern nur kryptische Zeichen zurück.

Ich habe in einem anderen Thread gelesen, dass in "neueren versionen der LibNoDave an S7Online eine HWND Übergeben" werden muss.
Was steckt da dahinter? Was muss ich machen und wie würde dies Codetechnisch für VB 2008 Express aussehen?

Danke bereits jetzt im voraus für Eure Unterstützung.

Gruss,

bool


----------



## Jochen Kühner (9 Mai 2010)

*Hwnd.*

benutzt du auch S7Online aus der neusten LibNoDave der du die HWND des Fensters mitgeben musst?


----------



## bool (9 Mai 2010)

Jochen Kühner schrieb:


> benutzt du auch S7Online aus der neusten LibNoDave der du die HWND des Fensters mitgeben musst?


Hallo Jochen,
was meinst Du mit der neuen LibNoDave und wie muss welcher Funktion das HWND des Fensters übergeben werden?
Ich verwende die LibNoDave 0.8.4.5 mit der libnodave.dll, libnodave.lib und libnodave.net.dll vom 12.07.2009. 
Als Verweis eingebunden habe ich die libnodave.net.dll da VB2008Express ja auf .NET basiert. Bei der Funktion 
fds.rfd = libnodave.openS7online(S7Online_accesspoint) kann ich leider kein HWND als zweiten Parameter übergeben.

Gibt es da neuere Bibliotheken und wenn ja wo kann ich diese herbekommen? Ich habe die dll aus LibNoDave 0.8.4.5 und eigenlich erst vor ein paar Wochen von http://sourceforge.net/projects/libnodave/
runtergeladen.

Für Informationen diesbezüglich wäre ich sehr dankbar.

Gruss,

bool


----------



## bool (9 Mai 2010)

bool schrieb:


> Verbindungsaufbau (wichtigsten Funktionen aus dem Code extrahiert):
> fds.rfd = libnodave.openS7online(S7Online_accesspoint)
> fds.wfd = fds.rfd
> di = New libnodave.daveInterface(fds, "IF1", S7Online_localAddress, libnodave.daveProtoS7online, nodaveBaudrate)
> ...


 
Hilft hier überhaupt die neue Funktion welcher das hWnd des aktiven Fensters mit übergegeben wird oder müsste dies auch mit der älteren Variante funktionieren welche so wie es scheint noch bei der aktuellen libnodave.net.dll (für .NET Applikationen) implementiert ist?
Oder gibt es eine aktueller dll welche ich hier verwenden sollte?
Welche der folgenden Funktionen müssen beim Verbindungsabbau in welcher Reihenfolge ausgeführt werden, so dass die Verbindung sauber und komplett geschlossen wird und nach dem nächsten Verbindungsaufbau wieder erfolgreich gelesen werden kann?

a) libnodave.closeS7online(fds.rfd) oder 
b) libnodave.closePort(fds.rfd) ? oder beide?

Danke bereits im voraus.

Gruss,

bool


----------



## Jochen Kühner (9 Mai 2010)

*Hm.*

also bei mir geht der aufruf ohne die hwnd gar nicht mehr, kann es sein, das du viel noch eine alte version der dll im system32 ordner hast!


----------



## bool (9 Mai 2010)

Jochen Kühner schrieb:


> also bei mir geht der aufruf ohne die hwnd gar nicht mehr, kann es sein, das du viel noch eine alte version der dll im system32 ordner hast!


 
Hab grad den kompletten Windowsordner durchsuchen lassen, doch da habe ich überhaupt keine libnodave DLL, ich habe sie nur im Projektordner, im Debug und Releaseordner.

Die libnodave.net.dll habe ich wie in meinem anderen Thread gepostet über Verweise eingebunden.

Gruss,

bool


----------



## Jochen Kühner (10 Mai 2010)

bool schrieb:


> Hab grad den kompletten Windowsordner durchsuchen lassen, doch da habe ich überhaupt keine libnodave DLL, ich habe sie nur im Projektordner, im Debug und Releaseordner.
> 
> Die libnodave.net.dll habe ich wie in meinem anderen Thread gepostet über Verweise eingebunden.
> 
> ...



Also bei mir wurde von CSharp auf jeden fall gemeckert das er in der Libnodave .dll die funktion ohne 2 parameter nicht gefunden hat. Ich habe aber die libnodave.net.dll auch nicht benutzt sondern das csharp sourcefile!


----------



## bool (10 Mai 2010)

Jochen Kühner schrieb:


> Also bei mir wurde von CSharp auf jeden fall gemeckert das er in der Libnodave .dll die funktion ohne 2 parameter nicht gefunden hat. Ich habe aber die libnodave.net.dll auch nicht benutzt sondern das csharp sourcefile!


 
Heisst dies, dass das gesamte libnodave in csharp also sourcefile vorliegt und alle Funktionen direkt eingesehen und bei Bedarf (wie hier nun in meinem Fall) angepasst werden können?
So langsam glaube ich, dass in Bezug auf libnodave es wahrscheinlich am besten wäre sich von VB zu lösen und auf CSharp umzusatteln.


Gruss,

bool


----------



## Jochen Kühner (10 Mai 2010)

bool schrieb:


> Heisst dies, dass das gesamte libnodave in csharp also sourcefile vorliegt und alle Funktionen direkt eingesehen und bei Bedarf (wie hier nun in meinem Fall) angepasst werden können?
> So langsam glaube ich, dass in Bezug auf libnodave es wahrscheinlich am besten wäre sich von VB zu lösen und auf CSharp umzusatteln.
> 
> 
> ...



Nein, das heisst es nicht, d.h. Ich habe die LibNoDave.net.cs in meinem Projekt und nicht als Dll eingebunden, nicht die libnodave.dll!


----------



## bool (10 Mai 2010)

Jochen Kühner schrieb:


> Nein, das heisst es nicht, d.h. Ich habe die LibNoDave.net.cs in meinem Projekt und nicht als Dll eingebunden, nicht die libnodave.dll!


 
Wie in meinem anderen Thread gepostet, habe ich (mit Hilfe Deiner Tips) inzwischen die libnodave.net.dll aus der Datei libnodave.net.cs erzeugen können.

Zwar bekomme ich nun ebenfalls die openS7online(S7ONLINE, HWND) Deklaration inkusive hWnd aber ein Variablenzugriff nach dem ersten Verbindungsabbau und erneuten Verbindungsaufbau funktioniert leider immer noch nicht. Ich bekomme von der Funktion dc.execReadRequest() nur noch eine "-128", dieses mal jedoch mit dem Klartext "Unexpected function code in answer". Wie gesagt, nach dem ersten Verbindungsaufbau funktioniert das Pollen der Daten mit dc.execReadRequest() einwandfrei, nach dem Verbindungsabbau (Programmcodeauszug siehe in meinem ersten post von diesem Thread) und erneuten Verbindungsaufbau dann leider nicht mehr.

Kann es vielleich auch sein, dass ich das HWND Handle falsch erzeuge?
Was mich wundert ist nämlich, dass in der angezeigten Deklaration das hWnd als Integer angegeben wird und nicht als IntPtr weshalb ich den Aufruf folgendermassen gestaltet habe:

Dim hWnd As IntPtr = GetForegroundWindow()
Dim ihWnd AsInteger = CInt(hWnd)
For i = 0 To 3
fds.rfd = libnodave.openS7online(S7Online_Accesspoint, ihWnd) 
fds.wfd = fds.rfd
If fds.rfd > 0 Then
ExitFor
EndIf
Next


Auf diese Weise bekomme ich den Handlewert als Integer in die ihWnd Variable geschrieben und sollte so eigentlich funktionieren.
Doch wie gesagt ergab dies leider keine Besserung nach dem zweiten Connect.

Ich hoffe Ihr habt weiterhin Ideen, ich werde sie gerne ausprobieren.

Gruss,

bool


----------



## bool (11 Mai 2010)

bool schrieb:


> Zwar bekomme ich nun ebenfalls die openS7online(S7ONLINE, HWND) Deklaration inkusive hWnd aber ein Variablenzugriff nach dem ersten Verbindungsabbau und erneuten Verbindungsaufbau funktioniert leider immer noch nicht. Ich bekomme von der Funktion dc.execReadRequest() nur noch eine "-128", dieses mal jedoch mit dem Klartext "Unexpected function code in answer". Wie gesagt, nach dem ersten Verbindungsaufbau funktioniert das Pollen der Daten mit dc.execReadRequest() einwandfrei, nach dem Verbindungsabbau (Programmcodeauszug siehe in meinem ersten post von diesem Thread) und erneuten Verbindungsaufbau dann leider nicht mehr.


 
Hallo, jetzt muss ich mich schon selbst zitieren , aber ich habe eine neue interessante Erkenntniss welche vielleicht helfen könnte dem Problem auf die Spur zu kommen.

Für die S7ONLINE verwende ich einen SIEMENS PCMCIA Adapter des Typs CP5511. 

Als dll verwende ich übrigens inzwischen die als dll compilierte libnodave.net.cs von Jochen Kühner welche die Funktion openS7online via Windowhandle parametriert.

*Und jetzt kommts: *
Wenn der CP5511 in "PG/PC Schnittestelle einstellen" fest auf "MPI" eingestellt ist funktioniert das Auslesen auch nach dem x-ten Verbindungsaufbau, wenn der Adapter jedoch "Auto" eingestellt (z.B. um über Profibus zu kommunizieren) ist, geht bereits wie oben im Thread beschrieben das Auslesen ab der zweiten Verbindung schief. Ab der zweiten Verbindung bekomme ich dann auch beinahe unverzögert das Ergebnis 0 (ok) von di.initAdapter und dc.connectPLC.
Wenn jedoch die Verbindung richtig beendet worden wäre müsste der erneute Verbindungsaufbau ja auch wieder um einiges länger dauern, was es ja auch tut wenn ich den CP551 Adapter unter "PG/PC Schnittstelle einstellen" fest auf "MPI" stelle.

fds.rfd = libnodave.openS7online(S7Online_Accesspoint, CInt(hWnd))
fds.wfd = fds.rfd
...
di = New libnodave.daveInterface(fds, "IF1", S7Online_LocalAddress, libnodave.daveProtoS7online, nodaveBaudrate)
di.setTimeout(1000)
res = di.initAdapter
dc = New libnodave.daveConnection(di, S7Online_remoteAddress, S7Online_rack, S7Online_slot)
res = dc.connectPLC

Vielleicht kann hiermit die Problemursache eingeschränkt werden und es hat jemand eine Idee.

Ich würde mich sehr freuen.

Ein *anderes Phenomen* welches ich grade eben beobachtet habe ist, dass die Funktion "res =* dc.connectPLC" auch die Rückmeldung 0 (ok)* bringt, *obwohl die parametrierte remote Profibus- oder MPI-Adresse* aus 
dc = New libnodave.daveConnection(di, S7Online_remoteAddress, S7Online_rack, S7Online_slot) *im MPI- bzw Profibusnetz **gar nicht existiert*. Das Ergebnis ist dann auch hier, dass die Lesefunktion 
dc.execReadRequest() ebenfalls eine "-128" (Unexpected function code in answer) ausspuckt. 

Hat hier vielleicht jemand eine Idee wie man das Verhindern kann oder ist es noch ein Bug in der Funktion dc.connectPLC?

Gruss,

bool


----------



## Jochen Kühner (11 Mai 2010)

*Beschreibung...*

Habe folgendes Dokument gefunden:

https://support.automation.siemens....l-api_0.pdf?func=cslib.csFetch&nodeid=1653428

dort ist unter Besonderheiten für Windows beschriebn wofür das Handele überhaupt verwendet wird, vieleicht ist das Problem das in der WinProc des Programmes nicht auf die Messages reagiert wird??


----------



## bool (11 Mai 2010)

bool schrieb:


> *Und jetzt kommts: *
> Wenn der CP5511 in "PG/PC Schnittestelle einstellen" fest auf "MPI" eingestellt ist funktioniert das Auslesen auch nach dem x-ten Verbindungsaufbau, wenn der Adapter jedoch "Auto" eingestellt (z.B. um über Profibus zu kommunizieren) ist, geht bereits wie oben im Thread beschrieben das Auslesen ab der zweiten Verbindung schief. Ab der zweiten Verbindung bekomme ich dann auch beinahe unverzögert das Ergebnis 0 (ok) von di.initAdapter und dc.connectPLC.
> Wenn jedoch die Verbindung richtig beendet worden wäre müsste der erneute Verbindungsaufbau ja auch wieder um einiges länger dauern, was es ja auch tut wenn ich den CP551 Adapter unter "PG/PC Schnittstelle einstellen" fest auf "MPI" stelle.



Scheibenkleister,
nachdem ich die Hardwarekonfig neu übertragen habe um die Schnittstelle auf Profibus umzustellen und diese ebenfalls unter der Einstellung "Auto" des CP5511 zu testen (funktioniert ebenfalls nur nach dem ersten Verbidnungsaufbau) und wieder auf MPI zurück bin. funktionierte das Lesen nach dem zweiten Verbindungsaufbau auch bei fest konfiguriertem "MPI" nicht mehr. Was zuvor grade noch reproduzierbar war, ist jetzt wieder hahnebüchen... alles wieder auf Anfang.
Scheibenkleister!



> Habe folgendes Dokument gefunden:
> https://support.automation.siemens.c...nodeid=1653428
> dort ist unter Besonderheiten für Windows beschriebn wofür das Handele überhaupt verwendet wird, vieleicht ist das Problem das in der WinProc des Programmes nicht auf die Messages reagiert wird??


Ok, danke schon mal für die Anregung..., aber als reiner libnodave user kann ich darauf wahrscheinlich keinen Einfluss nehmen, oder doch?
Ich denke da ist Zottel gefragt, das ist doch so meine ich der Urvater von libnodave wenn ich mich nicht irre.
Ich hoffe er kann mir mit diesem Problem weiterhelfen.

Gruss,

bool


----------



## bool (11 Mai 2010)

Ich kann nun noch folgende Erkenntnis beisteuern:

Bei dem ersten Verbindungsaufbau (nach Applikationsstart) ist vor dem ersten Aufruf (FOR Schleife 0-3 da die S7ONLINE Verbindung hin und wieder mehrere Anläufe braucht) von 
fds.rfd = libnodave.openS7online(S7Online_accesspoint)
das fds.rdf noch = 0, nach dem Funktionsaufruf ist dieses dann =1.

Beim Verbindungsabbau ist nach dem Funktionsaufruf von 
res = libnodave.closeS7online(fds.rfd)
das fds.rfd immer noch 1 (res=0) und ich glaube hier liegt der Hund begraben. 

Bei dem zweiten Verbindungsaufbau ist vor dem ersten Aufruf von 
fds.rfd = libnodave.openS7online(S7Online_accesspoint)
das fds.rdf noch immer = 1, es wird jedoch keine neue Verbindung aufgebaut. Es scheint als wäre die alte Verbindung hängen geblieben.
Eine stumpfe Zuweisung von "0" an fds.rfd beim Verbindungsabbau bringt hier keine Besserung, auch kein Schleifen der libnodave.closeS7online() Funktion bis fds.rdf = 0 ist, denn diese wird nicht 0, aber res dagegen wird ab dem zweiten Aufruf der closeS7online() Funktion -1.

Ich hoffe es kann jemand mit dieser neuen Erkenntnis etwas anfangen und mir bei meinem Problem weiterhelfen.

Gruss,

bool


----------



## Jochen Kühner (11 Mai 2010)

bool schrieb:


> Ich kann nun noch folgende Erkenntnis beisteuern:
> 
> Bei dem ersten Verbindungsaufbau (nach Applikationsstart) ist vor dem ersten Aufruf (FOR Schleife 0-3 da die S7ONLINE Verbindung hin und wieder mehrere Anläufe braucht) von
> fds.rfd = libnodave.openS7online(S7Online_accesspoint)
> ...



Denke nicht das das Problem ist. Wenn man sich den Source von "openS7online.c" anschaut, sieht man das der wert einfach ein Handle auf die Verbdinung ist, und diese dann auch mit Close geschlossen wird. Wieso sollte man dieses Handle auf 0 setzten müssen (wäre vielleicht schöner, sollte aber keine Probleme bereiten!)

Vieleicht sollte noch die Funktion SCP_get_errno in Libnodave eingebunden damit man die Fehlermeldung auslesen kann.
(Hups, hab grad gesehen wird ja verwendet, aber So wie Ich das sehe wird der Fehler nicht ausgewertet!)

Wenn Ich morgen mal Zeit habe, mache Ich mich mal an tests mit der S7Online Verbindung!


----------



## Jochen Kühner (11 Mai 2010)

*Probier mal*

Hab in der DLL mal die Fehlercodes von S7 Online noch reinprogrammiert...

Schau mal ob damit was anderes passiert...


----------



## bool (11 Mai 2010)

Jochen Kühner schrieb:


> Hab in der DLL mal die Fehlercodes von S7 Online noch reinprogrammiert...
> 
> Schau mal ob damit was anderes passiert...


 
Hab grad mal die libnodave.dll ausgetauscht, das Programm stürzt dann jedoch schon bevor die Form1 überhaupt geladen wird mit folgendem Windows Fehler ab:

Fehler beim Erstellen des Formulars. Weitere Informationen finden Sie in Exception.InnerException. Fehler: Die DLL "libnodave.dll": Das angegebene Modul wurde nicht gefunden. (Ausnahme von HRESULT: 0x8007007E) kann nicht geladen werden..

Die ursprüngliche libnodave welche ich aus dem libnodave 0.8.4.5 zip-file verwendet habe hat 124kb, die neue aus Deinem post 81kb.
Die von mir aktuell verwendete libnodave.net.dll ist die compilierte libnodave.net.cs welche ich von Dir bekommen habe um das Unicode-Problem der libnodave.daveStrerror(res) Auswertung in den Griff zu bekommen.

Ich habe mal die aktuell von mir verwendeten dll`s und die lib dem post angehängt.

Gruss,

bool


----------



## Jochen Kühner (11 Mai 2010)

*Jo*

Ja Ich weis das die viel kleiner ist.

Hab die auch mit VS2010 kompiliert, da das mit nmake bei mir nicht klappt.

Bringt es dir was wenn Ich dir den Source schicke das du in selber übersetzen kannst??

Also bei mir läufts mit meiner geänderten Dll


----------



## bool (11 Mai 2010)

Jochen Kühner schrieb:


> Ja Ich weis das die viel kleiner ist.
> 
> Hab die auch mit VS2010 kompiliert, da das mit nmake bei mir nicht klappt.
> 
> ...


 
mit nmake habe ich noch nichts gemacht, aber die letzte libnodave.net.cs welche Du mir gesedet hattest konnte ich mit dem c#-compiler (csc.exe) in die libnodave.net.dll verwandeln, ich nehme an das geht dann mit der Source für die libnodave.dll gleichermassen, oder liege ich da falsch?

Bezüglich meines "Handle wieder freigeben" Problemchens habe ich es mir erlaubt mal in die c# quelle des testS7online Konsolenprogramms zu spickeln und beim Verbindungsabbau fogenden Code gefunden:

dc.disconnectPLC();
} 
di.disconnectAdapter();
libnodave.closeS7online(fds.rfd);
GC.Collect();
GC.WaitForPendingFinalizers();

Console.WriteLine("Here we are");
 
Hier wird am Ende mit dem GarbageCollector nicht verwendeter Speicher wieder freigegeben. 
Gibt es auch so was für VB.NET?
Ist das vielleicht die Lösung für mein Problem?

Gruss,

bool


----------



## bool (11 Mai 2010)

bool schrieb:


> Hier wird am Ende mit dem GarbageCollector nicht verwendeter Speicher wieder freigegeben.
> Gibt es auch so was für VB.NET?
> Ist das vielleicht die Lösung für mein Problem?
> bool


 
Habs grad mit dem Garbage Collector probiert, hat leider keine Besserung gebracht.


----------



## Jochen Kühner (11 Mai 2010)

bool schrieb:


> mit nmake habe ich noch nichts gemacht, aber die letzte libnodave.net.cs welche Du mir gesedet hattest konnte ich mit dem c#-compiler (csc.exe) in die libnodave.net.dll verwandeln, ich nehme an das geht dann mit der Source für die libnodave.dll gleichermassen, oder liege ich da falsch?



Ja, da liegst du falsch! Sonst hätte Ich's auch geschaft ;-)

Habe aber jetzt größere Probleme, Habe vor 1h meinen Netlink-treiber unter Windows 7 geupdatet, und nun crashed LibNodave beim Zugriff auf S7Online (egal ob meine DLL oder die orginale!)

Scheiße!

(Ja, Ich weis, Step7 ist ja auch noch nicht für Win7 freigegeben!)


----------



## bool (11 Mai 2010)

Jochen Kühner schrieb:


> Ja, da liegst du falsch! Sonst hätte Ich's auch geschaft ;-)
> 
> Habe aber jetzt größere Probleme, Habe vor 1h meinen Netlink-treiber unter Windows 7 geupdatet, und nun crashed LibNodave beim Zugriff auf S7Online (egal ob meine DLL oder die orginale!)
> 
> ...


 
ups... da drücke ich Dir die Daumen, dass Du das wieder hin kriegst und das meine ich nicht nur im eigenen Interesse.

Meintest Du mit "nmake" eigentlich die "winmake.bat" im Stammverzeichnis des libnodave zip oder wie ist die offizielle Vorgehensweise zum compilieren der libnodave.dll?

Gruss,

bool


----------



## Jochen Kühner (11 Mai 2010)

bool schrieb:


> ups... da drücke ich Dir die Daumen, dass Du das wieder hin kriegst und das meine ich nicht nur im eigenen Interesse.
> 
> Meintest Du mit "nmake" eigentlich die "winmake.bat" im Stammverzeichnis des libnodave zip oder wie ist die offizielle Vorgehensweise zum compilieren der libnodave.dll?
> 
> ...



Eigendlich musst du vcwinmake verwenden (sowie ich das sehe) das andere ist für compilierung unter linux mit wine!

Wenn du das nutzt brauchst du nmake und das hab Ich, aber beim compilieren kommen bei mir lauter fehler. Ich hab mir ein VS2010 C++ DLL Projekt erstellt, die entsprechenden Sourcen reinkopiert, die Compiler und Linker Sachen angepasst und das Symbol BCCWIN definiert.

Weis nur nicht ob alles richtig ist, aber kompiliert habe ich es ja!


----------



## Jochen Kühner (11 Mai 2010)

*Nochmal Ich...*

Nebensächliches:

Windows 7 und die Netlink Treiber.

Mit dem neusten treiber von Helmholz, crash beim hinzufügen von Schnittstellen. Dann neusten treiber von Deltalogic verwendet (dachte eigendlich die beiden sind gleich (Version ist es auch)). Damit geht Step7 wieder aber Libnodave DLL crasht. Dann treiber von IBH installiert, Connection scheitert erst beim daveNewConnection aufruf.

Ohhh man....


----------



## Question_mark (11 Mai 2010)

*Wundert mich eigentlich nicht*

Hallo,



			
				Jochen Kühner schrieb:
			
		

> und nun crashed LibNodave beim Zugriff auf S7Online (egal ob meine DLL oder die orginale!)



Also mal erst einige Worte vorab : Ich schätze und achte die Leistung von Zottel mit der LibNoDave und auch Deine Bemühungen um den Protokoller und auch das Engagement von rudl. Das ist alles schön, um mal die Haussteuerung mit dem Rauf- und Runterfahren vom PC die Jalousien zu steuern. 
Aber wenn ich diesen Rotz ernsthaft in ein Angebot für meine Kunden einarbeiten würde, die würden mir bei der Auftragsverhandlung freundschaftlich auf die Schulter klopfen und mir zeigen, wo der Maurer das Loch gelassen hat.

Die Freds hier im Forum zu Problemen mit LibNoDave sind wohl recht vielfältig, da kommen einige hunderte zusammen und dominieren wohl ..

Aber ich bezahle lieber ein paar hundert Euro für eine kostenplichtige, aber funktionierende und zuverlässige Komponente, bevor ich viele Arbeitstunden für die Nichtfunktionalität von Freeware verschwende. Ich muss einfach meinem Kunden die Funktionalität garantieren.
Nur mal so zum Nachdenken, und bitte nicht böse sein wegen meiner vielleicht etwas harten Worte, aber ich sehe das auf Grund meiner Erfahrung etwas pragmatischer ...

Gruß

Question_mark


----------



## Jochen Kühner (11 Mai 2010)

Question_mark schrieb:


> Hallo,
> 
> 
> 
> ...



ich denke nicht das es als Problem anzusehen ist wenn dies nun unter Windows 7 crashed (wo es auch noch keine Offizielle Siemens Version, noch einen offiziellen Netlink Treiber gibt)

Und Ich habe die Netlink Bibliothek schon in einigen Anlagen Produktiv im Einsatz und noch nie Probleme gehabt! Auch habe Ich ja bei der Libnodave den Quelltext und kann nach Fehlern selbst suchen, wobei Ich bei einer ClosedSource Bibliothek immer auf den Hersteller und dessen Reaktionszeit angewiesen bin. 

Aber Ich weis auch nicht was dieser Punkt jetzt hier in diesem Thread soll, denke diese Diskussion wäre auch in einem Extra Thread besser aufgehoben!

Oder hat es was mit dem gefragten Problem zu tun?


----------



## bool (11 Mai 2010)

@Question_mark
Bitte beim Thema des Threads bleiben und kein pauschales Runtermachen, Danke.


----------



## Question_mark (12 Mai 2010)

*Pfft ..*

Hallo,



			
				Jochen Kühner schrieb:
			
		

> Nebensächliches:
> 
> Windows 7 und die Netlink Treiber.
> 
> Mit dem neusten treiber von Helmholz, crash beim hinzufügen von Schnittstellen. Dann neusten treiber von Deltalogic verwendet (dachte eigendlich die beiden sind gleich (Version ist es auch)). Damit geht Step7 wieder aber Libnodave DLL crasht. Dann treiber von IBH installiert, Connection scheitert erst beim daveNewConnection aufruf.



Vielen Dank für Deine Einschätzung, das die Funktionalität nur nebensächlich ist.



			
				bool schrieb:
			
		

> Bitte beim Thema des Threads bleiben und kein pauschales Runtermachen, Danke.



Aber gerne .. Wenn Du mit Kritik nicht umgehen kannst, halte einfach das Maul 

Gruß

Question_mark


----------



## Question_mark (12 Mai 2010)

*???*

Hallo,



			
				Jochen Kühner schrieb:
			
		

> Mit dem neusten treiber von Helmholz, crash beim hinzufügen von Schnittstellen. Dann neusten treiber von Deltalogic verwendet (dachte eigendlich die beiden sind gleich (Version ist es auch)). Damit geht Step7 wieder aber Libnodave DLL crasht. Dann treiber von IBH installiert, Connection scheitert erst beim daveNewConnection aufruf.



So langsam werde ich nachdenklich. Also alles an Treibern drin in Deinem Projekt. Also LibNoDave (ist ja Open Source), Treiber von Deltalogic, Helmholtz und IBH ...

Werden diese Treiber bei Deinem Projekt alle kostenlos mitgeliefert ? 

Ich werde mir das mal alles schnell bei Dir runterladen, bevor Dir ein paar der genannten Firmen den Arsch bis zu den Ohren aufreissen 

Gruß

Question_mark


----------



## Jochen Kühner (12 Mai 2010)

Question_mark schrieb:


> Hallo,
> 
> 
> 
> ...



Hääää???? Wieso sollten diese in meinem Projekt sein...

Ich habe diese Treiber bei mir installiert um zu sehen mit welchem der Netlink unter Windows 7 wieder zum funktionieren zu bringen ist...




			
				Question_mark schrieb:
			
		

> Aber gerne .. Wenn Du mit Kritik nicht umgehen kannst, halte einfach das Maul



Mir kommt es eher so vor als könntest du das nicht....


----------



## Question_mark (12 Mai 2010)

*Da kneift aber unser Jochen*

Hallo,



			
				Jochen Kühner schrieb:
			
		

> Mir kommt es eher so vor als könntest du das nicht....



Du hast hier im Forum in einigen Beiträgen um kritische und aber auch konstruktive Kritik und Anregungen zu Deinem Projekt regelrecht gebettelt. Du hast diese Kritik und auch Anregungen von mir bekommen und maulst jetzt  hier herum. Geh doch einfach mit dem User "bool" unter die Kuscheldecke und lass Dich von Ihm bewundern 

Gruß

Question_mark


----------



## Jochen Kühner (12 Mai 2010)

Question_mark schrieb:


> Hallo,
> 
> Vielen Dank für Deine Einschätzung, das die Funktionalität nur nebensächlich ist.
> 
> Question_mark



Das Nebensächliche stand hier, da dies eigendlich nichts mit der Thread Topic zu tun hat.

Wollte nur erwähnen das eben das meiste unter Win7 eben noch nicht geht, und dies hat nix mit LibNoDave zu tun wenn die Treiber nicht laufen!


----------



## Jochen Kühner (12 Mai 2010)

*Andere Version...*

Hier nochmal ne anderst kompilierte Version.

Probiers mal damit.


----------



## Zottel (12 Mai 2010)

Question_mark schrieb:


> ...Das ist alles schön, um mal die Haussteuerung mit dem Rauf- und Runterfahren vom PC die Jalousien zu steuern.
> Aber wenn ich diesen Rotz ernsthaft in ein Angebot für meine Kunden einarbeiten würde, die würden mir bei der Auftragsverhandlung freundschaftlich auf die Schulter klopfen und mir zeigen, wo der Maurer das Loch gelassen hat.


Jooh...
Da es ausser Libnodave nicht so viele Open Source Lösungen gibt, behaupte ich mal frech, daß fast der ganze "Rest" des Forums Probleme behandelt, die Leute mit Lösungen von "professionellen" Anbietern haben. Ich meine jetzt noch nicht einmal nur Kommunikationsbibliotheken sondern die gesamte Automatisierungstechnik, Hard- und Firmware eingeschlossen.
Und wie kann es sein, daß viele Anwender eher hier Hilfe finden als bei dem "professionellen" Support des Herstellers?



Question_mark schrieb:


> Die Freds hier im Forum zu Problemen mit LibNoDave sind wohl recht vielfältig, da kommen einige hunderte zusammen und dominieren wohl ..



Dominieren was? Das Forum? Den Themenbereich SPS-PC-Kommunikation? Letzteres mag vielleicht sein.

Zur Menge tragen mindestens 3 Kategorien von Threads bei, die es bei anderen Produkten gar nicht gibt:

- Selber kompilieren. Kann man ohne Quellcode nicht. Ist ja bei "professionellen" Produkten nicht nötig. Ist bei Libnodave auch nicht nötig. Aber wer mag und kann, kann. Bitte sehr! Wer aber dabei Hilfe braucht: Es gibt ein README.compiling, das muß reichen.

- Leute, die Libnodave ausprobieren wollen, die aber nicht wissen, wie sie eine DLL einbinden, wie sie eine Header-Datei benutzen, die die Speicheraufteilung einer S7 nicht verstehen, die nicht vorhandene Datenbausteine lesen wollen, etc. Ich denke, daß der Großteil dieser Leute durchaus um die Grenzen der eigenen Fähigkeiten weiß. Daher würden sie sich scheuen, einige hundert Euro zu investieren. Aber mit Libnodave ist der Versuch kostenlos.

- Der dritte Punkt ist meine Schuld: Ich bezeichne die Nutzung von s7online als "experimentell", ich rate davon ab, es gibt keinen Grund es zu nutzen außer mit CP5x1x. Es ist extrem "buggy". Ich selbst brauche es nicht und habe es daher niemals verbessert. Aus heutiger Sicht hätte ich s7online vielleicht besser nie veröffentlicht.



Question_mark schrieb:


> Aber ich bezahle lieber ein paar hundert Euro für eine kostenplichtige, aber funktionierende und zuverlässige Komponente, bevor ich viele Arbeitstunden für die Nichtfunktionalität von Freeware verschwende.


Natürlich, WENN das die Alternativen sind.
Ich habe auch schon "viele Arbeitstunden" damit verschwendet, die Grenzen oder Unzulänglichkeiten sogenannter "funktionierender und zuverlässiger Komponenten" zu erkunden. Ich glaube, da gibt es auch einen psychologischen Faktor:
Wenn das Produkt einen klangvollen Namen hat, sucht der Neuling (Neuling in Bezug auf das Produkt, nicht auf das Fachgebiet) den Fehler zuerst bei sich. Wenn es "Open Source", Freeware, kostenlos, namenlos ist, tendiert er eher dazu, Schwierigkeiten dem Produkt anzulasten.



			
				Question_mark schrieb:
			
		

> ...o langsam werde ich nachdenklich. Also alles an Treibern drin in Deinem  Projekt. Also LibNoDave (ist ja Open Source), Treiber von Deltalogic,  Helmholtz und IBH ...


Nur um es klarzustellen: Libnodave benötigt keine Treiber von Deltalogic,  Helmholtz und IBH. Es kann mit den diversen Net-Link-Varianten deren PC-seitige Protokolle sprechen. Das ist dann auch zuverlässig. 
Es KANN aber auch über s7online diese Treiber verwenden. Davon rate ich ab, weil eben die s7online-Anbindung fehlerhaft ist.


----------



## Zottel (12 Mai 2010)

Jochen Kühner schrieb:


> Eigendlich musst du vcwinmake verwenden (sowie ich das sehe) das andere ist für compilierung unter linux mit wine!


Makefile.VC
Makefile.VC.WINE
Sind die Makefiles.
vcwinmake ruft nmake mit Makefile.VC auf.

Du kannst anpassen, welches du willst, aber bei Makefile.VC sollte es einfach weniger Arbeit sein...


Jochen Kühner schrieb:


> Wenn du das nutzt brauchst du nmake und das hab Ich...


Das ist ja schon was...


Jochen Kühner schrieb:


> ..., aber beim compilieren kommen bei mir lauter fehler.


Meistens wird etwas nicht gefunden. Daran können Dateipfade in der Batch-Datei, im Makefile oder Umgebungsvariablen schuld sein. Und:
Libnodave ist C, nicht C++!!!!


Jochen Kühner schrieb:


> Ich hab mir ein VS2010 C++ DLL Projekt erstellt, die entsprechenden Sourcen reinkopiert, die Compiler und Linker Sachen angepasst und das Symbol BCCWIN definiert.


Nichts dagegen einzuwenden. Mußt du halt nochmal machen, wenn sich irgendwann das makefile ändert...


Jochen Kühner schrieb:


> Weis nur nicht ob alles richtig ist, aber kompiliert habe ich es ja!


Der ultimative Test: Wenn du nichts geändert hast, sollte die resultierende Libnodave.dll sollte genauso lang sein, wie die runtergeladene.


----------



## bool (12 Mai 2010)

Jochen Kühner schrieb:


> Hier nochmal ne anderst kompilierte Version.
> 
> Probiers mal damit.


 

Hab grad die neue dll verwendet, doch dann bringt u.a. die Funktion dc.connectPLC schon beim Connect via ISO on TCP die Rückmeldung -1.
Die prinzipielle Verbindung beim S7Online bringt zwar keine Fehler, jedoch geht nun schon beim ersten Verbinden die dc.execReadRequest auf -128.

Gruss,

bool


----------



## Jochen Kühner (12 Mai 2010)

*Soo, nun endlich...*

So, habs nun mit Zottels Batch kompiliert bekommen (musste noch vcvarsall.bat in die winmake.bat aufnehmen das alle enviroment variablen gesetzt sind!)

Probiers mal damit, wenn die auch nicht geht, weis ich im Moment auch nicht weiter.


----------



## Jochen Kühner (12 Mai 2010)

*So...*

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!


----------



## bool (12 Mai 2010)

Jochen Kühner schrieb:


> So, habs nun mit Zottels Batch kompiliert bekommen (musste noch vcvarsall.bat in die winmake.bat aufnehmen das alle enviroment variablen gesetzt sind!)
> 
> Probiers mal damit, wenn die auch nicht geht, weis ich im Moment auch nicht weiter.


 
Die ISO on TCP Verbindung und die erste Verbindung mit S7Online laufen wieder wie zuvor, doch leider gibt es ab der zweiten Verbindung beim Lesen noch immer eine -128 als Ergebnis.

Wie zuvor ist zu beobachten, dass vor der zweiten Verbindung 
fds.rfd noch immer = 1 ist und die Funktion ohne Verzögerung durchläuft und auch danach ist fds.rfd = 1. Beim ersten Verbinden braucht sie normalerweise immer ein paar Sekunden um die Verbindung aufzubauen.

Du meintest, dass Du die Fehlercodes in die DL Limplementiert hast, doch wie kann ich diese Fehlercodes von openS7online auslesen? Die Funktion gibt ja nur das fds.rfd zurück.


Gruss,

bool


----------



## bool (12 Mai 2010)

Jochen Kühner schrieb:


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


 

ok, werde ich probieren.

Hatte diesen post leider zu spät gesehen und bereits selbst gepostet.

Gruss,

bool


----------



## bool (13 Mai 2010)

Jochen Kühner schrieb:


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


 
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 (13 Mai 2010)

*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 (13 Mai 2010)

bool schrieb:


> ,
> 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 (13 Mai 2010)

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 (13 Mai 2010)

bool schrieb:


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




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 (13 Mai 2010)

*...*

Hallo,



			
				Jochen Kühner schrieb:
			
		

> 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 (28 Mai 2010)

*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 (30 Mai 2010)

Jochen Kühner schrieb:


> @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 (30 Mai 2010)

*jo...*



bool schrieb:


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



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 (31 Mai 2010)

*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 (18 Juni 2010)

*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 (18 Juni 2010)

bool schrieb:


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



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 (18 Juni 2010)

Jochen Kühner schrieb:


> 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 (18 Juni 2010)

bool schrieb:


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



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 (22 Juni 2010)

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 (22 Juni 2010)

bool schrieb:


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



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 (22 Juni 2010)

*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 (22 Juni 2010)

*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 (22 Juni 2010)

Jochen Kühner schrieb:


> 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 (22 Juni 2010)

bool schrieb:


> Hallo Jochen,
> 
> Danke für die (wie gewohnt) schnelle und informative Rückmeldung.
> 
> ...



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!


----------



## bool (25 Juni 2010)

Jochen Kühner schrieb:


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


 
Bin leider dieser Tage noch nicht dazu gekommen das näher unter die Lupe zu nehmen. Damit ich die Connection Lib starten kann muss ich vermutlich auch erst noch eine VM mit C#.NET 2010 Express auufsetzen, richtig? Ich arbeite momentan noch mit Visual Studio 2008 Expresss (hauptsächlich davon VB.Net) und konnte die Connection Lib vor ein paar Tagen wegen diverser bei mir fehlender Verweise nicht starten.

Ab Sonntag bin ich leider bis Freitag  nächste Woche uwegs, so dass ich frühestens ab Samstag nächste Woche dazu kommen werde.
Solange Dir/Euch auf jeden Fall noch viel Erfolg mit Euren anderen Vorhaben/Projekten.

Gruss,

bool


----------

