Perfomance Test mit vielen SPSen

[StevenGB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,

hat irgendjemand schonmal einen Perfomance-Test gemacht um DBs aus (S7-300)SPSen auszulesen? Ich müsste einen Prototyp (in C#) entwickeln, der DBs aus SPSen über TCP/IP ausliest und dabei die Zeit misst.
Es handelt sich dabei um ziemlich viele SPSen (um die 100), die jeweils 1-4DBs haben - mit im Schnitt 600Bytes. Diese liegen in den DBs ziemlich eng beieinander. Die konvertierte Form der Daten bräuchte ich (vorläufig) nicht. Es reichen mir die Daten als Byte Array.
Momentan bin ich daran die S7.NET (http://s7net.codeplex.com/), Libnodave und AGLink Libraries zu testen.

Erfahrungen damit:
- S7.NET: kaum, funktioniert irgendwie noch nicht für meine Test-Software SPSen.
- Libnodave: Ab ca 450Bytes reicht wohl die ReadBytes nicht mehr aus und ich muss zur readManyBytes zurückgreifen. Die "Read multiple items" Variante werde ich auch noch Testen. Nur sehe ich hier ein Problem mit dem Platt machen der Empfangen Daten. Da müsste ich dann mit einer extra Schleife drüber um die Daten über getU8() in ein Byte Array zu schreiben und das kostet Zeit.
- AGLink: hier werde ich die ReadDataBytes und ReadMixEx Funktion verwenden. Einmal in der Synchronen und einmal in der Asynchronen Variante. Bei beiden Funktionen lese ich immer den kompletten DB. Bin noch am überlegen ob ich nicht auch noch die Optimierte Version der ReadMixEx Funktion testen soll. Nur glaube ich das sich der Overhead der Optimierung nicht lohnt, da die Bytes in den DBs ziemlich eng beieinander liegen.

Für Tipps und Ratschläge wäre ich sehr dankbar.

Viele Grüße

 

[Jochen Kühner]

Du kannst noch meine Bibliothek verwenden, welche auf LibNodave aufsetzt: https://github.com/jogibear9988/DotNetSiemensPLCToolBoxLibrary. Darin gibt es auch ein Projekt "ReadSpeedtest" mit dem Ich schon die Lesezeit analysiert habe.

Du kannst ja die verbindungen zu allen 100 SPSen gleichzeitig aufbauen, daher sollte es geschwindigkeitsmäßig ja kein Problem sein!

 

[StevenGB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke. Schau ich mir gerade eben an.

Das Aufbauen der Verbindung wird kein Problem darstellen, aber das zyklische Abfragen. Ich möchte so viele wie möglich SPSen zyklisch in einer Zeit von 250ms abfragen. Das "ideale" Ziel wären 100SPSen, sprich in 250ms 100SPSen abfragen... und das wird schwierig (wenn nicht sogar unmachbar - kann ich noch nicht beurteilen, bzw. ich soll die Grenze finden)

 

[Rainer Hönle]

Wenn es sich um komplette DBs handelt dann genügt im Prinzip ein AGL_ReadMixEx mit allen DBs in einem Aufruf. Wenn sich keine Änderungen der DBs bzw. der Datnelängen ergeben, dann kann bei den optimierten Lesefunktionen einmal die Optimierung durchgeführt und anschließen nur noch gelesen werden. Dies bringt bei machen SPSen noch einmal einen geringen Performancevorteil von ca. 10 %.
Ob synchron oder asynchron gelesen wird, ist Geschmackssache. Beim asynchronen Lesen genügt in der Applikation ein Thread, dieser kann dann alle 100 SPSen parallel abfragen. Wenn synchron aufgerufen wird, dann kann dieser Thread die SPSen nur sequentiell verarbeiten. Aus diesem Grund empfehle ich die asynchrone Variante.
Das parallele Lesen aus weit über 100 SPSen ist mit ACCON-AGLink schon von mehreren Kunden zu deren vollsten Zufriedenheit getestet und implementiert worden. Solche Mengengerüste stellen für uns nichts Neues oder Ungewöhnliches dar.

 

[LowLevelMahn]

Ich hab auch sehr gute Erfahrungen mit AGLink bei >50 SPS gemacht
einfach die Funktionen als asynchrone starten und den AGLink-Jobmanager den Rest machen lassen

Bezüglich "Overhead der Optimierung": ohne Benchmarks von dir würde ich sagen deine SPS sind hier eher die Bremsen

 

[StevenGB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das sind doch mal erfreuliche Nachrichten. Wenn die Optimierung der der ReadMixEx nur einmal am Anfang stattfindet, fällt dieser Overhead nicht weiter ins Gewicht - die DBs dürften konstant bleiben.
Ich vermute mal es wird am Ende auf die Asynchrone Optimierte ReadMixEx hinauslaufen... werde aber noch ein paar Tests mit Libnodave durchführen (die S7.NET Librarie bekomm ich einfach nicht zum Laufen mit den Software SPSen)

Dann wird am Ende wohl das wegschreiben der gelesen Daten der Flaschenhals werden. Diese sollten noch in eine Datenbank oder in Files. Falls jemand damit schon Erfahrungen gesammelt hat - für Tipps bin ich gerne offen. Wonderware hat da eine ganz nette Lösung, aus Datenbankschemas und Files. Vielleicht gibt’s da ja schon was Ähnliches?

Vielen Dank.

 

[Thomas_v2.1]

Ich vermute mal es wird am Ende auf die Asynchrone Optimierte ReadMixEx hinauslaufen... werde aber noch ein paar Tests mit Libnodave durchführen (die S7.NET Librarie bekomm ich einfach nicht zum Laufen mit den Software SPSen)

Wenn du mit WinAC probierst dann funktioniert S7.net damit auch nicht. Das liegt daran dass die WinAC (warum auch immer) zwischendurch immer mal wieder über ISO fragmentierte Pakete schickt, und der ISO-Layer in S7.net überhaupt nicht zuverlässig ausgewertet wird. Ich würde von S7.net aus noch anderen Gründen die Finger lassen.

 

[Jochen Kühner]

Dann wird am Ende wohl das wegschreiben der gelesen Daten der Flaschenhals werden. Diese sollten noch in eine Datenbank oder in Files. Falls jemand damit schon Erfahrungen gesammelt hat - für Tipps bin ich gerne offen. Wonderware hat da eine ganz nette Lösung, aus Datenbankschemas und Files. Vielleicht gibt’s da ja schon was Ähnliches?

Vielen Dank.

Dazu gibts von mir z.B. dieses Tool http://www.sps-forum.de/werbung-und-produktneuheiten/46470-dotnetsimaticdatabaseprotokoller.html Der kann sich mit deinen ganzen SPSen verbinden und schreibt die Daten in beliebige Datenbanken!
Den Quellcode dafür bekommst du auch auf in meinem GitHub Projekt!

 

[StevenGB]

Zuviel Werbung?
-> Hier kostenlos registrieren

okay, dann werde ich mich nicht weiter mit S7 beschäftigen.

Wow, Jochen du warst wirklich fließig. Ich werde mir es im Verlauf der Woche mal anschauen.

Dankeschön.