DotNetSiemensPLCToolBoxLibrary (LibNoDave) Zugriff auf Dual-Port RAM / FB15

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

TSAPs??

Das ist sozusagen die Zieladresse auf ISO-Ebene. Wenn du in Wireshark den Filter auf cotp.type == 0x0e einstellst, bekommst du die Anfrage zu sehen.

Die meisten Tests, vor allem die NC Up-Downloads sowie PI-Dienste hab ich an der selben NCU (Teststand 840d sl) durchgeführt.


Würde ja heißen, dass "testISO_TCP.exe 10.172.26.233 --slot=4" sich nicht mit Slot 4 verbindet.

Das stimmt, es wird weiterhin slot=2 verwendet.

Stelle den Slot mal direkt in der testISO_TCP.c ein, an der Stelle:

dc =daveNewConnection(di,2,0,useSlot); // insert your rack and slot here

auf:

dc =daveNewConnection(di,2,0,4); // insert your rack and slot here



Edit:
oder den slot vor der IP angeben:
testISO_TCP.exe --slot=4 10.172.26.233

 

[Hans54216]

C:\Users\1\Documents\_löschen\_LibNoDave\libnodave-0.8.5.1-nc>testISO_TCP.exe --slot=4 10.172.26.233
IF1 error in daveConnectPLC() step 1. retrying...
IF1 error in daveConnectPLC() step 1. retrying...
IF1 error in daveConnectPLC() step 1. retrying...
Couldn't connect to PLC.
 Please make sure you use the -2 option with a CP243 but not with CPs 343 or 443
.

In Wireshark sieht es jetzt genau so aus wie mit der geänderten Lib von Jochen.
Nodave bekommt keine Verbindung zur NC.

Anhang anzeigen testISO_TCP_NC_ConnectionError.rar

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist wahrscheinlich noch das Problem mit der TPDU und S7-PDU Größe.

Ändere mal in der nodave.c Zeile 3812
von:

	0xC0,1,0x9,

auf:

	0xC0,1,0xa,

Und Zeile 1544
von:

	dc->maxPDUlength=1920;				// assume an (unreal?) maximum

auf:

	dc->maxPDUlength=960;

 

[Hans54216]

Das ist wahrscheinlich noch das Problem mit der TPDU und S7-PDU Größe.

Ändere mal in der nodave.c Zeile 3812
von:

    0xC0,1,0x9,

auf:

    0xC0,1,0xa,

Soll dies in "uc b4R2[]={ // for routing" auch auf 0xa geändert werden?

C:\Users\1\Documents\_löschen\_LibNoDave\libnodave-0.8.5.1-nc>testISO_TCP.exe --slot=4 10.172.26.233
Connected.
Starte PutNC Program...
davePutNCProgram: tot_len=0
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: Daten sind gesendet, gehe zu 'End Download'
davePutNCProgram: Sende End download...
davePutNCProgram: End download, res=0
davePutNCProgram: End download, Fehler Parameter: p2.param[5]=0xbf
davePutNCProgram: End download, Fehler Parameter: p2.param[6]=0x04
davePutNCProgram res=-128
Finished.

Anhang anzeigen testISO_TCP_NC_File_Download2.rar

Programm ist nach dem Download auf der NC vorhanden.

 

[Thomas_v2.1]

Ja, das müsste dann auch an anderen Stellen geändert werden.

D.h. die Datei konntest du jetzt erfolgreich hochladen?

