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

Zuviel Werbung?
-> Hier kostenlos registrieren
Ich steh' auf dem Schlauch, mir fällt da keine Logik zu ein.

Was passiert wenn du unackcount z.B. auf 7 festsetzt? Nicht dass die NC einfach eine Zeit abwartet in der nichts kommt, und dann erst sagt "weitermachen".
 
Code: 
C:\Users\1\Documents\_löschen\_LibNoDave\libnodave-0.8.5.1-nc>testISO_TCP.exe --slot=4 192.168.214.1
Connected.
Starte PutNC Program...
davePutNCProgram: tot_len=989133
davePutNCProgram: unackcount=0, warte auf Antwort von NC um fortzusetzen...
davePutNCProgram: tot_len=988201
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=987269
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=986337
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=985405
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=984473
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=983541
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=982609
davePutNCProgram: unackcount=0, warte auf Antwort von NC um fortzusetzen...
davePutNCProgram res=-1025
Finished.
 
Ich könnte mir vorstellen, dass wir nach dem Absenden von EndDownload bei der Antwort von der NC nochmal prüfen, ob sich da nicht noch eine alte "Fortsetzungsanweisung" von der NC im Empfangspuffer befindet, und diese einfach wegwerfen/ignorieren. Dann kommt es hoffentlich immer zu einem erfolgreichen Abschluss.
Das ist dann zwar nicht richtig, aber es funktioniert.
 
Also ab Zeile 7592 (hoffentlich sind wir da noch in sync):
Code: 
                /* Antwort auswerten */
                if (res == daveResOK) {
                    res = _daveSetupReceivedPDU(dc, &p2);
                    if (daveGetDebug() & daveDebugPDU) {
                        _daveDumpPDU(&p2);
                    }
                    while (p2.param[5] == 0x3f && p2.param[6] == 0x03 && p2.dlen == 6) {
                        /* noch ein altes Fortsetzungstelegramm im Puffer? Ignorieren und nochmal lesen */
                        LOG1("davePutNCProgram: Noch ein Fortsetzungstelegramm im Puffer, versuche nochmal zu lesen...\n");
                        res = _daveGetResponseISO_TCP(dc);
                        if (res == daveResOK) {
                            res = _daveSetupReceivedPDU(dc, &p2);
                            if (daveGetDebug() & daveDebugPDU) {
                                _daveDumpPDU(&p2);
                            }
                        }
                        if (res != daveResOK) {
                            break;
                        }
                    }
                    if (p2.param[5] == 0xbf && p2.param[6] == 0x04) {
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Code: 
davePutNCProgram: tot_len=11465davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=10533
davePutNCProgram: unackcount=0, warte auf Antwort von NC um fortzusetzen...
davePutNCProgram: tot_len=9601
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=8669
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=7737
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=6805
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=5873
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=4941
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=4009
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=3077
davePutNCProgram: unackcount=0, warte auf Antwort von NC um fortzusetzen...
davePutNCProgram: tot_len=2145
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=1213
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
davePutNCProgram: tot_len=281
davePutNCProgram: Senden ohne auf Antwort zu warten, Aufruf _daveSendTCP...
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: Noch ein Fortsetzungstelegramm im Puffer, versuche nochmal zu
lesen...
davePutNCProgram: End download, errorcode in parameterteil war res=0
davePutNCProgram res=0
Finished.

Datei ist auf der Steuerung vorhanden.

Anhang anzeigen testISO_TCP_NC_File_Download8_v4_5_5_5_work.rar
 
Nicht schön aber selten.
Oder wir prüfen ob in dem Telegramm von der NC eine 18 steht, und dann wird eine 8 angekommen. Wenn dort eine 10 oder 8 steht dann wird dieser Wert übernommen, denn dann scheint sich die NC auch so zu verhalten. Die v4.7 schickt zumindest die 10, und das passt dann auch.

Als Notfallbremse dann die Prüfung ob noch was im Puffer ist, für sonstige Exoten.
 
So in der Art (Zeile 7566):
Code: 
                            if (unackcount == 18) {
                                unackcount = 8;
                            } else if (unackcount == 0) {
                                LOG2("davePutNCProgram: in continue response unackcount=%d. Exit!\n", unackcount);
 
Dann müsste man zumindest nochmal den Code "durchfegen", und die Kommunikation unabhängig von den Übertragungswegen machen. Jetzt ist ja fest Iso-On-TCP eincodiert.

Ich weiß nur noch nicht was ich in Wireshark an dieses Datenfeld (1.Byte) schreiben soll, oder ich lass es einfach ohne Beschreibung.
 
Wie sieh´s bei dir aus? Hast du lust den Code unabhängig vom Übertragungsweg zu machen?

Ich kann den Code dann gerne testen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hans54216 schrieb:
Wie sieh´s bei dir aus? Hast du lust den Code unabhängig vom Übertragungsweg zu machen?

Ich kann den Code dann gerne testen.
Zum Vergrößern anklicken....

Ich dachte du bist schon schwer dabei ;-)

Also muss ich nicht unbedingt machen, das müsste ja auch in Jochens Lib rein. Fang doch mal an, wenn's hakt dann kannst du gerne fragen.
 
Thomas_v2.1 schrieb:
Ich dachte du bist schon schwer dabei ;-)

Also muss ich nicht unbedingt machen, das müsste ja auch in Jochens Lib rein. Fang doch mal an, wenn's hakt dann kannst du gerne fragen.
Zum Vergrößern anklicken....

Hab im Moment gerade wenig Zeit da was zu machen. Zusätzlich sehe ich Momentan keinen Anwendungsfall in dem ein anderer Übertragungsweg als Iso-On-TCP zur NC nötig ist.

Nach dem der Jochen seine Lib überarbeitete hab ich die Tests ja bereits mit dieser Durchgeführt.

Werde diese dann wohl nur optisch überarbeiten und ein Pull Request anlegen.
 
Falls jemand lust hat mich zu unterstützen. Hab mal ein ganzes Paket zusammengestellt, mit den meisten Datentypen und den zugehörigen Definitionsdateien.
 

Anhänge

  • GUD_ACX_Files.rar
    5,2 KB · Aufrufe: 22
Wenn ich richtig liege kann damit der Inhalt der Definitionsdatei GUDx von der NC gelesen werden.
Bei der 840d gibt es Definitionsdateien für Variablen. Deren Inhalt wird erst nach dem aktivieren aktiv. Und genau hier liegt gerade mein Problem. Ich hab mir nen Interpreter für die Definitionsdatei geschrieben. Ist nun eine Datei nicht aktiviert und es wurde zwischendrin eine Variable verändert verschieben sich die Adressen für den Lese/Schreibzugriff.

Hab mir die Hexfiles heute mal genauer angesehen und auch schon einzelne Byte ausgemacht, die für den Datentyp oder Arrays stehen.

Kennst du ein Tool mit dem man die Hexfiles schön vergleichen kann?
 

Similar threads

E
Snap7 Zugriff auf Dual-Port RAM / FB15 / SINUMERIK
Antworten
1
Aufrufe
4K
Jochen Kühner
Jochen Kühner
Zurück
Oben