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

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die imho einzige Funktion die sich bei libnodave um die PDU Größen kümmert ist daveReadManyBytes. Im Normalfall ist also der Anwender von libnodave dafür verantwortlich die Funktionen so einzusetzen, dass die Protokollspezifikationen eingehalten werden. Was dann leider vorraussetzt, dass der Anwender überhaupt weiß wo die Beschränkungen sind. Diese "Low-Leveligkeit" war ja auch ein Grund warum der Jochen da noch eine Schicht darübergesetzt hat.

Ist bei den NC-Funktionen denn überhaupt schon aus der Anfrage ersichtlich wie groß der Antwortdatensatz werden wird? Wenn dort z.B. Zeichenketten bei angefragten Dateinamen zurückkommen, ist das im Gegensatz zu den Funktionen der S7 bei denen immer nur eine fixe Anzahl an Bytes gelesen werden nicht so einfach ersichtlich wie groß der Antwortdatensatz werden wird.

Aber wie Rainer schon schrieb, ein Wireshark Log von der Siemens Kommunikation ist nicht verkehrt. Vielleicht bietet die NC ja spezielle Funktionen dafür.

 

[Jochen Kühner]

Wenn du die ReadTags Funktion meiner Bibliothek verwendest, diese Splittet die Telegramme in mehrere PDUs auf. Dort gibt es auch keinen Spezialcode für deine NC Tags (außer du hast ihn eingebaut).

Es gibt dort aber einiges an Logik wie Ich ermittle wie Ich die Daten am geschicktesten in PDUs packe...

 

[Hans54216]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich verwende die ReadTags Funktion. Diese enthält schon kleine Anpassungen für die NC, wobei der Teil mit der PDU Größe bis jetzt gepasst hat.
Mit der NC hat NoDave ja ne PDU Größe von 960 ausgehandelt. Für die Feed Drive Daten ist jedoch bei 240 schluss.

Scheinbar tunnelt die NC die Drive anfragen und schickt sie dann per ProfiBus an den Antrieb.

Hab jetzt ne zusätzlich abfrage eingebaut und die maximale Größe dann auf 208 (240-32) verringert.

 

[Jochen Kühner]

Ich verwende die ReadTags Funktion. Diese enthält schon kleine Anpassungen für die NC, wobei der Teil mit der PDU Größe bis jetzt gepasst hat.
Mit der NC hat NoDave ja ne PDU Größe von 960 ausgehandelt. Für die Feed Drive Daten ist jedoch bei 240 schluss.

Scheinbar tunnelt die NC die Drive anfragen und schickt sie dann per ProfiBus an den Antrieb.

Hab jetzt ne zusätzlich abfrage eingebaut und die maximale Größe dann auf 208 (240-32) verringert.

Machst du n Pull Request? Wäre cool wenn das bei mir auch funktionieren würde!

 

[Rainer Hönle]

Machst du n Pull Request? Wäre cool wenn das bei mir auch funktionieren würde!

Was verstehst Du unter einem Pull-Request?

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Poll-Request?

 

[Jochen Kühner]

Pull Request? Das er seine änderungen auf github eincheckt und einen pull request auf mein repo macht!

 

[Rainer Hönle]

Pull Request? Das er seine änderungen auf github eincheckt und einen pull request auf mein repo macht!

Ich war der Meinung, das hätte was mit dem Protokoll zu tun ;-), an Git habe ich dabei nicht gedacht.

 

[Hans54216]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hab mal wieder was neues

Mehre Maschinen (840d sl) sind per X150 (ProfiNet) verbunden und ich möchte darüber kommunizieren.
Lesen/Schreiben der NC und PLC funktioniert ganz normal. Beim Dateien Kopieren kommt es jedoch zum Fehler.

So wie es aussieht hängt es mit der Größe der Datei zusammen. Ob der Fehler nun in der Siemens Steuerung oder in der Lib passiert kann ich nicht sagen.

Ablauf:
- Datei "TestFile1" ("/_N_MPF_DIR/_N_TestFile1_MPF") in Steuerung laden
- Datei "TestFile1" aus Steuerung lesen
- Hier ist noch alles gut.