Wenn du jetzt noch in meiner Funktion in der nodave.c die Zeile 7599 von:

                    if (p2.param[5] == 0xbf && p2.param[6] == 0x05) {

auf

                    if (p2.param[5] == 0xbf && p2.param[6] == 0x04) {

änderst, sollte es auch keine Fehlermeldung mehr geben.

Dann ist zu prüfen ob und wie das bei großen Dateien funktioniert.

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist wahrscheinlich noch das Problem mit der TPDU und S7-PDU Größe.

Ändere mal in der nodave.c Zeile 3812
von:

    0xC0,1,0x9,

auf:

    0xC0,1,0xa,

Und Zeile 1544
von:

    dc->maxPDUlength=1920;                // assume an (unreal?) maximum

auf:

    dc->maxPDUlength=960;

@Thomas: muß Ich das bei mir umbauen? Oder ist das nur zum testen?

 

[Thomas_v2.1]

Vom Prinzip her sollte es eigentlich auch so wie jetzt funktionieren. Wenn die NC keine 1920er PDUs mag, könnte sie den Wert ja beim Aushandeln verringern. Das macht sie aber nicht, sondern beendet die Verbindung sofort. Wenn die NC kein fragmentieren von TPDUs unterstützt, könnte sie ja bei einer vorgeschlagenen TPDU-Größe von 512 die S7-PDU auf 480 festsetzen.
Ich würde zumindest die TPDU-Große in der Anfrage entsprechend hochsetzen (auf 1024) und die S7-PDU auf max. 960 in der Anfrage. Ich habe auch noch kein Siemens-Gerät gesehen, was mehr als 960er PDUs unterstützt - aber ich kenne auch nicht alle Siemens Geräte. Vielleicht ist das in der geheimen Spezifikation auch auf max. 960 festgelegt und die NC schmeißt einen zurecht raus, wer weiß.

 

[Thomas_v2.1]

Vielleicht ist das auch einfach eine NC Spezialität.
Denn wenn er sich mit den gleichen Verbindungsparametern zur SPS (Rack=0, Slot=2) verbindet, akzeptiert sie diesen Wert, bzw. gibt 240 Bytes PDU beim Aushandeln zurück.
Wenn er sich hingegen zur NC (Rack=0,Slot=4) verbindet, schmeißt sie ihn mit den gleichen Daten raus.

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

D.h. nun? Es wäre doch besser Ich ändere das, dann Funktionierts mit den PLCs und auch mit der NC, oder?

 

[Hans54216]

Test mit einem großen Download.

C:\Users\1\Documents\_löschen\_LibNoDave\libnodave-0.8.5.1-nc>testISO_TCP.exe --
slot=4 10.172.26.233
Connected.
Starte PutNC Program...
davePutNCProgram: tot_len=4133
davePutNCProgram: unackcount=0, warte auf Antwort von NC um fortzusetzen...
davePutNCProgram: in continue response, falscher Aufbau der Antwort (p2.param[5]
 = 63). Exit!
davePutNCProgram res=-128
Finished.

Anhang anzeigen testISO_TCP_NC_Big_File_Download1.rar

 

[Thomas_v2.1]

Ändere mal die gesamte if-Bedingung Zeile 7564/7565 auf diese eine Zeile:

                        if (p2.param[5] == 0x3f && p2.param[6] == 0x03 && p2.dlen == 6) {

Dann sollte eine Datei von der Größe zumindest fuktionieren.

In deinen anderen Downloads wird dann so wie es aussieht gelegentlich schon nach 8 PDUs auf eine Fortsetzungsanweisung gewartet. Vermutlich wird es ab einer Datei mit dieser Größe dann haken. Falls es dazu kommt, dann kannst du direkt mal testen was passiert wenn du in der nachfolgenden Zeile 7565:

unackcount = 8; /* Anzahl an Paketen die gesendet werden dürfen, ohne auf ein Ack zu warten */

schreibst. Falls die Anzahl 8 nicht übermittelt wird sondern wie auch immer vereinbart wird.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

D.h. nun? Es wäre doch besser Ich ändere das, dann Funktionierts mit den PLCs und auch mit der NC, oder?

Ich würde es so machen (TPDU=1024 und S7-PDU=960). Ich wüsste nichts was für die bisherigen Werte spricht.
WinCC verwendet TPDU=1024 und S7-PDU=480, dass ein Kommunikationspartner die 960 beherrscht sehe ich bei der NC das erste mal, die 400er machen alle nur 480.

 

[Hans54216]

Ändere mal die gesamte if-Bedingung Zeile 7564/7565 auf diese eine Zeile:

                        if (p2.param[5] == 0x3f && p2.param[6] == 0x03 && p2.dlen == 6) {

Dann sollte eine Datei von der Größe zumindest fuktionieren.

In deinen anderen Downloads wird dann so wie es aussieht gelegentlich schon nach 8 PDUs auf eine Fortsetzungsanweisung gewartet. Vermutlich wird es ab einer Datei mit dieser Größe dann haken. Falls es dazu kommt, dann kannst du direkt mal testen was passiert wenn du in der nachfolgenden Zeile 7565:

unackcount = 8; /* Anzahl an Paketen die gesendet werden dürfen, ohne auf ein Ack zu warten */

schreibst. Falls die Anzahl 8 nicht übermittelt wird sondern wie auch immer vereinbart wird.

Mit den beiden Änderungen kann ich nun auch sehr große Dateien übertragen.

Anhang anzeigen testISO_TCP_NC_Big_File_DownloadX.rar

 

[Hans54216]

Habs gerade über die lib vom Jochen probiert. Funktioniert genauso.

Danke!!!

Noch zwei Dinge zum Wireshark.
1. Beim Antworten der NC auf den "NC Push" kommt "Unknown subfunc: 0x03 "
2. Einstellen eines Filters:
- Wird der Filter vollständig eingegeben und mit "Enter" bestätigt -> alles Gut (Filter wird übernommen und Hintergrund wird grün)
- Wird der Filter anhand der Auswahl selektiert und mit "Enter" bestätigt -> Filter wird eingetragen aber nicht aktiv, Hintergrund wird grün (man muss nun nochmals in die Filterzeile klicken und mit "Enter" bestätigen)

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Noch zwei Dinge zum Wireshark.
1. Beim Antworten der NC auf den "NC Push" kommt "Unknown subfunc: 0x03 "
2. Einstellen eines Filters:
- Wird der Filter vollständig eingegeben und mit "Enter" bestätigt -> alles Gut (Filter wird übernommen und Hintergrund wird grün)
- Wird der Filter anhand der Auswahl selektiert und mit "Enter" bestätigt -> Filter wird eingetragen aber nicht aktiv, Hintergrund wird grün (man muss nun nochmals in die Filterzeile klicken und mit "Enter" bestätigen)

1. Habe ich drin. Ich habe es als "Continue download" bezeichnet. In der Version die ich dir habe zukommen lassen habe aber noch nicht.
2. Das habe ich auch schon gemerkt. Ich weiß nicht ob das einen Grund hat, dass es so gelöst wurde. Evtl. weil das Filtern bei großen Dateien schonmal etwas länger dauern kann, und man darum die Auswahl nochmal bestätigen muss? Um den GUI-Teil von Wireshark habe ich mich aber noch nie gekümmert, das ist vollständig vom Netzwerkteil abgetrennt programmiert. Darum ließ sich da auch bei der Umstellung von Gtk zu Qt relativ einfach ein neues Userinterface drüberstülpen.


Die Frage ist aber noch: Woher kommt die Anzahl 8?

Beim ersten "Continue download" kommen in den beiden Byte im Datenteil 0x12, 0x00 zurück. Das wäre 0x12=18 dez. Das funktioniert aber scheinbar nicht. Oder warum hast du das direkt auf die Konstante 8 geändert?
Danach kommt immer 0x08, 0x00. Das würde dann schön mit der 8 hinkommen und sollte dann auch funktionieren.
Da wäre meine Interpretation: Die NC sagt damit: Schick mit weitere 8 PDUs.
Aber was soll dann die 18? Oder die 8 in Telegrammen stimmt nur rein zufällig mit der Anzahl überein, und das bedeutet etwas ganz anderes.

Das sollten wir schon noch herausbekommen, andernfalls funktioniert es dann an einer anderen Anlage nicht. Außerdem möchte ich in Wireshark das Feld gerne bezeichnen, und evtl. ist das bei anderen Telegrammtypen auch so.

 

[Hans54216]

Die Frage ist aber noch: Woher kommt die Anzahl 8?

Beim ersten "Continue download" kommen in den beiden Byte im Datenteil 0x12, 0x00 zurück. Das wäre 0x12=18 dez. Das funktioniert aber scheinbar nicht. Oder warum hast du das direkt auf die Konstante 8 geändert?

Ohne die Änderung auf die Konstante 8 hat`s nicht funktioniert.

Laut testIso_DownloadHistory.txt hab ich zunächst 3 Downloads ohne die feste Konstante 8 durchgeführt.
- Beim ersten Download (kleine Datei) hats auch funktioniert.
- Bei den nächsten beiden (größere Datei) hat der "End download" nicht funktioniert. Damit war auch keine Datei auf der Steuerung.

Anschließend die Variable fest auf 8 gesetzt. -> Selbst riesige Downloads funktionieren.

Danach kommt immer 0x08, 0x00. Das würde dann schön mit der 8 hinkommen und sollte dann auch funktionieren.
Da wäre meine Interpretation: Die NC sagt damit: Schick mit weitere 8 PDUs.
Aber was soll dann die 18? Oder die 8 in Telegrammen stimmt nur rein zufällig mit der Anzahl überein, und das bedeutet etwas ganz anderes.

Das sollten wir schon noch herausbekommen, andernfalls funktioniert es dann an einer anderen Anlage nicht. Außerdem möchte ich in Wireshark das Feld gerne bezeichnen, und evtl. ist das bei anderen Telegrammtypen auch so.

Woher die 8 kommt weiß ich nicht.

 

[Thomas_v2.1]

Ja, wenn ich den Wert aus der Anwort der NC auswerte, steht da, warum auch immer, in der ersten Antwort eine 18. D.h. ich erwarte dann erst nach 18 PDUs eine Fortsetz-Anweisung von der NC, die hat aber schon eins zu viel geschickt, d.h. es steht im Empfangspuffer ein unerwartetes Telegramm.

Wenn diese einmalige 18 nicht wäre, würde alles schön zusammenpassen. Jetzt kommt: 1, 18, 8, 8, 8, 8, 8, ... usw.

Hast du Zugang zu einem anderen Typ NC, die sich evtl. anders verhält?

 

[Hans54216]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast du Zugang zu einem anderen Typ NC, die sich evtl. anders verhält?

Hab jetzt mal verschiedene NC-Versionen getestet.

Anhang anzeigen testISO_TCP_NC_File_unackcountTest.rar

Bei v2.6 - v4.5 kommt 1, 18, 8, 8, 8, ... -> Fehlermeldung, es wird nur der Ordner angelegt (bei "v4.5 HF2 SP4" kommt auch die Fehlermeldung, die Datei ist aber auf der Steuerung )
Bei v4.7 kommt 1, 10, 8, 8, ... -> funktioniert

 

[Thomas_v2.1]

D.h. bei den Tests hast du das Festsetzen von unackount auf 8 wieder deaktiviert, also übernahme aus dem NC-Telegramm?

So wie es bei v4.7 ist hätte ich das auch erwartet. Aber wenn man bei dieser Version den Wert auf 8 festsetzen würde, dann würde es damit auch nicht funktionieren, weil (wahrscheinlich) nach 8 Telegrammen von der NC noch nichts zurückkommt.

 

[Hans54216]

D.h. bei den Tests hast du das Festsetzen von unackount auf 8 wieder deaktiviert, also übernahme aus dem NC-Telegramm?

Richtig.

So wie es bei v4.7 ist hätte ich das auch erwartet. Aber wenn man bei dieser Version den Wert auf 8 festsetzen würde, dann würde es damit auch nicht funktionieren, weil (wahrscheinlich) nach 8 Telegrammen von der NC noch nichts zurückkommt.

unackount fest auf 8 gesetzt: funktioniert auch mit v4.7

Anhang anzeigen testISO_TCP_NC_File_unackcount8Test.rar