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

[Hans54216]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Hans ist da noch ein Fehler in meiner Lib?

0x80 (Periphery) ist zwar als enum vorhandeln, wird jedoch nicht verwendet. Laut Kommentar ist es auch nicht im Tag zulässig.

Hab das interpretieren der PLC Adresse angepasst (ergänzt).
Ich mach bei zeiten wieder nen Pull request von meim Fork.

 

[Thomas_v2.1]

Funktioniert der Dateidownload eigentlich mit den ergänzten Funktionen in libnodave fehlerfrei bei großen wie auch bei kleinen Dateien?

Mir ist bei den mir vorliegenden Logfiles aus diesem Thread nämlich eine kleine Unstimmigkeit aufgefallen.
Und zwar wird der eigentlichen Datei u.a. die Dateilänge als ASCII vorangestellt. In der Funktion die ich ergänzt habe, berechne ich die Längenangabe aus der Länge der Datei plus der Länge der Pfadangabe.

Jetzt habe ich hier eine Aufzeichnung "NC_File_Download" bei der diese Berechnung auch stimmt (Daten=20, Pfad=19, Vorab=39), aber bei der Aufzeichnung "NC_File_Big_Download" in der die gesamte Datei auf mehrere PDUs aufgeteilt wird, stimmt die Berechnung überhaupt nicht (Daten=8918, Pfad=34, Vorab=8934). Screenshots davon im Anhang.

Oder diese Längenangabe ist überhaupt nicht von Relevanz, wenn der Download trotzdem funktioniert.

Das ist mir aufgefallen, weil ich in Wireshark das Zusammensetzen der Datenteile aus fragmentierten Dateien ergänzt habe, und eigentlich die Länge vorab für die Größe der Datei verwenden wollte, was aber nicht bei allen Dateien die ich von NC Down-/Upload Transaktionen habe, funktioniert.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hilft doch manchmal das Problem nochmal aufzuschreiben. Ist alles richtig umgesetzt, bei den NC Funktionen gibt es im Dateiteil in jedem Fragment nochmal diese zwei Bytes 0x00, 0xfd unbekannter Funktion.
Da kommt dann die Rechnung hin, wenn ich 9*2 = 18 Bytes davon abziehe.

Dann habe ich aber noch eine Aufzeichnung "NC_File_Big_Download2", bei dem vor dem Download noch eine Upload Anforderung ist, da stehen in der Dateilänge wiederum nur Leerzeichen. Der Inhalt sieht dann auch nicht nach Datei aus, sondern nach einer Art Verzeichnisauflistung. Gibt es sowas?

 

[Hans54216]

Dann habe ich aber noch eine Aufzeichnung "NC_File_Big_Download2", bei dem vor dem Download noch eine Upload Anforderung ist, da stehen in der Dateilänge wiederum nur Leerzeichen. Der Inhalt sieht dann auch nicht nach Datei aus, sondern nach einer Art Verzeichnisauflistung. Gibt es sowas?

Wenn man einen Upload auf einen Ordner/Verzeichnis macht, schickt die NC ein File mit den Namen der Dateien und Ordner in diesem Pfad.

 

[Thomas_v2.1]

Wenn man einen Upload auf einen Ordner/Verzeichnis macht, schickt die NC ein File mit den Namen der Dateien und Ordner in diesem Pfad.

Ich glaube du hattest in diesem Thread mal geschrieben, die Pfadangabe könne maximal 32 Zeichen lang sein. So viel Platz habe ich in der ergänzten Funktion die ich hier gepostet habe auch vorgesehen.

Bei der Verzeichnisanfrage sind aber laut einem Logfile was ich von dir habe auch längere Angaben möglich. In einer Aufzeichnung mit einem Upload und ;$PATH=/_N_wks_dir/_N_G_GQ_TEST_SWITCH_VCS_WPD sind es 40 Zeichen. Es wäre also sinnvoll das auch in der Funktion zu erweitern, andernfalls wird die Pfadangabe abgeschnitten und es kommt vermutlich ein Fehler zurück.

 

[Hans54216]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich glaube du hattest in diesem Thread mal geschrieben, die Pfadangabe könne maximal 32 Zeichen lang sein. So viel Platz habe ich in der ergänzten Funktion die ich hier gepostet habe auch vorgesehen.

Nicht die Pfadangabe, sondern ein Dateiname/Ordner können maximal 31 Zeichen + Nullterminierung lang sein.

Bei der Verzeichnisanfrage sind aber laut einem Logfile was ich von dir habe auch längere Angaben möglich. In einer Aufzeichnung mit einem Upload und ;$PATH=/_N_wks_dir/_N_G_GQ_TEST_SWITCH_VCS_WPD sind es 40 Zeichen. Es wäre also sinnvoll das auch in der Funktion zu erweitern, andernfalls wird die Pfadangabe abgeschnitten und es kommt vermutlich ein Fehler zurück.

