Performance PUT/GET Verbindung

MW

Level-1
Beiträge
1.186
Reaktionspunkte
272
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab mal ne Frage an die Kommunikationsspezi's

ich habe als Beispiel folgenden Aufruf des SFB14:
Code:
      CALL  "GET" , DB14
       REQ   :=#req_get
       ID    :=#con_ID
       NDR   :=#get_ndr
       ERROR :=#get_err
       STATUS:=#get_stat
       ADDR_1:=P#DB99.DBX 0.0 BYTE 4
       ADDR_2:=P#DB99.DBX 16.0 BYTE 16
       ADDR_3:=P#DB99.DBX 40.0 BYTE 32
       ADDR_4:=
       RD_1  :=P#DB19.DBX 0.0 BYTE 4
       RD_2  :=P#DB19.DBX 16.0 BYTE 16
       RD_3  :=P#DB19.DBX 40.0 BYTE 32
       RD_4  :=
Dieser läuft, wie der Kenner auf anhieb sieht, auf einer S7-400. Der Baustein soll aus einem DB der Partner Station 3 Datenbereiche auslesen, die auch noch im gleichen DB liegen(die dazwischen liegenden Bytes sind auf beiden Seiten unbenutzt). Nun hat die Steuerung an sich schon eine hohe Kommunikationslast bzw. ist das Netzwerk recht lahm, aus diesem Grund frage ich mich, ob folgender Aufruf nicht effizienter wäre:
Code:
      CALL  "GET" , DB14
       REQ   :=#req_get
       ID    :=#con_ID
       NDR   :=#get_ndr
       ERROR :=#get_err
       STATUS:=#get_stat
       ADDR_1:=P#DB99.DBX 0.0 BYTE 80
       ADDR_2:=
       ADDR_3:=
       ADDR_4:=
       RD_1  :=P#DB19.DBX 0.0 BYTE 80
       RD_2  :=
       RD_3  :=
       RD_4  :=
Von der Funktion her ist dieser Aufruf gleichwertig.
Nun zum Wichtigen:

Hat jemand die möglichkeit sich solch eine Kommunikationsverbindung per Wireshark anzusehen oder hat das schon getan
und kann mir folgende Fragen beantworten:

- Gehen bei der ersten Variante 3 einzelne Anfragen an die Partner CPU, oder packt er das alles in eine Anfrage ?
- Wenn dafür 3 einzelne Anfragen nötig sind, geht das dann immer synchron (Anfrage 1 -> Antwort 1 -> Anfrage 2 -> Antwort 2......) oder geht das Asynchron (Anfrage 1 -> Anfrage 2 -> Anfrage 3 -> Antwort......) ?
- Kurz und knapp: Ist Variante 2 schneller/Resourcenschonender als Variante 1 ?

Bitte keine Vermutungen aufstellen, die habe ich selber kann sie nur nicht bestätigen ;-)
 
Kannst du das nicht mal mitschneiden? Eine 400er ist mittlerweile leider so selten im Einsatz.

Du wolltest zwar keine Vermutung, aber...
Ich habe mir den Datenaustausch mit Put/Get und einer S7-400 noch nicht angesehen, aber aus den Angaben zur möglichen Nutzdatenlänge in der Bausteinbeschreibung kann man einiges ableiten.
Da sich laut den Angaben dort die mögliche Nutzdatenlänge um jeweils 16 Byte pro Put-Befehl verringert, kann man eigentlich davon ausgehen dass alle 4 Datenbereiche in ein Telegramm gepackt werden. Denn das ist genau die Anzahl an Bytes die pro Bereichsangabe hinzukommen (12 Bytes Parameterteil für Adressbereich + 4 Bytes Kopf im Datenteil für die zu schreibenden Daten).

Warum dort bei einem Get-Befehl dieses pro Datenbereich nur 4 Bytes weniger sein sollen will mir nicht einleuchten, das sollten eigentlich 12 Bytes sein.
Genau aus dem Grund wäre es interessant da mal einen Mitschnitt zu bekommen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Meines Wissens nach entspricht Get/Put dem Lesen/Schreiben von Variablen wie es auch z. B. in libnodave enthalten ist (mit wireshark log kann ich es genau sagen). Im ersten Fall ist somit der Request ein bischen länger, im zweiten Fall der Response. Es passt aber immer ales in eine PDU. Somit dürften sich quasi keine Zeitunterschiede ergeben, denn die Länge eines Paketes geht minimal in die Performance ein. Dramatischer sind da die Sprünge wenn eine zusätzliche PDU gebraucht wird.
 
Warum dort bei einem Get-Befehl dieses pro Datenbereich nur 4 Bytes weniger sein sollen will mir nicht einleuchten, das sollten eigentlich 12 Bytes sein.

Das mit den 4 Bytes passt, da die Adressangabe ja nur in den Anfrage und nicht in der Antwort ist.
Also sieht es rein von den Zahlen auch so aus als ob die Kommunikation bei put/get wie z.B. libnodave arbeitet.
 
erstmal danke für die Antworten.
Ich muss dann wohl doch mal versuchen ob ich von der Kommunikation einen Log bekomme, dass wird zwar nicht so einfach klappen, aber zumindest sehe ich dann auch gleich wie groß die Kommunikationslast der Steuerung ist. Es handelt sich übrigens um eine Microbox, hab mich da im ersten Beitrag vertan.
 
Zurück
Oben