Fehler in libnodave oder in meiner Version...

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich habe ein Problem in meiner Version von libnodave (glaube Ich zumindest.)

Bin von jemandem angesprochen worden das die Kommunkation zu einer CPU 313C mit CP nicht Funktioniert.

Der CP hat die MPI Adresse 4, die CPU die 2.

Habe von ihm auch die Logfiles bekommen werde jedoch daraus nicht schlau.

Wenn Ich das Logfile von Visual Studio anschaue, siehts so aus als würde Ich auf die Connection Anfrage (zur MPI2) keine Antwort bekommen, wenn ich aber das Wireshark Logfile anschaue sieht alles richtig aus.

Wenn er zur MPI4 Connecten will sieht alles richtig aus (bringt aber nichts, da er ja nicht mit dem CP sprechen will)

Vielleicht sieht ja einer was da falsch läuft, aber in Wireshark sieht meiner Meinung nach alles richtig aus...

 

[nekron]

Moin Moin,

Was für ein CP und was für ne Verbindung ?

Einen 342-5 haette ich da, eine Ethernet CP auch noch da ...

Gruß
Michael

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Moin,

Was für ein CP und was für ne Verbindung ?

Einen 342-5 haette ich da, eine Ethernet CP auch noch da ...

Gruß
Michael

Verbindung ist TCP/IP, rest der Hardware weiss Ich nicht (ist ja nicht meine). Aber mit libnodave direkt klappt die Verbindung, nur mit meiner Version über .NET nicht.

Ich habe aber auch einen Auszug von der Verbindung über libnodave, und das erste telegramm (COTP) ist genau gleich, genauso wie die Antwort darauf, welche jedoch bei mir nicht anzukommen scheint...

Ich verstehe dann aber nicht warum die Antwort der MPI Adresse 4 ankommt....

Ich blicks einfach nich...

 

[Thomas_v2.1]

Warum kann man denn bei einer TCP/IP Verbindung überhaupt die MPI-Adresse angeben? Solange du kein Routing machen willst ist diese später im Netzwerkverkehr gar nicht notwendig.

Bei Aufzeichnung 02 sieht es so aus, als ob der PC nach dem ISO-Connect nicht den nächsten Schritt macht und die S7-Verbindung aufbaut. Im CP scheint es da wohl einen Timeout zu geben, nachdem die Verbindung dann getrennt wird.
Aufzeichnung 04 ist sehr putzig. Aber wenn das nackte libnodave funktioniert, ist ja eigentlich klar wo der Fehler liegt.
Ich habe ein paar Wireshark Logfiles zu einer 313C mit Ethernet CP, da sind keine Besonderheiten zu erkennen.

 

[Jochen Kühner]

Warum kann man denn bei einer TCP/IP Verbindung überhaupt die MPI-Adresse angeben? Solange du kein Routing machen willst ist diese später im Netzwerkverkehr gar nicht notwendig.

Bei Aufzeichnung 02 sieht es so aus, als ob der PC nach dem ISO-Connect nicht den nächsten Schritt macht und die S7-Verbindung aufbaut. Im CP scheint es da wohl einen Timeout zu geben, nachdem die Verbindung dann getrennt wird.
Aufzeichnung 04 ist sehr putzig. Aber wenn das nackte libnodave funktioniert, ist ja eigentlich klar wo der Fehler liegt.
Ich habe ein paar Wireshark Logfiles zu einer 313C mit Ethernet CP, da sind keine Besonderheiten zu erkennen.

Sorry, meine Auch gar nicht die MPI Adresse, er hat Slot 4 eingegeben...
So wies es aussieht antwortet die CPU ja bei beiden requests richtig, aber auch den mit Slot 2 reagiere Ich nicht...

Wobei Ich aber keinen fehler in der nodave.c entdecken kann der das bewirkt. Es wird ja nach dem Step 1 nur die länge ausgewertet, ob 22 Bytes zurück kommen, und dann sollte der NegotiatePDULength passieren, tuts aber nich...

Er sagt aber, mit einer 315/2DP häts bei ihm schon Funktioniert...

kann jemand einen fehler in der nodave.c entdecken?

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast du an der nodave.c denn außer für das Routing und der S7online Schnittstelle etwas geändert?

Du könntest testweise die von Zottel mitgelieferten Testprogramme so umschreiben dass diese die libnodave Funktionen aus deiner dll laden, denn die mitgelieferten fertig übersetzten sind ja statisch gelinkt. Dann kannst du den Fehler schonmal eingrenzen, und es können andere Leute den Fehler damit evtl. einfacher nachstellen.

 

[Jochen Kühner]

Habs gefunden, er hatte den Timeout einfach zu niedrig eingestellt... Dadurch ist select zurückgekehrt, bevor die Daten da waren!