Für den Up- oder Download muss zunächst ein PI-Dienst mit der Pfadangabe ausgeführt werden. Im Up/Download selbst wird nur der Dateiname angegeben. In diesem Fall 27 Zeichen + \0.

 

[KES_CK]

@Hans54216
danke für das super code snippet!
Das laden und interpretieren der unterschiedlichen ACX-Files klappt hervorragend!
Das lesen von selbst angelegten GUD's => MGUD, UGUD, GD4-GD9 sowohl Global und Kanalspezifisch funktioniert.
Beim versuch z.B. GUD's aus dem Bereich Global SGUD oder denen die über MD18660 im Baustein MGUD (SYG_RM) angelegten wurden zu lesen wird im PLCNckTag ItemDoesNotExist=true gesetzt.
Das Lesen über die PLC mit FB5 klappt normal.
Hast Du in dem Bereich auch schon mal versucht was zu lesen?

 

[Hans54216]

Über X130 (Firmennetz) funktioniert die alte Upload Methode mit neuen Software Ständen nicht mehr.
Mit der neuen Variante (NC sendet mehrer Pakete ohne Bestätigung) kommt es bei INI Dateien zum Fehler in LibNoDave.

Anhang anzeigen IniFileUpload_20190221.rar

Vom HMI hochgeladen (andere INI): Anhang anzeigen IniFileUpload_HMI_20190221.rar

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Zählung von unackcount ist nicht richtig, das erste Paket außerhalb der while-Schleife wird nicht mitgezählt.
Wenn du nach tot_len += part_len; und vor while... ein unackcount++; einfügst sollte es richtig gezählt werden. Zumindest in dem Stand der Funktion die ich habe. Vermutlich ist der Fehler in der anderen Funktion daveGetNcFileSize ebenfalls vorhanden.

Hat das denn schon einmal funktioniert, oder wurden bisher nur noch keine Dateien geladen die mehr als 20 PDUs benötigen und es ist darum nicht aufgefallen?

 

[Hans54216]

Ich werd das morgen testen.

Hat das denn schon einmal funktioniert, oder wurden bisher nur noch keine Dateien geladen die mehr als 20 PDUs benötigen und es ist darum nicht aufgefallen?

Ich hab schon alle Größen geladen, jedoch nur von echten Programmen (PI-Dienst F_XFER). Hab letztens ja geschrieben, dass der wireshark anders aussieht wie vom HMI. Bei Programmen ist die NC da wohl nicht so gleinlich.

 

[Hans54216]

@Hans54216
danke für das super code snippet!
Das laden und interpretieren der unterschiedlichen ACX-Files klappt hervorragend!
Das lesen von selbst angelegten GUD's => MGUD, UGUD, GD4-GD9 sowohl Global und Kanalspezifisch funktioniert.
Beim versuch z.B. GUD's aus dem Bereich Global SGUD oder denen die über MD18660 im Baustein MGUD (SYG_RM) angelegten wurden zu lesen wird im PLCNckTag ItemDoesNotExist=true gesetzt.
Das Lesen über die PLC mit FB5 klappt normal.
Hast Du in dem Bereich auch schon mal versucht was zu lesen?

Schau ich mir morgen an, muss aber funktionieren.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Apropos PI-Dienste: Wozu dient eigentlich _N_F_PROR?
Dazu gab es schon mal einen Thread, aber ergebnislos.

 

[Hans54216]

Apropos PI-Dienste: Wozu dient eigentlich _N_F_PROR?
Dazu gab es schon mal einen Thread, aber ergebnislos.

Ich werd mal ne anfrage bei Siemens starten. Die Theorie is das es irgend welche Zugriffsrechte setzt, wobei er nicht dokumentiert ist. Das HMI startet ihn auf alle möglichen Dateien, wobei er immer wieder negativ (Fehlerhaft) quittiert wird.

 

[Thomas_v2.1]

Ich werd mal ne anfrage bei Siemens starten. Die Theorie is das es irgend welche Zugriffsrechte setzt, wobei er nicht dokumentiert ist. Das HMI startet ihn auf alle möglichen Dateien, wobei er immer wieder negativ (Fehlerhaft) quittiert wird.

Die Fehlermeldung der Antwort kann ich leider nicht aufschlüsseln, sonst wäre das auch hilfreich.
Ich hatte mir auch gerade so überlegt PROT = Protection setzen, und PROR = Protection remove oder etwas in der Richtung.
Wenn ich die Parameter so interpretiere wie _N_F_PROT dann stünden im 3. Parameter bei Protection fünf Unterstriche _____

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hab schon alle Größen geladen, jedoch nur von echten Programmen (PI-Dienst F_XFER). Hab letztens ja geschrieben, dass der wireshark anders aussieht wie vom HMI. Bei Programmen ist die NC da wohl nicht so gleinlich.