- Datei "TestFile2" ("/_N_MPF_DIR/_N_TestFile2_MPF") in Steuerung laden
- Datei "TestFile2" aus Steuerung lesen
- Fehler beim Upload, Datei kann in der Steuerung nicht geöffnet werden


Leser über X150 (Fehler)
Anhang anzeigen FileUpDownloadX150_20181116.rar


Lesen über X120 (Funktioniert)
Anhang anzeigen FileUpDownloadX120_20181116.rar

 

[Thomas_v2.1]

Ist die Datei denn trotzdem in der Steuerung vorhanden?

Eine Fehlermeldung gab es von der Steuerung an keiner Stelle, sie beendet einfach direkt die Verbindung.
Was ist denn der Unterschied zwischen X120 und X150? Vielleicht musst du bei großen Dateien vor dem Upload eine kurze Zeit warten.

 

[Hans54216]

Die Dateien "_N_TESTFILE1_MPF" und "_N_TESTFILE2_MPF" hab ich per SCP von der Steuerung geladen.

Datei kommt über beide Schnittstellen auf die Steuerung, jedoch sind über X150 in der größeren Datei Bytes am Ende Falsche Bytes drin. Gesamtlänge (anzahl an Bytes) ist gleich.
Steuerung sagt bei öffnen der Datei über X150 "Kann Binär Datei nicht öffnen". Daher wird wohl der Upload in der Steuerung auch crashen.

Die 840D sl hat drei Verschiedene Netzwerkbereiche
X120: Maschinennetz
X130: Anlagennetz (Firmennetz)
X150: Maschinenvernetzung ProfiNet

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast du die Möglichkeit zu testen ab welcher Dateigröße es nicht mehr funktioniert?

Es gibt im Telegramm beim Download noch 2 unbekannte Bytes, wo an einer Stelle 0x00fb / dez 251 eingetragen wird. Vielleicht hat der Wert doch irgendeine Bewandtnis. Deine funktionierende Datei ist 199 Bytes groß und die nicht funktionierende 267. Das liegt also einmal unter und einmal über dem Wert.
Von den PDU-Größen verhalten sich laut deinen Logfiles beide Schnittstellen gleich.

 

[Thomas_v2.1]

Ich habe da eine Fährte.
Und zwar bei der Übertragung wo du sagst es fangen fehlerhafte Daten an, ist dieses ab Byte 169.
Im S7-Protokoll für den NC-Transfer gibt es 10 Bytes Header + 12 Bytes Parameter + 6 Bytes Data-Header + 43 Bytes Dateiheader für den Filetransfer. Da sind wir bei 240 Bytes, und das riecht doch stark nach einer S7-PDU-Größe.

Meine Vermutung ist darum, dass die Datenverbindung auf der betroffenen Schnittstelle intern über einen Kanal geleitet/geroutet wird, der nur 240 Bytes große PDUs beherrscht, auch wenn die Schnittstelle nach außen sagt, sie könne 960. Du könntest mal versuchen in libnodave die PDU Größe auf 240 Bytes zu setzen und dann die Daten zu übertragen. Ich vermute mal, es wird damit funktionieren.

 

[Hans54216]

Genau das ist des Rätsels Lösung. Das Problem hatte ich schon mit Drive Daten, wobei da bei jeder Schnittstelle die PDU Größe auf 240 Bytes reduziert werden muss.

Da ich bei den Drivedaten anhand der Zieladresse diese Identifizieren kann, ist es leicht nur für diese die PDU Größe zu reduzieren.

Bei den Datei Up/Downloads hab ich nun die Schwierigkeit, dass das Ziel das NC Dateisystem ist und die PDU Größe von der Schnittstelle abhängig ist. Ich kann also pauschal die Größe verringern, damit es funktioniert oder ich finde ein Kriterium mit der ich erkennen kann an welcher Schnittstelle ich stecke.

 

[Hans54216]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei "davePutNCProgram" hab ich die Funktion "daveGetMaxPDULen(dc)" wo ich prüfen kann ob die PDU größer als 240 ist und dann verringern. Wo muss ich beim "daveGetNcFile" und bei "daveGetNCProgram" die PDU Größe verringern?

