# Realtime mit libnodave



## Nobby37 (19 April 2010)

Hallo,

ich bin neu hier und habe folgendes "kleines" Problem:

Ich habe eine Anwendung in C++ unter MS Visual Studio 9 mit der Library libnodave implementiert, um in Realtime (dh. 10 ms) mit einer Siemens S7 zu kommunizieren. Der Austausch eines Datenblock von 128 Byte in einen SPS Datenblock funktioniert auch ganz toll, aber leider dauert das Schreiben mit daveWriteBytes ca. 25 ms. Anscheinend wartet die Funktion auf eine Antwort von der SPS. Wie kann man dies noch beschleunigen?

Danke schon mal im Voraus für eventuelle Antworten

Norbert


----------



## MW (19 April 2010)

Von welchem Zugriffsweg sprechen wir hier ? (Ethernet, MPI, Profibus)


25ms halt ich persönlich schon für recht flott und bezweifele, dass das noch schneller geht. Wie ist eigentlich die Zykluszeit deiner SPS ?, denn desto kürzer die ist umso schneller bearbeitet die SPS dann auch die anstehenden Kommunikationsaufträge. 

Und ja, die Funktion wartet auf eine Antwort von der Steuerung, dass geht aber auch nicht anders.


----------



## Nobby37 (19 April 2010)

*Kommunikationsprotokoll*

Das habe ich fast befürchtet. Das Protokoll ist übrigens "ISO on TCP", was ich implementieren sollte, weil das normale TCP zu langsam war. Die Zykluszeit der SPS soll bei 5-10 ms liegen.
Was könnte man denn Alternativ verwenden. Ist Profibus schneller?

VG,

Norbert


----------



## Rainer Hönle (20 April 2010)

Realtime ist mit einer solchen Zugriffsart nicht machbar. Es kann einfach nicht vorausgesagt werden, wie groß die maximale Zeit für die Kommunikation ist. Da spricht schon der verwendete Kommunikationsweg (TCP/IP) dagegen. Auch führen Zykluszeitschwankungen zu Kommunikationszeitschwankungen.
Wenn es darum geht, die Daten möglichst in einer bestimmten Zeit zu erhalten, dann kann das funktionieren. Wenn es wirklich 10 ms beim Lesen sind, dann kommt eine 300er-PN-CPU zum Einsatz. Und die ist empfindlicher auf Zykluszeitschwankungen als eine separate CP. 
Was steckt denn eigentlich genau hinter den Anforderunge? Warum muss denn der komplette Block nach 10 ms da sein? Was passiert dann mit den Daten? Wie wäre es, wenn die SPS den Block nur bei Veränderung schickt?


----------



## LowLevelMahn (20 April 2010)

*ich denke Realtime = ganz ganz schnell*

ich glaube nicht das hier eine Echtzeitanforderung vorliegt - eher soll eine sehr schnelle Reaktion erreicht werden - möglicherweise hat er ja mehrere SPS zum Abfragen und verbraucht zu viel Zeit mit dem Einzelwarten - wie wärs mit einer asynchronen Lösung 

Wikipedia sagt "Ist die Dauer eines Vorgangs (auch eine Wartezeit) vorhersehbar, dann  spricht man von Echtzeit" - also auch 1 Jahr auf den Block zu warten ist Echtzeit - solange das ganze vorhersehbar ist


----------



## Nobby37 (20 April 2010)

LowLevelMahn schrieb:


> ich glaube nicht das hier eine Echtzeitanforderung vorliegt - eher soll eine sehr schnelle Reaktion erreicht werden - möglicherweise hat er ja mehrere SPS zum Abfragen und verbraucht zu viel Zeit mit dem Einzelwarten - wie wärs mit einer asynchronen Lösung
> 
> Wikipedia sagt "Ist die Dauer eines Vorgangs (auch eine Wartezeit) vorhersehbar, dann  spricht man von Echtzeit" - also auch 1 Jahr auf den Block zu warten ist Echtzeit - solange das ganze vorhersehbar ist



Die Anwendung ist wie folgt: Ein Messsystem ermittelt die Position von einem beweglichen Objekt und die SPS soll eine Hardwareplattform entsprechend nachführen. Ist das Realtime genug? 

Ist das warten auf die Antwort der SPS zwingend in ISO on TCP implementiert oder kann man auch mit "fire and forget" senden?


