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

Zuviel Werbung?
-> Hier kostenlos registrieren
Das heißt es wird ein "End Download" geschickt? Dann wird eigentlich nur noch auf eine Antwort von der NC gewartet, und diese ausgewertet. Wenn keine Antwort kommt, sollte es zumindest einen Timeout geben.

Bau dir doch ein paar LOG-Ausgaben ein, das ist einfacher als da den Debugger anzuklemmen (was wegen der Kommunikation eh bescheiden funktioniert).
 
Das heißt es wird ein "End Download" geschickt? Dann wird eigentlich nur noch auf eine Antwort von der NC gewartet, und diese ausgewertet. Wenn keine Antwort kommt, sollte es zumindest einen Timeout geben..

Es wird kein "End Download" geschickt. So wie ich gerade feststellte wird auch kein "Push" geschickt.

Durch die Änderung wird ja jetzt deine Funktion "_daveSendTCP" verwendet.
Diese setzt ja noch auf die variablen "TPDUsize" und "partPos" aus der Struktur.

Ist dort vielleicht der Fehler?

Anhang anzeigen dave_NC_File_Download4.rar
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Na wie sieht denn deine _daveSendTCP aus?

Wie gesagt, bei der libnodave Variante die Jochen verwendet, sind etliche Fehlerkorrekturen von der originalen libnodave nicht enthalten.

In der dave_NC_File_Download3 aus deinem letzten Anhang gab es doch ein "Push", dann hat sich bei dir jetzt schon wieder etwas anderes geändert wenn es jetzt nicht mehr vorhanden ist.

Wenn ich bei meiner Variante (Basis libnodave 0.8.5.1 = letzte Version) die Abfragen für die Antworten der NC auskommentiere, läuft der Download (in eine SPS) so durch, d.h. es werden zumindest alle Telegramme passend rausgeschickt.

Ich würde mir einfach an mehreren Stellen Log-Ausgaben oder printf einbauen, dann sieht man doch sofort wo es hakt.
 
