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

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Jochen,

Ich versuche gerade einen String von der NC zu lesen.

Wenn ich im PLCNckTag zusätzlich zum Typ String noch die "ArraySize = 20" mitgebe, kommt im Buffer der Text auch an.

Beim Umwandeln des Strings kommt es aber zu einem Exception:

{"Der Index und die Anzahl müssen sich auf eine Position im Puffer beziehen.\r\nParametername: bytes"}


Versuchs mal mit "CharArray", String ist ein S7String mit 2 Bytes header!
 
@Jochen
Hier die Infos zu den Beschränkungen:

Das hier:

Soweit ich es verstanden habe sind die Limitierungen wie folgt:

  • Die Bereiche FeedDrive und MainDrive dürfen jeweils immer nur einzeln, nicht in Kombination mit anderen Bereichen gelesen werden. Bei anderen Bereichen ist das egal
  • Das gleichzeitige Lesen von Variablen aus mehreren Units in einem Auftrag ist NIE erlaubt, egal aus welchem Bereich
  • In den Bereichen FeedDrive und MainDrive dürfen max. 19 Variablen auf einmal gelesen werden, egal welcher Datentyp
  • Die Endian-Verdrehung betrifft (glaube ich) alles in den Bereichen MainDrive und FeedDrive, nicht nur die 0x8Y Blöcke

sagt mir aber alles nichts! Ich weiß nicht was der Bereich "FeedDrive" ist, ... Wie gesagt Ich kenn mich mit NC nicht aus!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Limitierungen für die "PLCNckTag" sind wie folgt:

  • Die Bereiche FeedDrive und MainDrive dürfen jeweils immer nur einzeln, nicht in Kombination mit anderen Bereichen gelesen werden. Bei anderen Bereichen ist das egal
PLCNckTag.NckArea == 5 || PLCNckTag.NckArea == 6 -> dürfen nicht in Kombination mit anderen Bereichen gelesen werden

  • Das gleichzeitige Lesen von Variablen aus mehreren Units in einem Auftrag ist NIE erlaubt, egal aus welchem Bereich
PLCNckTag.NckUnit -> alle NckUnit in einem Auftrag müssen gleich sein

  • In den Bereichen FeedDrive und MainDrive dürfen max. 19 Variablen auf einmal gelesen werden, egal welcher Datentyp
PLCNckTag.NckArea == 5 || PLCNckTag.NckArea == 6 -> dürfen max. 19 Variablen auf einmal gelesen werden, egal welcher Datentyp (Wobei die HMI maximal 17 Variablen liest)

  • Die Endian-Verdrehung betrifft (glaube ich) alles in den Bereichen MainDrive und FeedDrive, nicht nur die 0x8Y Blöcke
PLCNckTag.NckArea == 5 || PLCNckTag.NckArea == 6 -> Endian-Verdreht wie Sps, die anderen Bereiche sind x86
(Dafür hab ich bereits eine mögliche Lösung eingebaut!)
 
Werd das nächste Woche einbauen... Vlt. Strukturier Ich auch das PLC Tag Objekt noch ein bischen um, das ein NckPLCTag nicht 1000 unbenutzte Properties hat...
 
Weiß jemand wie ich die Funktion vom FB5 "GetGUD" in C# nachbilde?


Die Funktion liefert anhand des Bereichs (NC, Kanal) und dem GUD-Variablennamen die Adresse in der bekannten Struktur. (Intern wird wieder der FB15 (C_für_S7) aufgerufen)

An Hand dieser Struktur(Werte mit der PLC ermittelt) kann ich mit der PLCLib die Variable lesen.


Nun möchte ich dies gern ebenfalls in meinem Programm machen, ohne die PLC anzulangen.
 
Leider nicht. PLC und NC sind bei der 840d ja im selben Gehause.
Du könntest mal in die aufgerufenen FBs hineinschauen, und dort prüfen ob dort zumindest im Ansatz Telegrammaufbauten wiederzufinden sind die womöglich auch übers Netzwerk funktionieren könnten.
Bzw. wenn der intern aufgerufene FB15 für die NCK-Kommunikation die wir hier gelöst haben verwendet wird, ist der Aufbau evtl. identisch, und es müssen nur entsprechende Werte für die Parameter eingetragen werden.
 