----------



## argv_user (20 April 2010)

Nobby37 schrieb:


> Das habe ich fast befürchtet. Das Protokoll ist übrigens "ISO on TCP", was ich implementieren sollte, weil das normale TCP zu langsam war.



Kann ich mir nicht vorstellen, das dadurch irgendetwas schneller wird.
Allein wenn ich bedenke, dass ISO-on-TCP gegenüber TCP-Native zusätzlichen Protokoll-Overhead bedeutet.


----------



## Rainer Hönle (20 April 2010)

Nobby37 schrieb:


> Die Anwendung ist wie folgt: Ein Messsystem ermittelt die Position von einem beweglichen Objekt und die SPS soll eine Hardwareplattform entsprechend nachführen. Ist das Realtime genug?


Dies ist nach der Definition von Realtime keine Realtime. Denn sonst müsste die maximale Zeit bestimmt werden können, in dem der Vorgang garantiert erledigt ist. Hier geht es wohl eher darum so schnell wie möglich zu sein.



> Ist das warten auf die Antwort der SPS zwingend in ISO on TCP implementiert oder kann man auch mit "fire and forget" senden?


Das Warten hat nichts mit Iso on TCP zu tun sondern mit dem darin enthaltenen Siemens-Protokoll.

Wo liegt der Schwerpunkt? Im Lesen der Daten oder im Schreiben? Was kommt genau für eine Hardware zum Einsatz? Ist die fix oder kann die für die Anforderungen noch "optimiert" werden? Welche Zeit darf systembedingt garantiert nicht überschritten werden?


----------



## Nobby37 (20 April 2010)

Rainer Hönle schrieb:


> Dies ist nach der Definition von Realtime keine Realtime. Denn sonst müsste die maximale Zeit bestimmt werden können, in dem der Vorgang garantiert erledigt ist. Hier geht es wohl eher darum so schnell wie möglich zu sein.
> 
> Also, natürlich so schnell wie möglich und max. 10 ms
> 
> ...



Der Schwerpunkt liegt in der Übertragung der Position von dem Messsystem an die SPS. Es wird eine Siemens S7 CPC 319-3PN/DP und eine CP 343-1 card bzw. Windows XP eingesetzt.


----------



## Rainer Hönle (20 April 2010)

Wofür wird die PN-Schnittstelle verwendet und wofür die CP?


----------



## argv_user (20 April 2010)

Nobby37 schrieb:


> Ist das warten auf die Antwort der SPS zwingend in ISO on TCP implementiert oder kann man auch mit "fire and forget" senden?



Es wird hier immer auf das Antworttelegramm gewartet. Wie Rainer Hönle
schon sagte hängt das am Siemens-Protokoll.

Es gibt aber auch noch UDP. Vielleicht kannst Du damit schnellere Kommunikation erreichen, da hier der TCP-Overhead wegfällt. Ich bin mir da aber nicht sicher. UDP ist eventuell in LibNoDave garnicht implementiert, eher in Prodave, oder im entsprechenden Produkt von Deltalogic.

Eine weitere Möglichkeit bietet vielleicht auch die Verwendung von "send/receive".


----------



## LowLevelMahn (20 April 2010)

*die lesezeiten wirst du nur schwerlich unterschreiten*

aber möglicherweise kannst du uns ja sagen wie die Daten aussehen und wer diese benutzt (und wer das was pollend liest)

also

Messystem <---> SPS-DB? <---> CP 343 <-> Windows XP <--> Achse?

möglicherweise kann man die Wege verkürzen und weniger pollen

also warum geht das nicht

Messsystem <--> SPS <--> Achse?


----------



## Nobby37 (20 April 2010)

Rainer Hönle schrieb:


> Wofür wird die PN-Schnittstelle verwendet und wofür die CP?



Die PN-Schnittstelle ist für andere Anwendungen und die CP für der erwänhnte Messsystem.


----------



## Nobby37 (20 April 2010)

argv_user schrieb:


> Kann ich mir nicht vorstellen, das dadurch irgendetwas schneller wird.
> Allein wenn ich bedenke, dass ISO-on-TCP gegenüber TCP-Native zusätzlichen Protokoll-Overhead bedeutet.



Das sehe ich genauso, war eine Aussage vom Siemens Support.