Ändere auch mal diese Zeile
Code:
while (tot_len > 0) {
falls tot_len negativ werden sollte (was normal nicht sein sollte). Oder lass dir tot_len mit printf ausgeben.
 
In "davePutNCProgram" verwendest du ja die Variable int tot_len.

In "_daveSendTCP" mischst du die Verwendung von "int totLen" und "tot_len"(Weiß jedoch nicht wo diese Deklariert ist).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kannst du in beiden Funktionen ändern, aber ich glaube nicht dass es daran liegt. Denn bei dir hat es doch schonmal bis zum 1. Push funktioniert.
Wenn du dein _daveSendTCP auf Basis von Jochens Funktionen erstellt hast, dürfte dort der Teil mit tot_len usw. überhaupt nicht vorhanden sein. Der Teil dient dazu, wenn die TPDU < S7-PDU die S7-PDU zu fragmentieren. Wenn ich das richtig sehe, ist bei dir TPDU=1024 und S7-PDU=960, das sollte also alles ohne fragmentieren übertragen werden können.

Füge in der putNCProgramm an den entsprechenden Stellen ein:
LOG1("bin hier usw\n");
ein, und sieh dir an bis wohin ausgegeben wird. Und den debug-Level so erhöhen, dass auch alles ausgegeben wird.

Ich könnte mir ja einen NC-Simulator programmieren der sich so verhält wie eine NC um daran zu testen, aber ich weiß eben noch nicht alles genau. Es bleiben aber nicht mehr viele Felder übrig in denen sich relevante Daten verstauen lassen.
 
davePutNCProgram: unackcount = 1
davePutNCProgram: do_down_pa[9] = 0
_daveSendTCP: totLen = 119
_daveSendTCP: totLen = 119
_daveSendTCP: totLen = 119
.....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kannst du in beiden Funktionen ändern, aber ich glaube nicht dass es daran liegt. Denn bei dir hat es doch schonmal bis zum 1. Push funktioniert.
Wenn du dein _daveSendTCP auf Basis von Jochens Funktionen erstellt hast, dürfte dort der Teil mit tot_len usw. überhaupt nicht vorhanden sein. Der Teil dient dazu, wenn die TPDU < S7-PDU die S7-PDU zu fragmentieren. Wenn ich das richtig sehe, ist bei dir TPDU=1024 und S7-PDU=960, das sollte also alles ohne fragmentieren übertragen werden können.

Bei "PDU senden mit Warten auf Antwort von NC" wird ein "NC Push" erzeugt.

Mit "_daveSendTCP" (/* Sendet eine PDU, ohne auf Antwort zu warten */) funkitioniert es nicht.

Die Funktion "_daveSendTCP" ist so, wie du sie geschrieben hast. Ich hab lediglich in der "struct _daveConnection" die beiden Variablen hinzugefügt.
 
Kannst du die normale libnodave übersetzen? Dann hänge ich gleich mal mein Arbeitsverzeichnis an. Nicht dass wir hier über verschiedene Dinge reden.
Weiß nicht genau was du meinst.

Hab gerade die nodave.c + nodave.h von "libnodave-0.8.5" in den Ordner vom Jochen kopiert. Beim Übersetzen kommt nun dieser Output:

2016-05-13 18_08_09-C__Windows_system32_cmd.exe.png
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hänge dir mal meine Version an. Diese Datei an beliebiger Stelle entpacken.
Wenn du das Microsoft Visual Studio installiert hast, startest du die Eingabeaufforderung für das VS command Prompt (z.B. "VS2013 x86 Native Tools Command Prompt" bei VS2013).
Auf der Konsole navigierst du dann in den Ordner in den du mein zip entpackt hast, und gibst:

nmake -f makefile.vc

ein. Dann sollte alles ordnungsgemäß kompiliert werden.
Mein Beispiel habe ich einfach mal in die testISO_TCP.c eingebaut. Das ist dann ein Download der Daten aus deinem letzten Beispiel.
Aufrufen kannst du das Programm ebenfalls über die Eingabeaufforderung mit:

testISO_TCP.exe 192.168.1.40

Als Parameter musst du die IP-Adresse übergeben. Ohne weitere Angabe wird rack=0 und slot=2 verwendet. Mit dem Parameter --slot=3 könntest du auf Slot 3 ändern. Ich weiß nicht was die NC da verlangt.
 

Anhänge

  • libnodave-0.8.5.1-nc-2016-05-13.zip
    822,9 KB · Aufrufe: 17
Zuletzt bearbeitet:
Schau mal in der makefile.vc ob die Pfade stimmen, dort habe ich die Pfade für die VS Version eingetragen:

VCPATH=C:\Program Files\Microsoft Visual Studio 12.0\VC
SDKPATH=C:\Program Files\Microsoft SDKs\Windows\v7.1A

Diese Pfade habe ich bei mir für VS2013 unter Windows 7 32 Bit eingetragen.

Edit:
Unter 64 Bit Windows dürfte das so etwas wie:

VCPATH=C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC
SDKPATH=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A

sein.
 
Zuletzt bearbeitet:
Mit schnell zusammenkopieren hats nicht funktioniert.

Ich schau, das ich bis Dienstag die ganzen Änderungen sauber zusammenfasse und teste anschließend weiter.
 
Ich hänge dir mal meine Version an. Diese Datei an beliebiger Stelle entpacken.
Wenn du das Microsoft Visual Studio installiert hast, startest du die Eingabeaufforderung für das VS command Prompt (z.B. "VS2013 x86 Native Tools Command Prompt" bei VS2013).
Auf der Konsole navigierst du dann in den Ordner in den du mein zip entpackt hast, und gibst:

nmake -f makefile.vc

ein. Dann sollte alles ordnungsgemäß kompiliert werden.
Mein Beispiel habe ich einfach mal in die testISO_TCP.c eingebaut. Das ist dann ein Download der Daten aus deinem letzten Beispiel.
Aufrufen kannst du das Programm ebenfalls über die Eingabeaufforderung mit:

testISO_TCP.exe 192.168.1.40

Als Parameter musst du die IP-Adresse übergeben. Ohne weitere Angabe wird rack=0 und slot=2 verwendet. Mit dem Parameter --slot=3 könntest du auf Slot 3 ändern. Ich weiß nicht was die NC da verlangt.

Code:
C:\Users\1\Documents\_löschen\_LibNoDave\libnodave-0.8.5.1-nc>testISO_TCP.exe 10
.172.26.233 --slot=4
Connected.
Starte PutNC Program...
davePutNCProgram: errorcode erster Antwort: 8104
davePutNCProgram res=33028
Finished.

Anhang anzeigen testISO_TCP_NC_File_Download1.rar
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab die fixes von der libnodave mal übernommen. Hoffe das passt soweit! Hab aber damit noch nichts getestet!

Mit dieser Änderung bekomme ich keine Verbindung zur NC (Slot4). Verbundung zur PLC funktioniert.

Wireshark:
1x _myConn.Connect(); //NC (Slot4)
-> 3x Job "Setup communication" ohne Antwort

Anschließend
1x _myConn.Connect(); //PLC (Slot2)
-> 1x Job "Setup communication"
-> 1x Ack_Data "Setup communication"
-> 1x Userdata "Read SZL"
-> 1x Userdata "Read SZL"

Anhang anzeigen toolBoxConnectionErrorNC.rar
 
Meine Vermutung ist, dass du dich bei meinem Testprogramm nicht mit der NC sondern mit der SPS verbindest. Dafür würde auch die PDU-Größe sprechen, die in der jetztigen Aufzeichnung 240 Bytes ist, und bei den bisherigen funktionierenden Downloads 960 Bytes (oder du hast eine andere NC die nur 240 unterstützt?).

In deinen bisherigen Aufzeichnungen von der NC-Kommunikation ist aber nie der Verbindungsaufbau zu sehen. Darum weiß ich nicht was für ein TSAP da überhaupt verwendet werden muss. Haben der Upload und die PI-Dienstaufrufe nicht mit den nodave Funktionen funktioniert? Welche TSAPs hast du dort verwendet?
 
Meine Vermutung ist, dass du dich bei meinem Testprogramm nicht mit der NC sondern mit der SPS verbindest. Dafür würde auch die PDU-Größe sprechen, die in der jetztigen Aufzeichnung 240 Bytes ist, und bei den bisherigen funktionierenden Downloads 960 Bytes (oder du hast eine andere NC die nur 240 unterstützt?).

In deinen bisherigen Aufzeichnungen von der NC-Kommunikation ist aber nie der Verbindungsaufbau zu sehen. Darum weiß ich nicht was für ein TSAP da überhaupt verwendet werden muss. Haben der Upload und die PI-Dienstaufrufe nicht mit den nodave Funktionen funktioniert? Welche TSAPs hast du dort verwendet?

TSAPs??

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

Die Verbindung zur NC bau ich im normalerweise über die ToolBox von Jochen auf, wobei sich die PLC zur NC nur darin unterschieden, dass ich bei der NC-Verbindung den Slot auf 4 ändere.

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

Anhang anzeigen NC_Verbindungsaufbau.rar
 
Zurück
Oben