Du könntest mal in die aufgerufenen FBs hineinschauen, und dort prüfen ob dort zumindest im Ansatz Telegrammaufbauten wiederzufinden sind die womöglich auch übers Netzwerk funktionieren könnten.
Bzw. wenn der intern aufgerufene FB15 für die NCK-Kommunikation die wir hier gelöst haben verwendet wird, ist der Aufbau evtl. identisch, und es müssen nur entsprechende Werte für die Parameter eingetragen werden.

Ich vermute mal, dass der Aufbau der selbe ist.

Die entscheidende Frage ist, wie bekommt man die Parameter.

Gibt es vielleicht ne SoftSPS Demo, die den FB15 unterstützt oder hat jemand ne SoftSPS und kann nen Mitschnitt der Kommunikation zur NC machen?

Aus dem FB5 definitiv nicht.

FB5 "GetGUD":
Code:
      L     DINO
      T     #C_LInstanzDb
      TAR2  
      T     #AR2_rett
      SRD   3
      T     #C_LInstanzOff


      L     W#16#8005
      T     #C_LBlockNo
      L     15
      T     #BpBlockNo
      UC    FB [#BpBlockNo]


      L     #C_LBlockFB15Return
      L     B#16#0
      ==I   
      SPBNB end


      UN    #Error
      SAVE  


end:  LAR2  #AR2_rett
      BE
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
NC file transfer

@Thomas_v2.1

Ich hab ein Wireshark des File up/download gemacht. Kannst du dir das mal anschauen und mir sagen wie das Protokoll auszusehen hat?

Beim Upload wird die Datei: "
/_N_MPF_DIR/_N_TEILEPROG1_MPF" aus der NC gelesen.

Beim Download wir die Datei: "
/_N_MPF_DIR/_N_TEILEPROG2_MPF" zur NC übertragen.

Anhang anzeigen NC_File_transfer.rar


PI-Dienst File Delete: Datei "/_N_MPF_DIR/_N_TEILEPROG2_MPF" aus NC löschen.

Anhang anzeigen NC_File_Delete.rar
 
Zuletzt bearbeitet:
Also die Grundstruktur habe ich soweit denke ich mal.

Evtl. muss ich aufgrund der Erkenntnisse mit deinen Logfiles einige Dinge im Wireshark-Dissector anpassen. Bei den üblichen SPS-Funktionen hatten nämlich bisher bestimmte Felder immer den gleichen Wert. Jetzt bei deinen Logfiles gibt es auch mal andere Werte zu sehen.

Der "Upload" scheint die gleichen Methoden zu verwenden, die auch beim SPS Programmieren verwendet werden. Im Datenteil sind das (mehr oder weniger) zwei ASCII-Strings, mit einer Längenangabe vorweg. Wobei das erste Byte bei einer SPS noch bedeutet, in wie viele Teile der String zu zerlegen ist, dann folgt auch noch ein Null-Byte. Dieses wird z.B. beim Befehl zum Einketten der vorher hochgeladenen Bausteine angewendet. Bei deinem NC Upload gibt es auch ein vorangestelltes Byte mit dem Wert 3, aber der restliche String ist dann nur der Dateipfad den du hier angegeben hast, und ggf. ein P01 vorangestellt, also max. 2 Teile.

Wie auch immer. Wenn du das in/mit libnodave komplett umgesetzt haben möchtest, musst du dich da schon selber reinfuchsen. Ohne direkten Zugriff auf eine NC, und dann noch über den Umweg über Jochen und seine Bibliothek sind wir andernfalls noch Jahre mit dem Pingpongspielen beschäftigt.

Ich selber habe auch nur insofern Interesse daran, dass ich das in Wireshark korrekt anzeigen kann.
 

Anhänge

  • NC-Download.pdf
    528,8 KB · Aufrufe: 19
  • NC-Upload.pdf
    770,7 KB · Aufrufe: 11
  • NC-File-Delete.pdf
    182,8 KB · Aufrufe: 10
Der String beim Upload ließe sich doch als 3 Teile interpretieren:
1) P01
2) _N_MPF_DIR/_N_TEILEPROG1_MPF
3) _N_F_XFER

Wobei _N_F_XFER nach meiner bisherigen Intepretation der PI-Service ist, beim SPS-Programmieren gibt es z.B. _INSE zum Einketten von Bausteinen. Theoretisch sollte der Aufbau beim Upload zwischen SPS und NC Kommunikation identisch sein, evtl. lassen sich dann doch Teile von den schon in libnodave vorhandenen Programmierfunktionen weiterbenutzen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie auch immer. Wenn du das in/mit libnodave komplett umgesetzt haben möchtest, musst du dich da schon selber reinfuchsen. Ohne direkten Zugriff auf eine NC, und dann noch über den Umweg über Jochen und seine Bibliothek sind wir andernfalls noch Jahre mit dem Pingpongspielen beschäftigt.

Danke schon mal!

Ein bisschen hab ich mich schon eingearbeitet. Hab in der libnodave sowie der Toolbox von Jochen auch das schreiben auf NC Variablen erfolgreich eingebaut.
Das reine programmieren und testen sollte kein Problem sein.
Die Schwierigkeit sehe ich vor allem im Protokoll.

Wenn du, Jochen oder wer sonst möchte mich dabei unterstützt, sollte es in einem überschaubaren Zeitraum funktionieren.

Thomas_v2.1 schrieb:
Ich selber habe auch nur insofern Interesse daran, dass ich das in Wireshark korrekt anzeigen kann.

Um das korrekt anzeigen zu können benötigst du ja den Aufbau des Telegramms. Was mir wiederum hilft das Telegramm nachzubilden und zu befüllen.
 
Zuletzt bearbeitet:
Wir können ja erstmal mit dem NC Upload anfangen, denn der Ablauf ist noch in Teilen mit dem identisch welche die SPS verwendet, außerdem bekomme ich dadurch evtl. auch noch eine etwas bessere Struktur in die SPS-Teile.

Bei der SPS gibt es nämlich auch PI-Dienste. Aus dem SPS-Programm heraus lässt sich aber nur der für Stop und für Start aufrufen, darum fehlt mit da etwas der Vergleich.
Wie aus diesem Thread ersichtlich:
http://www.sps-forum.de/simatic/587...nd-den-pi-dienst-_n_f_pror-oder-nur-pror.html

sind bei der NC noch weitere Funktionen möglich. Mir ist bisher unbekannt, wie die Parameter des Funktionsaufrufs auf dem Netzwerk übertragen werden. Laut den NC-Handbüchern existieren dabei nur zwei Typen von Parametern: INT oder STRING.

In dem 1. Telegramm in deinem File Upload mit Function 0x28, wäre meine aktuelle Vermutung, dass die erste Längenangabe für die Länge der Argumente (gesamt) ist, und dann wie auch immer die einzelnen Argumente dort hintereinandergehängt werden. Als letztes kommt dann der PI-Dienst der aufgerufen werden soll als STRING.
Oder der Partner entscheidet anhand des angegebenen PI-Dienstnamens, wie die Argumente zu interpretieren sind. Das wäre unschön, denn dann muss ich vorab alle Argumente und Argumenttypen kennen.

Vielleicht kannst du noch von anderen PI-Dienstaufrufen mit diversen Parametern Mitschnitte machen, um hoffentlich damit herausfinden zu können wie die Argumente codiert werden. Dann lässt sich hoffentlich eine universelle Funktion schreiben, die einen PI-Dienstaufruf auf dem Netzwerk abschickt.
 
Zuletzt bearbeitet:
Ich hab deinen commit auf github mal gemerged....

Komm aber grad nicht wirklich dazu da was zu machen! Helfen kann iCH DIR NATÜRLICH GERNE (SOFERN ES MIR MÖGLICH IST)
 
Zurück
Oben