Realtime mit libnodave

Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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.
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zurück
Oben