S7 / libnodave / Framelänge größer 240 Bytes

foreach

Level-1
Beiträge
12
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo !

Ich bin neu hier in diesem Forum und komme eher von der PC-Seite. Hier habe ich eine Anwendung geschrieben, die mittels libnodave und ISO over TCP Daten aus der SPS holt. Die Daten liegen in der SPS in einem DB hintereinander (ca. 8k). Leider bekomme ich diese Daten nur in 222 Byte (240 - 18 HeaderBytes) Häppchen über die libnodave-Funktion ReadManyBytes. Dadurch brauche ich für die 8k ca. 350ms. Ich vermute, daß es deutlich schneller gehen würde, wenn ich die Daten in größeren Paketen holen könnte. Allerdings scheint libnodave die Paketgröße mit der SPS auszuhandeln.
Kennt jemand eine Möglichkeit mehr als 240 Bytes pro Aufruf zu holen ?
Zur Not könnte auch die SPS die Initiative übernehmen. Schöner wäre es allerdings wenn ich vom PC pollen könnte.
Ich bin nicht auf libnodave angewiesen und bin für alles offen. Wichtig ist, daß ich die Daten schneller brauche.

Über Antworten würde ich mich sehr freuen !

Bis dann

Christof
 
Das geht über das S7 Protokoll nicht anderst. Zumindest bei einer 300er. Eine 400er CPU kann auch 480 Byte große Pakete!

Da musst du wohl auf der PLC eine TCP/IP Verbindung aufbauen, da gehen dann auch großere Pakete (die größe hängt wiederum auch vom CP/CPU ab)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was ich mir noch vorstellen könnte, wenn du mehrere Anfragen gleichzeitig losschickst, vielleicht würde das ein Geschwindigkeitsschub bringen (weiss aber nicht ob das so ist). Thomas_V2.1 hat hier : http://www.sps-forum.de/showthread.php/28292-Wireshark-Plugin-für-S7-Protokoll?p=412017#post412017 dazu was geschrieben. Das ist aber in libnodave nicht implementiert, aber vielleicht hat ja Deltalogic was in der Richtung in AGLink.
Oder du nutzt die Abfrage bei der die SPS von selbst automatisch die Daten schickt (geht auch nicht mit libnodave, aber AGLink hat das drinn), aber wieviel Bytes da gehen weiss Ich auch nicht!
 
Hallo !

Danke erstmal für die Antwort.
Wichtig wäre erstmal, daß überhaupt größere Frames gehen, da ich hier den größten Flaschenhals vermute. Ich muß die 8K jetzt nicht unbedingt am Stück lesen aber 1K Blöcke würden es wohl auch tun.
Wie gesagt, da ich mehr von der PC-Seite komme weiß ich jetzt nicht, was es für einen Aufwand bedeutet auf der SPS eine TCP Verbindung aufzubauen. Gibt es da keine fertigen Bausteine ? Es dürfte auch Geld kosten. Das ist nicht das Problem.

Gruß

Christof
 
Auf der S7 ist das kein großer Act. Es gehen auf jeden Fall größere Frames, das muss dann aber halt aktiv von der SPS angestoßen werden. Bei aktuellen CPs kann eine Telegramm bis zu 8192 Bytes groß sein!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hast du da mal ein Link zu wie man sowas SPS-seitig integriert.
Das Problem dabei ist, daß ich diese Aufgabe delegieren muß und ich nicht weiß wie es geht.

Den anderen Vorschlag mit dem gleichzeitigen/paralellem Zugriff setze ich gerade um. Ich melde mich wenn es fertig ist und wenn ich Geschwindigkeits-Messergebnisse habe.

Bis dahin

Christof
 
Hast du da mal ein Link zu wie man sowas SPS-seitig integriert.
Das Problem dabei ist, daß ich diese Aufgabe delegieren muß und ich nicht weiß wie es geht.

Den anderen Vorschlag mit dem gleichzeitigen/paralellem Zugriff setze ich gerade um. Ich melde mich wenn es fertig ist und wenn ich Geschwindigkeits-Messergebnisse habe.