Anhang anzeigen libnodave_20181117.rar

 

[Thomas_v2.1]

Ich würde beim Verbindungsaufbau ganz einfach eine PDU von 240 Bytes vorschlagen, dann wissen beide Partner davon. Der Wert steht in der Struktur daveConnection in maxPDUlength. Der Wert wird in daveNewConnection in deinem Fall auf 960 initialisiert, und dann im Ablauf der Connect-Routine ausgehandelt. Wenn du den Wert maxPDUlength direkt vor dem Aufruf von Connect auf 240 setzt, dann sollte das funktionieren.

 

[Hans54216]

Ich schau mal wie es sich bei NC Variablen verhält. Vielleicht bau ich nen Übergabeparameter für maxPDUlength ein. Ich will ja nicht grundsätzlich auf den Vorteil der größeren PDU verzichten.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Unterstützt die NC eigentlich auch das Abfragen von Informationen über die Systemzustandslisten (SZL)?
Evtl. lässt sich darüber diese "Systemeigenschaft" erkennen, die SZL-Funktionen sind in libnodave schon vorhanden.

Um zu prüfen was geht, kannst du dir erst einmal ausgeben lassen welche SZL-IDs überhaupt unterstützt werden.
Diese Information erhältst du, wenn du eine Anfrage mit SZL-ID=0 und SZL-Index=0 stellst. In der Antwort erhältst du dann eine Liste mit allen unterstützten IDs.
Beispielsweise lässt sich in ID=0x0131 Index=1 nochmal die Max. PDU Größe abfragen, wenn dort bei der einen Schnittstelle 960 und bei der anderen 240 steht, dann wäre das ein entsprechendes Kriterium.

Aber teste doch erst einmal ob es wirklich mit der 240er PDU funktioniert. Eigentlich wäre es dann ein Fehler in der Steuerung den man selber umgehen muss.

 

[Peter Gedöns]

Eigentlich wäre es dann ein Fehler in der Steuerung den man selber umgehen muss.

Eigentlich ist der Fehler das es überhaupt geht. Es ist nicht gewollt vom Profinet X150 in die NC zugreifen zumindest nicht in das NC Filesystem
ich weiß nicht mit welcher Version der Hans da Testet aber mit den letzten Softwareständen ist auch das Linuxbase angepasst worden.
man hatte gemerkt das man etwas Richtung Netzwerk Sicherheit tun muss.

 

[Hans54216]

Eigentlich ist der Fehler das es überhaupt geht. Es ist nicht gewollt vom Profinet X150 in die NC zugreifen zumindest nicht in das NC Filesystem
ich weiß nicht mit welcher Version der Hans da Testet aber mit den letzten Softwareständen ist auch das Linuxbase angepasst worden.
man hatte gemerkt das man etwas Richtung Netzwerk Sicherheit tun muss.

Ich teste mit v4.7.6.1 und v4.8.2, welche jetzt nicht gerade veraltet sind. Bei v4.7.3 weiß ich dass Siemens an der Linuxbase rumgebastelt hat und einige Fehler eingebaut hat, sodass selbst die eigenen HMI Funktionen nicht mehr funktionierten. Mir ist aber nicht bekannt dass bei S7comm etwas angelangt wurde.
Was nicht funktioniert ist der SCP Zugriff über X150.

Aber teste doch erst einmal ob es wirklich mit der 240er PDU funktioniert. Eigentlich wäre es dann ein Fehler in der Steuerung den man selber umgehen muss.

Ich hab nun zunächst viele NC Variablen gelesen (960 PDU Größe), dabei bekomme ich ebenfalls einen Fehler. Anschließend hab ich die maximale PDU Größe auf 240 gesetzt und siehe da, alles funktioniert. Somit ist das wohl ein Fehler der Steuerung, dass sie über diese Schnittstelle keine kleinere PDU Größe aushandelt.

Ich hab dann die SZL0,0 der NC ausgelesen. NC sendet zwar Daten, jedoch kann LibNoDave mit diesen noch nichts anfangen.

Anhang anzeigen NC_SZL.rar