libnodave und geschwindigkeit

[mabi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

zunächst einmal ein herzliches dankeschön an den/die Macher von libnodave. Ich teste die library seit zwei Tagen (unter .NET) und bin wirklich sehr angetan. Die Kommunikation mit einer cp5611 über s7online und einer 315er SPS funktioniert wirklich einwandfrei.
Nur ein großes Problem steht mir im Weg: Ich muss in meiner Anwendung (es geht um eine Simulation) auf eine große Menge Daten, die überall verstreut in der SPS liegen können, lesend und schreibend zyklisch zugreifen. Also Eingänge, Ausgänge, Merker und DBs.
Nun habe ich getestet, dass über Mpi das auslesen und schreiben von 200 MerkerBytes in jeweils einer Anforderung schon ca. 80ms dauert. Wenn ich nun zudem in 10DBs jweils 200 Byte lesen und schreiben will, und auch noch 200Byte Ein-/und Ausgänge dann komme ich ganz schnell auf eine minimale Zykluszeit von einigen Sekunden! Die Anwendung sollte aber nach Möglichkeit mit ca 0,5s laufen.

Selbst wenn ich in meiner Anwendung nur 200Bit benötige muss ich ja immer den ganzen Speicher einlesen, da diese 200Bit überall verteilt sein können. (ist in der Anwendung frei konfigurierbar).
Nur die benötigten Bytes auszulesen würde noch länger dauern, da noch mehr einzelne Anforderungen notwendig wären.


Nun ist die Frage: Es muss doch irgendwie auch eine schnellere Möglichkeit geben. WinCC beispielsweise kann doch auch sehr viele Variablen, die überall verstreut sein können, auslesen und schreiben und dabei trotzdem die Zykluszeiten einhalten... Liegt das an der Libnodave bzw. wäre es mit anderen (kostenpflichtigen) Tools eher schneller möglich? Oder über OPCServer?

Über Profibus (1,5Mbit)habe ich es übrigens auch schon probiert, ist aber auch nur knapp doppelt so schnell...


Gruß

 

[Zottel]

zunächst einmal ein herzliches dankeschön an den/die Macher von libnodave. Ich teste die library seit zwei Tagen (unter .NET) und bin wirklich sehr angetan. Die Kommunikation mit einer cp5611 über s7online und einer 315er SPS funktioniert wirklich einwandfrei.

Danke!

Nur ein großes Problem steht mir im Weg: Ich muss in meiner Anwendung (es geht um eine Simulation) auf eine große Menge Daten, die überall verstreut in der SPS liegen können, lesend und schreibend zyklisch zugreifen. Also Eingänge, Ausgänge, Merker und DBs.
Nun habe ich getestet, dass über Mpi das auslesen und schreiben von 200 MerkerBytes in jeweils einer Anforderung schon ca. 80ms dauert.

Kann ich jetzt nicht testen, aber das Testprogramm testS7online kann mittels der Option -b einen Benchmark durchführen. Probier es einmal aus und poste das Ergebnis. Dabei werden folgende Tests jeweils 100x ausgeführt:
- 1 Byte lesen
- Einen großen Block (typisch 200 Byte) lesen
- Verteilte Variablen (5 oder 6 Stück) durch eine einzige Anforderung lesen
Ein typischer Wert für den 2. Test mit einem NetLink/IBH-Link ist 5-6 Sekunden mit einer CPU 315, so daß 55ms zu schaffen wären. Der CP5611 selbst wird da keinesfalls langsamer sein. Es kann gut sein, daß die Anbindung von Libnodave an die s7online.dll suboptimal ist.

Wenn ich nun zudem in 10DBs jweils 200 Byte lesen und schreiben will, und auch noch 200Byte Ein-/und Ausgänge dann komme ich ganz schnell auf eine minimale Zykluszeit von einigen Sekunden! Die Anwendung sollte aber nach Möglichkeit mit ca 0,5s laufen.

Schreiben mußt du ja eventuell nur, wenn sich auf der PC-Seite ein Wert ändert. Wenn da ein Mensch einzelne Einstellungen vornimmt, wird es unteri 1 Variable/500ms bleiben.

Selbst wenn ich in meiner Anwendung nur 200Bit benötige muss ich ja immer den ganzen Speicher einlesen, da diese 200Bit überall verteilt sein können. (ist in der Anwendung frei konfigurierbar).

An dieser Stelle würde ich dir raten, die Konfiguration an das SPS-Programm zu übermitteln und dieses die zu lesenden Bits in einem Übergabe-Speicherbereich kopieren zu lassen.

Nur die benötigten Bytes auszulesen würde noch länger dauern, da noch mehr einzelne Anforderungen notwendig wären.

Nun ist die Frage: Es muss doch irgendwie auch eine schnellere Möglichkeit geben.

Das bezweifel ich.

WinCC beispielsweise kann doch auch sehr viele Variablen, die überall verstreut sein können, auslesen und schreiben und dabei trotzdem die Zykluszeiten einhalten...

Das bezweifel ich wieder, jedenfalls wenn diese Zykluszeiten im Millisekunden-Bereich liegen.

Liegt das an der Libnodave bzw. wäre es mit anderen (kostenpflichtigen) Tools eher schneller möglich? Oder über OPCServer?

Alle diese Tools benutzen das gleiche Übertragungsprotokoll. Dieses begrennzt die Länge von Anfrage und Antwort auf die PDU-Länge (240 Byte bei 315). Darin sind Protokoll-Overhead und Nutzdaten unterzubringen.
Die Anfrage wird abgeschickt und auf die Antwort der CPU gewartet. Anfrage kann nach mehreren Variablen an unterschiedlichen Adressen fragen, aber auf Kosten der Nutzdatenlänge in der Antwort, da für jede Variable Typ und Längeninformationen mit zurückgeliefert werden. Das einzige, was ein gutes Tool da machen könnte, ist genau auszurechnen, welche Verteilung auf mehrere Anfragen optimal ist. Z.B. ist es günstiger 12 Byte ab MD0 in einem Rutsch zu lesen, wenn MD0 und MD8 benötigt werden.
WinCC als HMI-Tool wird auch den Bildschirm nicht öfter als alle 500 bis 1000 ms neu aufbauen. Eventuell könnte es je nach angezeigtem Bild nur die tatsächlich benötigten Werte lesen.

 

[mabi]

Zuviel Werbung?
-> Hier kostenlos registrieren

danke für deine schnelle und eingehende Antwort!

Ein typischer Wert für den 2. Test mit einem NetLink/IBH-Link ist 5-6 Sekunden mit einer CPU 315, so daß 55ms zu schaffen wären. Der CP5611 selbst wird da keinesfalls langsamer sein. Es kann gut sein, daß die Anbindung von Libnodave an die s7online.dll suboptimal ist.

das Benchmark hatte ich auch schon laufen lassen. Ich weiß die genauen Werte momentan nicht mehr auswendig aber der zweite Wert lag glaube ich sogar knapp unter 5s. Die erwähnten 80ms waren auch für schreiben UND Lesen von JEWEILS 200Byte. Also nur lesen waren um die 40ms. Eigentlich also durchaus ein "guter" Wert, nur für meinen Anwendungsfall eben nicht gut genug

Schreiben mußt du ja eventuell nur, wenn sich auf der PC-Seite ein Wert ändert. Wenn da ein Mensch einzelne Einstellungen vornimmt, wird es unteri 1 Variable/500ms bleiben.

leider nein, denn die Variablen werden nicht bzw. nicht nur durch Menschliche Bedienung sondern auch durch automatische Vorgänge verändert.

Alle diese Tools benutzen das gleiche Übertragungsprotokoll. Dieses begrennzt die Länge von Anfrage und Antwort auf die PDU-Länge (240 Byte bei 315). Darin sind Protokoll-Overhead und Nutzdaten unterzubringen.
Die Anfrage wird abgeschickt und auf die Antwort der CPU gewartet. Anfrage kann nach mehreren Variablen an unterschiedlichen Adressen fragen, aber auf Kosten der Nutzdatenlänge in der Antwort, da für jede Variable Typ und Längeninformationen mit zurückgeliefert werden. Das einzige, was ein gutes Tool da machen könnte, ist genau auszurechnen, welche Verteilung auf mehrere Anfragen optimal ist. Z.B. ist es günstiger 12 Byte ab MD0 in einem Rutsch zu lesen, wenn MD0 und MD8 benötigt werden.
WinCC als HMI-Tool wird auch den Bildschirm nicht öfter als alle 500 bis 1000 ms neu aufbauen. Eventuell könnte es je nach angezeigtem Bild nur die tatsächlich benötigten Werte lesen.

Ok, da wird mir wohl nichts anderes übrig bleiben, also in meinem Programm auch zu versuchen eine optimale Verteilung hinzubekommen und mich notfalls evtl mit Zykluszeiten von 1s zufrieden zu geben. Ich glaube du hast recht und WinCC liest tatsächlich nur die benötigten Werte, wobei diese ja auch quer im Speicher verteilt liegen können...
Werde morgen auch mal noch schauen wieviel es noch bringt, den Profibus auf 12MBit hochzujagen. (dürfte dem Libnodave über s7online ja egal sein, oder?)

 

[Zottel]

Die Profibus-Baudrate ist Libnodave egal. Ob es gegenüber 1,5MBit etwas bringt siehst du ja.
Das Problem liegt eher in folgendem:
1. Die CPU braucht recht lange für die Antwort. Probier mal:
1.1. Die typische Einstellung 20% Zeit/Leistung für Kommunikation zu erhöhen. Ich habe es noch nie probiert...
1.2. Einen Benchmark starten und während er läuft einen zweiten in einem zweiten Fenster. Sie werden langsamer, aber wenn ich mich recht erinnere, ist die Summe der pro Zeit empfangenen Telegramme größer als bei einem einzelnen Test. Das könnte ein Programm nutzen, indem es mehrere Verbindungen aufmacht und darauf gleichzeitige Anfragen absetzt. Allerdings hat Libnodave in Verbindung mit S7online und mehreren Verbindungen Probleme...
1.3. Die S7-Kommunikation läuft auf dem Profibus mit niedriger Priorität, wenn sonst nichts zu tun ist und die CPU den Token hat. Daher ist es günstig, wenn keine weiteren Master, noch günstiger keine weiteren Teilnehmer als CPU und CP5611 dran hängen. Eventuel ließe sich mit den PB-Timing-Parametern was rausholen, aber da fehlt mir im Augenblick der Überblick.
1.4 Versuch es mit einer Siemens-CPU mit integrierter Ethernet-Schnittstelle oder einer VIPA-CPU.

 

[mabi]

ja die Baudrate auf 12Mbit hat nur noch wenig gebracht. (ca. 0,2s im Benchmark.

Ich habe heute nocheinmal alle Möglichkeiten, die ich momentan zur Verfügung habe, mit Benchmark durchgetestet.
Der zweite Wert war ca.:
CP5611 über MPI: 4,7s
CP5611 über DP(1,5Mbit): 2,7s
CP5611 über DP(12Mbit): 2,5s
Ethernet mit CP343-1: 4,8s
Ethernet ist also sogar etwas langsamer als MPI. Liegt aber wohl am Rückwandbus.

Werde mich jetzt wohl mit der Profibus-Variante zufriedengeben und in meinem Programm versuchen, die jeweils benötigten Daten in geschickte Blöcke zu zerlegen.

 

[hovonlo]

Zuviel Werbung?
-> Hier kostenlos registrieren

So rein interessehalber 'ne Frage zu deiner Messung "Ethernet mit CP343-1: 4,8s":
Was war das denn für ein Ethernet-CP? Extern über den Bus angebunden vermute ich mal - die Geschwindigkeit ist innerhalb der Toleranz identisch zu MPI.

Zottel hatte von Siemens CPUs mit integriertem Ethernet bzw. Vipa Speed7 gesprochen, da geht die interne Kommunikation - weil anderer Bus - deutlich schneller.

 

[argv_user]

...
Zottel hatte von Siemens CPUs mit integriertem Ethernet bzw. Vipa Speed7 gesprochen, da geht die interne Kommunikation - weil anderer Bus - deutlich schneller.

Mal unabhängig von libnodave bin ich daran interessiert zu erfahren,
ob es Siemens-CPUs der 300er Bauform mit interner TCP gibt, die den Transfer
wirklich schneller abwickeln als die Kombi CPU+CP343. Nachweislich, nicht
vermutlich.

 

[Rainer Hönle]

Mal unabhängig von libnodave bin ich daran interessiert zu erfahren,
ob es Siemens-CPUs der 300er Bauform mit interner TCP gibt, die den Transfer
wirklich schneller abwickeln als die Kombi CPU+CP343. Nachweislich, nicht
vermutlich.

Im Prinzip ja. Nun mal Spaß beiseite. Die Siemens-CPUs mit integrierter Ethernet-Schnittstelle sind bei kurzer Zykluszeit wirklich deutlisch schneller als die Kombination CPU + CP. Geht aber die Zykluszeit nach oben, dann ist irgendwann die Kombination CPU + CP schneller. Das Ganze hängt aber nebenbei noch von so Kleinigkeiten wir Firmwareversion etc. ab. Ich habe hierzu schon die verschiedensten SPSen und CPs in den Fingern gehabt. Grundsätzlich gilt: Soll die Kommunikationsleistung hoch sein, dann muss man sich den Einsatz einer 400er überlegen.
Zu den Vipa-SPSen kann ich derzeit noch nichts sagen, da ich diese noch nicht getestet habe und somit nicht in den Reigen der Siemens-Steuerungen bezüglich Kommunikationsleistung einordnen kann.

 

[argv_user]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Rainer,

erstmal vielen Dank für den Beitrag.

Das ist kein Spaß. Ich bin da echt noch auf der Suche.
Es geht um eine mobile Anwendung, die in "Echtzeit" auf Daten
vom PC reagieren soll; quasi wie auf Analogeingänge, nur dass
die Daten vom PC geliefert werden.
TCP muss aber sein (lt. Kunde).

Und die 400er scheidet leider aus Platzgründen aus, obwohl sie ja
viel schneller als die 300 ist.

Naja, vielleicht ergibt sich ja noch was.

 

[Rainer Hönle]

Was bedeutet in diesem Zusammenhang Echtzeit? Ich denke Du must innerhalb einer bestimmten Zeit eine Reaktion haben. Wie lang ist diese Zeit maximal? Muss es wirklich TCP/IP sein oder genügt Ethernet? Hintergrund: Vielleicht gibt es eine Software auf dem PC die als PNIO-Device agiert. Mit einer PN-CPU hättest Du dann mit Sicherheit eine sehr schnelle Reaktion. Und wenn mit mobil auch wireless gemeint ist, dann sind diese Komponenten ebenfalls verfügbar.

 

[argv_user]

"Echtzeit" ist ja immer relativ: heißt hier, etwa 20 mal pro Sekunde
ein Telegramm von etwa 10 Bytes in die SPS zu
übertragen. Klingt hart, und ob es wirklich nötig ist,
kann ich nicht beurteilen. Jedenfalls ist das mit CPU+343 nicht machbar,
wenn zwischendurch auch noch ein Status abgefragt werden soll...

 

[Rainer Hönle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei einer 318er würde das nicht sofort ablehnen. Aber bis zur 315 (PN ausgenommen) kann es sehr eng werden. Wäre die PN-Geschichte keine Alternative?
[Werbung]Oder mit dem NetLink PRO auf den Profibus mit entsprechend hoher Geschwindigkeit gehen. Profibus on Board ist deutlich schneller als TCP/IP über Rückwand. Der NetLink Pro wird auch über TCP/IP angesprochen und kann sogar das CP-Protokoll.[/Werbung]

 

[argv_user]

Hallo Rainer, ich werde diesbezüglich mit dem Kunden
nochmal Rücksprache halten. Ich hatte das Thema ja schonmal in
einem anderen Thread angesprochen, allerdings gab es damals
kein wirkliches Resultat: der Netlink Pro wurde vom Kunden nicht
akzeptiert... ("Fremdhersteller").

Besser wäre eben eine CPU mit TCP, die da noch mitkommt.

 

[blaubaer]

Wir haben für eine derartige Anwendung eine VIPA Speed7 eingesetzt, das Ganze über die eingebaute Ethernet Schnittstelle der VIPA. Bitte jetzt nicht hauen, aber bei einem improvisierten Benchmarktest (100 Variablen im DB vom PC beschreiben lassen, danach das gleiche von der S7 usw. usw.) war die VIPA ca. 20 mal schneller als das "Vergleichsnormal" 315-2AG10. Das entsprach ungefähr dem Verhältnis der Zykluszeiten (auch nur geschätzt, nicht wissenschaftlich haltbar).
Wenn man sich bewusst ist, das man sich mit der kryptischen Hardwarekonfig rumärgern muss, das die VIPA sich beim Aufstarten auch ganz selten mal "ziert" und wenn man dem Endkunden von der Unausweichlichkeit des VIPA-Einsatzes überzeugt hat (Alternative: mind. 416-2), ist die SPEED7 für solche Anwendungen schon Spitze. Wenn möglich, einfach mal testen.

 

[marcengbarth]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast du denn die folgenden LibNoDave-Funktionen schon ausprobiert???

davePrepareReadRequest();
daveAddVarToReadRequest();
daveExecReadRequest();