Bis dahin

Christof

Wie setzt du das mit dem Paralellen zugriff den um? (da dies in LibNodave ja nicht implementiert ist)...
Was für eine CPU hast du den ?? eine P-CPU oder nutzt du einen CP? Weil je nach dem sind es unterschiedliche Bausteine die man auf der SPS verwenden muß! Wobei es bei einem CP einfacher ist, da man die Verbindung in NetPro Projektiert, und auf der SPS einfach nur noch den Baustein AG_SEND aufrufen muß (Mit einem Zeiger auf die zu sendenden Daten!)!
 
Ich bastel mir jeweils einen Thread um eine libnodave connection und instanziere das Ganze dann z.B. 5 Mal.
Die Threads laufen dann parallel holen dann jeweils einen Block von der SPS. Danach sind sie wieder frei und holen den nächsten zu holenden Block. Bis alle Blöcke da sind.
Wie gesagt, wenn ich Meßergebnisse habe melde ich mich.

Zur SPS: Wir haben alle möglichen S7-Typen im Einsatz. Je nach Kunde und Budget.

Gruß,

Christof
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zu prüfen ist allerdings, ob das Protokoll wirklich dadruch schneller wird, dass man bei der Datenmenge mehr als eine PDU angeben kann. Denn intern müssen die Daten in Häppchen übertragen werden. Bin mal auf die Ergebnisse gespannt.
btw: BSEND kann ebenfalls größere Pakete übertragen, allerdings intern auch nur in Häppchen. Diese Funktion wird allerdings nur von ACCON-AGLink und nicht von libnodave unterstützt.
 
Zu prüfen ist allerdings, ob das Protokoll wirklich dadruch schneller wird, dass man bei der Datenmenge mehr als eine PDU angeben kann. Denn intern müssen die Daten in Häppchen übertragen werden. Bin mal auf die Ergebnisse gespannt.
btw: BSEND kann ebenfalls größere Pakete übertragen, allerdings intern auch nur in Häppchen. Diese Funktion wird allerdings nur von ACCON-AGLink und nicht von libnodave unterstützt.

Aber für BSEND muss Ich ja auf der SPS auch was programmieren, oder? Dann kann man ja auch TCP verwenden.

Kann es sein das mit Fetch/Write auch nur DBs bis 255 gehen (hab mir grad mal die Doku auf http://proj-isolde-controls.web.cern.ch/proj-isolde-controls/Documents/fetchwrite.pdf angesehen) da nur ein Byte für die DB Nummer verwendet wird?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Projekt für mich erfolgreich beendet

Hallo,

ich hatte ja angekündigt mich nochmal zu melden, wenn ich den Parallelzugriff abgeschlossen habe.
Ich benutze jetzt 12 Windows-Threads (konfigurierbar), wovon jeder einzelne eine Verbindung zur SPS über die libnodave.dll offen hält.
Mein Test DB ist 8096 Bytes lang. Diesen "zerlege" ich in 222 Byte große Blöcke (240 - 18) und weise jeder Verbindung (Thread) die Blöcke zu die sie lesen soll.
Ich verteile also 37 Blöcke auf 12 Verbindungen.
Das Lesen aller Blöcke dauert so nur noch 77 ms.
Ohne Parallelzugriff waren es um die 250ms.
Ich bin also um Faktor 4 schneller geworden. Das reicht mir !
Selbst wenn man nicht so viele Verbindungen offen halten will/kann bringen sogar 4 parallele Verbindungen eine deutliche Verbesserung auf 106 ms !
Vorteilhaft sind parallele Verbindungen vor allem, wenn die Bytes nicht alle schön hintereinander im DB liegen sondern wild verstreut über mehrere DB's.
Dann kann der Verbesserungs-Faktor noch größer werden, da die zu lesenden Blöcke vermutlich kleiner sind als 222 Bytes.

Gruß,

Christof
 
Zurück
Oben