# Beckhoff-system Latenzen optimieren



## Beta6 (22 August 2008)

Hallihallo,

ich habe einen EK1100, eine EL4732 und eine EL3702 angeschlossen.
Nun speise ich mit einem Funktionsgenerator ein Signal in die 3702 ein (1khz Rechteck) und gebe den Wert mit der El4732 wieder aus und messe diesen ausgangswert mit einem Oszilloskop. Dieser vergleicht dann das Ausgangssignal mit dem Signal des Funktionsgenerators. Ich messe eine Latenz zwischen 100 und 150 µs, was für mich jedoch noch zuviel ist. 
Mein Ziel: wie schaffe ich es, unter 100µs zu kommen. 
Abgesehen davon ist ein starkes Jittern zu verzeichnen, das jedoch erstmal außer acht gelassen kann. Der Mittelwert gibt ca. eine latenz von 130µs an.

Würd mich freuen wenn jemand mir den einen oder anderen Tipp geben könnt


----------



## drfunfrock (22 August 2008)

Frag mal Beckhoff. Es gibt die Klemmen, die per Zeit getriggert werden. Sobald ein Ereignis an einer Eingangsklemme kommt, wird die Ausgangsklemme getriggert, ohne das ein Programm dabei beteiligt ist. Ich habe das auf einer Messe gesehen.


----------



## trinitaucher (23 August 2008)

Ein Jitter kommt grundsätzlich zustande durch:
- System-Latenzzeit: Schwankungen des gesamten TwinCAT Systems. (wird im System Manager angezeigt und sollte nicht über 5µs liegen)
- SPS-Latzenzeit: Abhängig von der Laufzeit des SPS-Programms
- Updatezeit des Ethercat und evtl. Schwankungen der Telegrammlaufzeit.

Wie hoch ist dein System-Jitter?

Alle Jitter könnten sich ggf. zu deinen Min/Max-Werten aufsummieren.
Schwankungen beim Ethercat werden bei den XfC-Klemmen (die du ja hast) durch die "verteilten Uhren" vermieden. Aber das spielt bei dir gar keine Rolle, da du ja nicht verschiedene Aus- oder EIngänge zur gleichen Zeit updaten möchtest.
Du hast eher mit dem System- und SPS-Jitter zu kämpfen. Normalerweise wird der Ethercat-Zyklus, so wurde es mir zumindest erklärt, gestartet, sobald das SPS-Programm fertig abgearbeitet ist. Schwankt die SPS-Laufzeit, schwankt auch die "Startzeit" zweier Ethercat-Zyklen.
Hierfür kannst du im System Manager unter SPS-Konfiguration => "Name deines SPS-Programms" => "I/O am Task Anfang" einstellen. Dann wird der Ethercat-Zyklus immer zum Task-Beginn gestartet, und die Prozessdaten am Anfang gelesen und geschrieben, womit der SPS-Jitter rausfällt. Aber dann wird deine Ein/Ausgabe evtl. um einen Zyklus verzögert!

Was aber zu deiner großen Abweichung führt, ist eher die Tatsache, dass die Klemmen nicht immer zum dem Zeitpunkt updaten, wo der Funktionsgenerator seinen passenden Flankenzustand hat. Evtl. mal kurz vor oder kurz danach. In Summe (bedenke die Anzahl der Zyklen pro Sekunde) kommt dann immer eine kleine Verschiebung zustande, verursacht durch den System-Jitter (also bis zu 5µs).
Ich wüsste nicht, wie du eine exakte Gleichzeitigkeit  von TwinCAT-System und Funktionsgenerator erreichen kannst.
Ach ja: wie sieht das ganze aus, wenn du 50µs Zykluszeit einstellst?

Wozu benötigst du diese Sache eigentlich?


----------



## speedix (25 August 2008)

*Beckhoff-Latenz optimieren - wie bekommt man stabil 100µs ?*

Hallo,

ich arbeite zusammen mit "beta6" an dem genannten Problem, und möchte mich schon einmal für die umfangreiche Hilfe bisher bedanken!

*Ich möchte zunächst noch einmal das übergeordnete Problem darstellen:*

- Geplante Anwendung ist die Regelung einer Magnetführung im Rahmen eines universitären Forschungsprojektes im Maschinenbau / Fertigungstechnik bzw. die Ausbildung von Studenten Maschinenbau/Elektrotechnik/Technische Informatik.
- Im Moment versuchen wir erst einmal, ein EtherCAT-System mit einem Eingang (EL3702, A/D-Wandler) und einem Ausgang (EL4132, D/A-Wandler) zum Laufen zu bringen.
- In einer weiteren Ausbaustufe soll dann das System mind. 8 Eingänge (16bit analog), am besten zusätzlich noch 8 weitere Eingänge, also insgesamt 16 Eingänge, absolut zeitsynchron abtasten, daher brauchen wir die DC. 
- Ausgegeben werden sollen dann 8 Analogausgänge, ebenfalls zeitsynchron (mit DC). 
- Das ganze muss möglichst schnell gehen, daher die Bedeutung der Latenzzeit, da es sich um eine Regelung handelt. Deswegen MUSS UNBEDINGT ein zeitlicher Determinismus gewährleistet sein, d.h. es darf nicht passieren, dass eine Ausgabe mal "einen Zyklus zu spät" kommt, da dann der Regler möglicherweise instabil wird. Gleichzeitig sollte es ja theoretisch möglich sein, durch die DC den Jitter im zweistelligen ns-Bereichzu halten.

Die Regelung soll eigentlich mit 10kHz laufen, jedenfalls verspricht Beckhoff zumindest in Ihrer Werbung dass das geht ("absolut zeitsynchron mit 100µs", "Eingänge lesen und schreiben unter 100µs"). Wenn noch mehr mehr (15 kHz, 20 kHz) ginge wäre das zwar prinzipiell schön, nach meinem bisherigen Verständnis aber nicht machbar.

Ich weiß das die Hardware die 10 kHz prinzipiell hergibt (habe schon Implementationen auf nem Echtzeit-Linux gesehen), aber ich würde ungern auf Linux zurückgreifen und lieber in der Twincat/Windows-Welt bleiben 

*Status Quo:*

Zykluszeit: 50µs, Task-Ausführungszeit: 50µs, neueste TwinCAT-Version installiert (Build 1328 ).
Wenn man nun ein Dreieckssignal in den A/D-Wandler einspeist, und das Programm eigentlich nur daraus besteht, Eingang 1 auf Ausgang 1 zu kopieren, dann hat man eine Signalverzögerung von 100µs mit relativ geringem Jitter... so weit, so gut.

Dabei kommt es aber vor, daß trotz CPU-Einstellung auf "90% für Twincat" und angeblicher Echtzeitauslastung von lediglich 25% (auf einem Core2Duo 2GHz) ab und zu "Glitches" auftauchen, sprich die Ausgabe einen Zyklus zu spät kommt. Dieses Phänomen wird deutlich häufiger, wenn man im Programm eine zweite Zeile hinzufügt und auch Eingang 2 auf Ausgang 2 kopiert. Die Echtzeit-Auslastung bleibt trotzdem bei ca. 25%. Programmiert ist das momentan über die SPS-Oberfläche in SPS-Code. Nur, wo ist da die deterministische "harte" Echtzeit? Die genannten "Glitches" dürften eigentlich nicht auftauchen. Da müssen wir noch irgendwas falsch gemacht haben...

*Ein paar Fragen:*

- Wann sampled der AD-Wandler, sofern keine DC benutzt werden? Direkt nach Paketeingang? Oder "gleichzeitig" zum Paketeingang? Sobald das Paket "durchfährt" müssen ja bereits Daten im Wandler liegen, und die Digitalisierung dauert ja auch ein paar µs.
- Ich nehme an, der DA_Wandler gibt das Signal aus sobald er es bekommt, wenn keine DC benutzt werden?
- Mit den DC solle es ja möglich sein, den Sampling-Zeitpunkt immer auf beispielsweise t=-10µs vor Paketeingang zu stellen, so daß das Paket aktuelle Daten zeitäquidistant einsammeln kann. Genauso sollte es ja gehen, daß der Ausgabewert der mit dem nächsten Paket übergeben wird beispielsweise auf t = t_sampling + 100µs gesetzt wird. Mit der Zykluszeit von 50µs sollte dann eine echt zeitlich-äquidistante Regelung mit t=100µs möglich sein, ganz so wie es die Werbung verspricht ? 
- Ergänzend zu der Implementation in TwinCAT in der SPS wäre es ja noch denkbar, über TwinCAT R3IO oder ADS zu regeln. Hat da jemand schon einmal Erfahrung gesammelt? Im Prinzip wär das hochinteressant, da "konventionelle Programmierung" und entsprechend gut anpassbar an unseren Einsatzfall. WIe sieht das da mit den Latenzen aus? Das wass ich bisher gefunden habe besagt nur "über R3IO kann schnell auf das Prozessabbild zugegriffen werden, oder den Umweg über ADS zu gehen"... an anderer Stelle steht aber, daß dies nur über den Multimedia-Timer und damit NICHT in harter Echtzeit geht, und man die Task dann über ADS synchronisieren solle (?) 

SO, das waren ne Menge Fragen & ne Menge Text, vielleicht findet sich ja jemand der zum einen oder anderen Thema was sagen kann, evtl. liest ja auch jemand von Beckhoff mit? Vielen Dank auf jeden Fall schon einmal für die Unterstützung!!!


----------



## trinitaucher (25 August 2008)

speedix schrieb:


> ..."absolut zeitsynchron mit 100µs", "Eingänge lesen und schreiben unter 100µs"...


Wir wissen ja alle, dass Werbeaussagen sehr genau betrachtet werden müssen.
Ich hab's immer so verstanden, dass dieses "XfC" immer eine Zykluszeit von 100µs zu Grunde legt. Also das Programm wird ausgeführt (Dauer so um die 50µs), das Ethercat-Telegramm losgeschickt (Ausgänge geschrieben, Eingänge gelesen, Dauer ca. 30µs)  und im folgenden Zyklus sind somit die aktuellen Eingänge verfügbar.

Scheinbar habt ihr euch mit den DC schon gut auseinandergesetzt. Ich bin da noch nicht so weit 
Was du schreibst, klingt aber erstmal logisch...

Zu den Jittern: Wie hoch ist denn die SPS-Zykluszeit (Maximum)? Welches Betriebssystem? Win CE oder Win XP?
Habe mal gehört, Win CE soll trotz TwinCAT "echtzeitfähiger" ROFLMAO sein als Win XP. Wer weiß was da im Hintergrund alles abgeht.

Ohne DC-Latch werden die Signale, denke ich mal, nach dem Durchlaufen des Telegramms ausgegeben und die bis dato gesammelten Eingangswerte ins Telegramm geschrieben.
Fragt doch mal bei Beckhoff nach. Vielleicht nicht unbedingt beim Support... versucht mal nen Produktmanager der XfC-Sache ans Rohr zu kriegen.


----------



## drfunfrock (26 August 2008)

Bei so kleinen Zykluszeiten kommt das ganze an eine Systemgrenze. Ihr könnt das ganze Per Timestamp syncen, aber auch nicht mehr.


----------



## MSc (4 September 2008)

Gibt es zu dem Thema neue Erkenntnisse. Die Synchronität hat ja noch nicht besonders berauschend ausgesehen und die verlorenen Werte würden mich etwas beunruhigen

LG

MSc


----------



## Beta6 (19 September 2008)

Bisher noch nicht wirklich. Wir haben mit diversen Einstellungen einen Wert von ungefähr 125-150µs bekommen (bei einer Prozessorauslastung >80% !). Das starke Jittering haben wir fehlgedeutet, es lag an unseren Messgeräten und war somit eigentlich gar kein Jittering. Ich bin gerade dabei ein Programm in c++ zu programmieren, um die klemmen anzusteuern. Mal schauen ob sich dadurch etwas verändert ...


----------



## Neals (22 September 2008)

Was habt ihr denn für einen EtherCAT Master?
Nen IndustriePC oder EmbeddedPC von Beckhoff oder einen normalen DesktopPC?

Die implementierung von EtherCAT im TwinCAT ist für Intel Prozessoren optimiert worden, vlcht solltet ihr mal die Netzwerkkarte tauschen.


----------



## Beta6 (26 September 2008)

Sooo,

also ich kann nun sagen dass man es wirklich vergessen kann mit ADS einen lese/schreib-zylkus im mikrosekundenbereich zu erreichen! Ich habe selber mit einer Funktion die Zeit ausgelesen und damit ein Programm geschrieben das funktioniert hatte, nur war es von den gewollten 50µs um Welten entfernt! 
Der Schreib Prozess konnte ungefähr nur alle 1-2ms ablaufen, was in meinem Fall leider viiiieeeel zu viel ist :smile: ... trotzdem danke für die mithilfe und ich probiere es nun mit R3IO ^^



und wir haben btw einen Industrie-Beckhoff-PC ...


----------



## drfunfrock (26 September 2008)

Ich denke, ihr seid da auf einem falschen Weg. Für so etwas kann man ein FPGA oder DSP nehmen, aber ein SPS ist für so etwas nicht gebaut worden. R3IO wird nicht helfen, weil dieser Teil nicht im Echtzeit-Kernel liegt.


----------



## Longbow (23 Oktober 2008)

Es wird aber daran gearbeitet, damit eine SPS das kann! ;-)


----------



## drfunfrock (23 Oktober 2008)

Longbow schrieb:


> Es wird aber daran gearbeitet, damit eine SPS das kann! ;-)



Verrate mehr! :TOOL:


----------



## Longbow (23 Oktober 2008)

drfunfrock schrieb:


> Verrate mehr! :TOOL:



Vielleicht mal auf der SPS/IPC/Drives etwas umschauen, dort wird eine SPS aus dem S7 Lager angekündigt, die mit OnBoard Analog etwas schneller umgehen kann.

Zielsetzung ist es diesen Bereich für eine SPS erreichbar zu machen,
damit es in Zukunft eben nicht mehr notwendig ist, einen FPGA oder Microcontroller zu benutzen.


----------



## drfunfrock (23 Oktober 2008)

Die Messe ist für mich leider nicht erreichbar. Aber es läuft doch dann darauf hinaus, dass ihr eine Box baut, die so etwas wie einen DSP drin hat und die Verarbeitung über Parameter, die über einen Bus kommen, gesteuert wird? 

Eigentlich eine naheliegende Idee. Wer braucht soetwas? Ich frage nur, weil ich neugierig bin.


----------

