Realtime mit libnodave

[Nobby37]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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


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?

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]

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

 

[argv_user]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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?

Hallo,

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

 

[Rainer Hönle]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

Die Lösung ist UDP

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".

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]

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.