Ich habe noch eine Aufzeichnung eines Uploads von dir über die libnodave Funktionen gefunden. Das scheint doch richtig gewesen zu sein so wie es ist, nur gibt es bei deiner aktuellen Version einen Unterschied wie die NC sich verhält.

Bisher:
-> Request Start Upload (0x11, 0x7f, 0x06)
<- Response Start Upload (0x12, 0xbf, 0x06)
<- Dann NC Push-Response Upload (0x12, 0x3f, 0x07) und diese Anzahl muss gezählt werden, so wie es jetzt gemacht wurde und der Aufzeichnung nach auch funktioniert.

Deine neue Aufzeichnung
-> Request Start Upload (0x11, 0x7f, 0x06)
<- Direkt NC Push-Response (0x12, 0x3f, 0x07) und dann ab hier zählen

Ich habe überhaupt nicht überprüft ob der Funktionscode in der Antwort richtig ist. Das sollte man aber wohl tun, und nur wenn in der ersten Antwort (0x12, 0x3f, 0x07) dann unackcount um 1 inkrementieren. Es ließe sich auch anstelle die Telegramme zu zählen auf die Nummer reagieren die mitgeschickt wird, aber letztlich kommt es auf das gleiche raus.

 

[Hans54216]

Bisher:
-> Request Start Upload (0x11, 0x7f, 0x06)
<- Response Start Upload (0x12, 0xbf, 0x06)
<- Dann NC Push-Response Upload (0x12, 0x3f, 0x07) und diese Anzahl muss gezählt werden, so wie es jetzt gemacht wurde und der Aufzeichnung nach auch funktioniert.

Upload mit Anpassung:
Anhang anzeigen BigFileUpload_v4_8_4_1_20190222.rar

Deine neue Aufzeichnung
-> Request Start Upload (0x11, 0x7f, 0x06)
<- Direkt NC Push-Response (0x12, 0x3f, 0x07) und dann ab hier zählen

Upload mit Anpassung:
Anhang anzeigen IniFileUpload_v4_8_4_1_20190225.rar

Ich habe überhaupt nicht überprüft ob der Funktionscode in der Antwort richtig ist. Das sollte man aber wohl tun, und nur wenn in der ersten Antwort (0x12, 0x3f, 0x07) dann unackcount um 1 inkrementieren. Es ließe sich auch anstelle die Telegramme zu zählen auf die Nummer reagieren die mitgeschickt wird, aber letztlich kommt es auf das gleiche raus.

Sollte das noch rein?

 

[Hans54216]

@Hans54216
danke für das super code snippet!
Das laden und interpretieren der unterschiedlichen ACX-Files klappt hervorragend!
Das lesen von selbst angelegten GUD's => MGUD, UGUD, GD4-GD9 sowohl Global und Kanalspezifisch funktioniert.
Beim versuch z.B. GUD's aus dem Bereich Global SGUD

SGUD = 0x36,
PGUD = 0x36,    //= SGUD
GUD1 = 0x36     //= SGUD

_N_NC_GD1_ACX, _N_CH_GD1_ACX
Funktioniert bei mir genau so wie die anderen Bereiche.

oder denen die über MD18660 im Baustein MGUD (SYG_RM) angelegten wurden zu lesen wird im PLCNckTag ItemDoesNotExist=true gesetzt.
Das Lesen über die PLC mit FB5 klappt normal.
Hast Du in dem Bereich auch schon mal versucht was zu lesen?

Kannst du die SYG_RM per FB5 lesen? Wenn ja, was steht auf der Struktur "VarToken"?

 

[Hans54216]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die SYG Variablen können auch ganz normal gelesen/geschrieben werden

 

[Thomas_v2.1]

Sollte das noch rein?

Ich schätze mal ja, denn ich vermute mal mit deiner Änderung jetzt wird es an der alten Steuerung nicht mehr funktionieren.

 

[KES_CK]

SGUD = 0x36,
PGUD = 0x36,    //= SGUD
GUD1 = 0x36     //= SGUD

_N_NC_GD1_ACX, _N_CH_GD1_ACX
Funktioniert bei mir genau so wie die anderen Bereiche.

Kannst du die SYG_RM per FB5 lesen? Wenn ja, was steht auf der Struktur "VarToken"?

Ich kann die Daten per FB5 ohne Probleme lesen aber beim lesen über die Lib bekommen ich als Value immer null zurückgeliefert
Bereich SGUD GUD-Variable _F_NCK_CL_ANG[0]
Step7:

C#:


Das gleiche Verhalten beim lesen der SYG_RM[0]
Step7:

C#: