# LibNodave Write Request von mehrern Var.



## Jochen Kühner (2 Juni 2010)

Bin gerade dabei in meinen Wrapper das schreiben von mehren Variablen zu implementieren. Was muss Ich den an Overhead pro Variable die auf die CPU geschrieben wird rechnen? Auch 4 Byte wie beim Read Request, plus die Daten, oder ist das anderst?


----------



## Zottel (3 Juni 2010)

Jochen Kühner schrieb:


> ...Auch 4 Byte wie beim Read Request, plus die Daten, oder ist das anderst?


Ich weiß es nicht auswendig, aber wenn du 
davePrepareWriteRequest, daveAddVarToWriteRequest, daveExecWriteRequest ausführen läßt, dabei die Anzahl der Variablen änderst 
und dir die Requests per debug-Ausgabe anzeigen läßt, kannst du es leicht herausfinden.


----------



## Jochen Kühner (3 Juni 2010)

Zottel schrieb:


> Ich weiß es nicht auswendig, aber wenn du
> davePrepareWriteRequest, daveAddVarToWriteRequest, daveExecWriteRequest ausführen läßt, dabei die Anzahl der Variablen änderst
> und dir die Requests per debug-Ausgabe anzeigen läßt, kannst du es leicht herausfinden.



Jo hab jetzt auch schon im Quellcode geschaut, aber dachte jemand weiss es so... Sind auf jeden fall auch 12 Byte für die Variable, aber da ist noch so ein Header... Ich muss mal analysieren...


----------



## Thomas_v2.1 (3 Juni 2010)

Jochen Kühner schrieb:


> Jo hab jetzt auch schon im Quellcode geschaut, aber dachte jemand weiss es so... Sind auf jeden fall auch 12 Byte für die Variable, aber da ist noch so ein Header... Ich muss mal analysieren...



12 Byte Parameterteil für die Adressangabe pro Datenbereich.
Bei einem "Write"-Befehl kommen dann nochmal 4 Byte Header für den Datenteil pro Datenbereich hinzu.

Beim "Read"-Befehl fehlt der Datenteil beim Request, in der Antwort eines "Read" sind dann die gleichen 4 Byte Header pro Datenteil wie bei einem "Write" vorhanden.


----------



## Jochen Kühner (3 Juni 2010)

Thomas_v2.1 schrieb:


> 12 Byte Parameterteil für die Adressangabe pro Datenbereich.
> Bei einem "Write"-Befehl kommen dann nochmal 4 Byte Header für den Datenteil pro Datenbereich hinzu.
> 
> Beim "Read"-Befehl fehlt der Datenteil beim Request, in der Antwort eines "Read" sind dann die gleichen 4 Byte Header pro Datenteil wie bei einem "Write" vorhanden.



Für was braucht man den die 4 Bytes pro Datenbereich???


----------



## Thomas_v2.1 (3 Juni 2010)

Jochen Kühner schrieb:


> Für was braucht man den die 4 Bytes pro Datenbereich???


1. Byte: Rückgabewert, eigentlich nur bei Read relevant. Ist der angefragte Datenbereich nicht verfügbar wird hier ein Wert <>0 zurückgegeben
2. Byte: Transport-Größe der Längenangabe (z.B. Bit, Byte, Word, etc.)
3./4. Byte: Anzahl der folgenden Daten (je nach Angabe in Byte 2)


----------



## Jochen Kühner (3 Juni 2010)

Thomas_v2.1 schrieb:


> 1. Byte: Rückgabewert, eigentlich nur bei Read relevant. Ist der angefragte Datenbereich nicht verfügbar wird hier ein Wert <>0 zurückgegeben
> 2. Byte: Transport-Größe der Längenangabe (z.B. Bit, Byte, Word, etc.)
> 3./4. Byte: Anzahl der folgenden Daten (je nach Angabe in Byte 2)



Ja aber das steht doch auch schon in den 12 Header Bytes...
oder:


```
0x12, 0x0a, 0x10,
		0x02,		/* unit (for count?, for consistency?) byte */
		0,0,		/* length in bytes */
		0,0,		/* DB number */
		0,		/* area code */
		0,0,0		/* start address in bits */
```


----------



## Thomas_v2.1 (3 Juni 2010)

Jochen Kühner schrieb:


> Ja aber das steht doch auch schon in den 12 Header Bytes...


Ich hab mir das Protokoll ja auch nicht ausgedacht ;-)

Aber diese 4 Byte Itemdaten-Header sind genauso auch in anderen Anfragen/Antworten wie zyklische Lesedienste, SZL etc. vorhanden.
So kann man eine Auswertefunktion für den Datenteil auch für verschiedene Telegramme nutzen, auch wenn es bei manchen zu Redundanzen führt.


----------



## bool (7 Juni 2010)

Hallo zusammen, 

wie vermutlich von einigen bereits bemerkt bin ich noch libnodave Einsteiger und momentan hauptsächlich Anwender der Bibliothek und beginne erst langsam Stück für Stück hinter die Kulissen zu spickeln.

Der ReadRequest von multiblen Variablen ist bei der von meiner verwendeten Test SPS S7 317 2DP/PN mit max 19Variablen begrenzt. Beim schreiben von multiblen Variablen via "dc.execWriteRequest(multiwritePDU01, rs)" musste ich heute feststellen, dass hier bereits bei 12 Variablen Schluss ist. Dies mag vermutlich darin begründet sein, dass der Poll mehr Informationen beinhaltet und deswegen nicht so viele Variablen aufgenommen werden können.
Testweise schreibe ich nun, da ich eine schnelle Lösung (programmiertechisch) brauchte, die Daten mit einzelnen Kommandos via 
dc.writeBytes(nArea, nDBnr, nByteAdr, nDataLength, Buffer)
in die SPS, jedoch ist dies performance mässig gesehen nicht die optimalste Lösung, vor allem nicht wenn man um die 20 nicht zusammenhängende Variablen zyklisch (mehrfach pro Sekunde) in die SPS schreiben möchte.
Aus diesem Grund möchte ich die Variablen auf zwei multible WriteRequests aufteilen. Ziel ist es jedoch hierfür KEINE zweite Verbindung (PDU) zur SPS aufzubauen, sondern nur eine PDU zu verwenden.
Gibt es hier dann eine Möglichkeit, dass die Funktion multiwritePDU01.addVarToWriteRequest(nArea, nDBnr, nByteAdr, nDataLength, Buffer) nicht bei jedem Schreibauftrag x mal aufgerufen werden muss, sondern die Variablen inklusive dem zu jeweils zu schreibenen Wert in eine Struktur geschrieben wird, und dann diese Struktur dem WriteRequest zugewiesen wird? Wie müsste dies dann aussehen?

Danke bereits im voraus.

Gruss,

bool


----------



## Jochen Kühner (7 Juni 2010)

bool schrieb:


> Hallo zusammen,
> 
> wie vermutlich von einigen bereits bemerkt bin ich noch libnodave Einsteiger und momentan hauptsächlich Anwender der Bibliothek und beginne erst langsam Stück für Stück hinter die Kulissen zu spickeln.
> 
> ...



Ab wievielen Variablen Schluss ist hängt einfach auch mit der länge der Var. zusammen welche geschrieben werden. Und wenn du in meine connection lib schaust, dort benutze Ich das addvartoread request. Du kannst die Connection Lib auch in einem VB Programm verwenden!


----------



## bool (7 Juni 2010)

Jochen Kühner schrieb:


> Ab wievielen Variablen Schluss ist hängt einfach auch mit der länge der Var. zusammen welche geschrieben werden. Und wenn du in meine connection lib schaust, dort benutze Ich das addvartoread request. Du kannst die Connection Lib auch in einem VB Programm verwenden!


 
... ok, werde ich probieren zu integrieren. 
Baut die Connection Lib dann mehrere Verbindungen parallel auf oder begnügt sie sich mit einer PDU?

Gruss,

bool


----------



## Jochen Kühner (7 Juni 2010)

bool schrieb:


> ... ok, werde ich probieren zu integrieren.
> Baut die Connection Lib dann mehrere Verbindungen parallel auf oder begnügt sie sich mit einer PDU?
> 
> Gruss,
> ...



begnügt sie sich mit einer PDU???? Hä? ( siehe http://de.wikipedia.org/wiki/Protocol_Data_Unit ) Die PDUs sind Teil der Kommunikationstelegramme zur SPS.


----------



## Jochen Kühner (7 Juni 2010)

Und man sollte mehrer Verbindungen zur gleichen Zeit aufbauen können....

Hier kurzes Codebeispiel:

Verbindungen einstellen:

```
LibNoDaveConnectionLibrary.Configuration.ShowConfiguration("", False)
```

Verbindungen aufbauen: (Die beiden Connections aaaa und bbbb wurden definiert)

```
Dim myConn1 As New LibNoDaveConnection("aaaa")
Dim myConn2 As New LibNoDaveConnection("bbbb")
myConn1.Connect()
myConn2.Connect()
```

Tags lesen:

```
Dim val As New LibNoDaveValue
        val.ByteAddress = 10
        val.DatablockNumber = 2
        val.LibNoDaveDataType = LibNoDaveDataType.Byte
        val.LibNoDaveDataSource = LibNoDaveDataSource.Datablock
        myConn1.ReadValue(val)
        MsgBox(val.Value)
```


----------



## bool (7 Juni 2010)

Jochen Kühner schrieb:


> begnügt sie sich mit einer PDU???? Hä? ( siehe http://de.wikipedia.org/wiki/Protocol_Data_Unit ) Die PDUs sind Teil der Kommunikationstelegramme zur SPS.


 
Tut mir leid wenn ich da was durcheinander gebracht habe bzw. ggf. noch immer etwas auf dem Schlauch stehe?

Bislang arbeite ich nur mit einer libnodave.PDU Klasse zum lesen oder schreiben. Ich vermutete bislang, dass mit jeder libnodave.PDU für einen weiteren ReadRequest eine weitere Verbindung zur SPS aufgebaut wird aber ich glaube da war ich auf dem Holzweg oder?
Eine weitere (parallele) Verbindung zur SPS wird wahrscheinlich erst über eine weitere libnodave.Connection erzeugt, ist das richtig?

Gruss,

bool


----------



## bool (7 Juni 2010)

Jochen Kühner schrieb:


> Und man sollte mehrer Verbindungen zur gleichen Zeit aufbauen können....
> 
> Hier kurzes Codebeispiel:
> 
> ...


 
Ok, die libnodave.PDU hat nichts mit der Verbindung an sich zu tun.
Habs verstanden, danke für das Beispiel.


----------



## Jochen Kühner (7 Juni 2010)

bool schrieb:


> Ok, die libnodave.PDU hat nichts mit der Verbindung an sich zu tun.
> Habs verstanden, danke für das Beispiel.



Das Beispiel war jetzt nur für dich gedacht wenn du meine Lib nimmst!


----------



## bool (7 Juni 2010)

Jochen Kühner schrieb:


> Das Beispiel war jetzt nur für dich gedacht wenn du meine Lib nimmst!


 
Jup, werds ausprobieren und auch mal mit dem Aufbau von zwei Verbindungen zu zwei SPSen experimentieren, doch dazu wirds wahrscheinlich die Woche nicht mehr reichen.
Erst einmal möchte ich das zyklische Schreiben in die SPS optimieren, ggf unter Einbindung Deiner Connection Lib und dann werde ich mal noch mit dem TCP/IP über S7Online experimentieren.

Gruss und Danke nochmal für die bisherigen Hilfestellungen.

bool


----------



## Jochen Kühner (7 Juni 2010)

bool schrieb:


> Jup, werds ausprobieren und auch mal mit dem Aufbau von zwei Verbindungen zu zwei SPSen experimentieren, doch dazu wirds wahrscheinlich die Woche nicht mehr reichen.
> Erst einmal möchte ich das zyklische Schreiben in die SPS optimieren, ggf unter Einbindung Deiner Connection Lib und dann werde ich mal noch mit dem TCP/IP über S7Online experimentieren.
> 
> Gruss und Danke nochmal für die bisherigen Hilfestellungen.
> ...



Wenn du meine Lib nimmst und mehrere Variablen auf einmal schreibst, packt diese soviel Variablen wie möglich in eine PDU, nur wenn deine Variable größer ist als in eine PDU passt gibt's wahrscheinlich noch Probleme, aber wird von mir ab Do daran gearbeitet!


----------