----------



## Rainer Hönle (20 April 2010)

Nobby37 schrieb:


> Die PN-Schnittstelle ist für andere Anwendungen und die CP für der erwänhnte Messsystem.



Und welche Anforderungen haben die anderen Anwendungen? Die PN-Schnittstelle ist bei der genannten SPS-Zykluszeit deutlich schneller als die CP. Warum also nicht "umdrehen"?


----------



## Nobby37 (20 April 2010)

Rainer Hönle schrieb:


> Und welche Anforderungen haben die anderen Anwendungen? Die PN-Schnittstelle ist bei der genannten SPS-Zykluszeit deutlich schneller als die CP. Warum also nicht "umdrehen"?



Laut Aussage vom Siemens Support soll die Zeit gleich sein.


----------



## Nobby37 (20 April 2010)

LowLevelMahn schrieb:


> aber möglicherweise kannst du uns ja sagen wie die Daten aussehen und wer diese benutzt (und wer das was pollend liest)
> 
> also
> 
> ...




Hallo,

der Weg ist z.Z. wie folgt.
Messsystem (Windows XP) <--> CP 343 <--> SPS-DB <--> Achse


----------



## Rainer Hönle (20 April 2010)

Nobby37 schrieb:


> Laut Aussage vom Siemens Support soll die Zeit gleich sein.



Ich glaube das jetzt nicht und deshalb würde ich sagen: selber testen. Einfach ne Demoversion von ACCON-AGLink von unserer Homepage laden und dann das Programm AGLink40_Performance.EXE nach der entsprechenden Konfiguration laufen lassen. Dieses Programm sucht sich den größten DB und führt dann entsprechende Lesetests durch und gibt die Werte aus. Da können wir dann sehen, ob der Siemens Support recht hat (wie bei: ich nehme noch Bytes für die Übertragung dazu, dann wird es schneller :?.


----------



## Nobby37 (20 April 2010)

*Die Lösung ist UDP*



argv_user schrieb:


> Es wird hier immer auf das Antworttelegramm gewartet. Wie Rainer Hönle
> schon sagte hängt das am Siemens-Protokoll.
> 
> Es gibt aber auch noch UDP. Vielleicht kannst Du damit schnellere Kommunikation erreichen, da hier der TCP-Overhead wegfällt. Ich bin mir da aber nicht sicher. UDP ist eventuell in LibNoDave garnicht implementiert, eher in Prodave, oder im entsprechenden Produkt von Deltalogic.
> ...




Die Lösung ist UDP!!!  Die Daten kommen jetzt alle 9-10ms an der SPS an. Allerdings sende ich nicht mehr per LibNodave, sondern mit MS Sockets.

Danke für den Tip


----------



## Thomas_v2.1 (20 April 2010)

Nobby37 schrieb:


> Die Lösung ist UDP!!!  Die Daten kommen jetzt alle 9-10ms an der SPS an. Allerdings sende ich nicht mehr per LibNodave, sondern mit MS Sockets.
> 
> Danke für den Tip



Wie hast du denn die Zeit gemessen? Bei UDP gibt es ja kein ACK.

Vielleicht dauert das reine Schreiben in die SPS mit libnodave ja auch nicht so lange. Also ich meine damit die Zeit in der die SPS den Wert an die entsprechende Adresse übernommen hat, und nicht bis sie das Antworttelegramm zurücksendet.


----------



## Nobby37 (20 April 2010)

Thomas_v2.1 schrieb:


> Wie hast du denn die Zeit gemessen? Bei UDP gibt es ja kein ACK.
> 
> Vielleicht dauert das reine Schreiben in die SPS mit libnodave ja auch nicht so lange. Also ich meine damit die Zeit in der die SPS den Wert an die entsprechende Adresse übernommen hat, und nicht bis sie das Antworttelegramm zurücksendet.



Die Zeiten sind auf SPS-Seite und über einen Netzwerk-Sniffer aufgezeichnet worden. Man konnte sehen, dass die SPS mit dem Acknowledge auch zeitnah antworten konnte, aber bevor dies wieder auf PC-Seite war, verging zuviel Zeit (Netzwerk-, CPU-überlastung, ...?). Ohne das TCP-Acknowledge konnte die Zeit auf 10 ms verkürzt werden. Bei schnelleren Übertragungen gingen Pakete verloren, weil sie von der SPS nicht abgeholt werden konnte.
Wichtig dabei ist auch zu wissen, dass ein Thread unter Windows XP durch das Scheduling maximal nur alle 16 ms aufgerufen werden kann. Die Sendezeiten konnte nur durch Verwendung des Multimediatimers erreicht werden, der bis zu 1 ms auflöst.


----------



## argv_user (20 April 2010)

Thomas_v2.1 schrieb:


> Wie hast du denn die Zeit gemessen? Bei UDP gibt es ja kein ACK.
> 
> Vielleicht dauert das reine Schreiben in die SPS mit libnodave ja auch nicht so lange. Also ich meine damit die Zeit in der die SPS den Wert an die entsprechende Adresse übernommen hat, und nicht bis sie das Antworttelegramm zurücksendet.



Interessanter Aspekt, 

aber wenn Du bedenkst dass bei den TCP-basierten Protokollen immer eine Antwort erwartet werden muss, und die etwas dauern kann, also bevor das nächste Telegramm losgeschickt werden kann, so kannste zwar beim ersten Zugriff recht schnell sein, aber nicht mehr in einer Schleife, die Zugriffe ohne Pause dazwischen durchnudelt...


----------



## Nobby37 (20 April 2010)

argv_user schrieb:


> Interessanter Aspekt,
> 
> aber wenn Du bedenkst dass bei den TCP-basierten Protokollen immer eine Antwort erwartet werden muss, und die etwas dauern kann, also bevor das nächste Telegramm losgeschickt werden kann, so kannste zwar beim ersten Zugriff recht schnell sein, aber nicht mehr in einer Schleife, die Zugriffe ohne Pause dazwischen durchnudelt...



Genau das war ja das Problem. Das Schreiben ging sicherlich schnell, aber die Funktion kehrt erst zurück, wenn eine Antwort angekommen ist.


----------



## Rainer Hönle (21 April 2010)

Nobby37 schrieb:


> Genau das war ja das Problem. Das Schreiben ging sicherlich schnell, aber die Funktion kehrt erst zurück, wenn eine Antwort angekommen ist.


Dies hängt aber nicht nur am TCP/IP sondern an dem überlagerten Protokoll. Ein Schreibauftrag über RFC1006 wird immer noch von der S7 bestätigt. Damit kann festgestellt werden, ob das Schreiben überhaupt geklappt hat. Es könnte ja z.B. der gewünschte DB nicht da sein. Dasselbe gilt natürlich auch für das Lesen.
Meine Untersuchungen haben gezeigt, dass weit über 95 % der Zeit beim Warten auf diese Bestätigungen verbraten wird.


----------



## argv_user (21 April 2010)

Rainer Hönle schrieb:


> Dies hängt aber nicht nur am TCP/IP sondern an dem überlagerten Protokoll. Ein Schreibauftrag über RFC1006 wird immer noch von der S7 bestätigt. Damit kann festgestellt werden, ob das Schreiben überhaupt geklappt hat. Es könnte ja z.B. der gewünschte DB nicht da sein. Dasselbe gilt natürlich auch für das Lesen.
> Meine Untersuchungen haben gezeigt, dass weit über 95 % der Zeit beim Warten auf diese Bestätigungen verbraten wird.



Das deckt sich auch mit meiner Erfahrung.
Und genau deshalb habe ich ja hier UDP vorgeschlagen, denn selbst wenn das AG eine Antwort schickt kann man die ja auch geflissentlich ignorieren.

Mit anderen Worten: Wem die Rückmeldung über Erfolg/Misserfolg egal ist, der kann mit der UDP-Variante durchaus glücklich werden.


----------



## Nobby37 (21 April 2010)

argv_user schrieb:


> Das deckt sich auch mit meiner Erfahrung.
> Und genau deshalb habe ich ja hier UDP vorgeschlagen, denn selbst wenn das AG eine Antwort schickt kann man die ja auch geflissentlich ignorieren.
> 
> Mit anderen Worten: Wem die Rückmeldung über Erfolg/Misserfolg egal ist, der kann mit der UDP-Variante durchaus glücklich werden.



Den Rückkanal haben wir übrigens als zweite Verbindung wieder über TCP realisiert. Ist nicht so zeitkritisch.


----------

