Beckhoff Ethercat Klemmen exakt jede Millisekunde auslesen

Hallo zusammen.
Ich bin neu hier, und auch neu im Thema Labview, Echtzeit, EtherCat, und Beckhoff TwinCat.

Folgende Komponenten versuche ich zum Zusammenspiel zu bringen:
Beckhoff EtherCat Klemmen mit Buskoppler EK1100 und klemmen EL3632, EL3011, EL4132.....
TwinCat I/O V2.11 build 2666
LabView 2011
Das alles auf einen Standart PC mit Pentium 4 Einkernprozessor bei 2,8 GHz
Betriebssystem Windows XP

Mein Problem ist folgendes:
Zur Überwachung eines Prüfstands soll ich mit Beckhoff EtherCat Klemmen unterschiedliche Sensoren auswerten und Ausgangsgrößen schreiben. Die gewandelten Signale sollen in Labview weiterverarbeitet werden z.B. Spektralanalyse, Erkennung von Schäden, Notabschaltung.

Mein bisheriges Vorgehen zum Lesen der Eingänge ist, die Ethercat Klemmen in der Beckhoff Software "Twincat Systemmanager" als Variablen in einen Task zu verknüpfen. Die Task-Zykluszeit beträgt 1ms.
Die so erzeugten Variablen lese ich dann mit LabView über über die ADS DLL (AdsSyncReadReq) aus. Dieses Auslesen findet in einer Schleife statt. Diese soll im Bestfall sobald ein neuer Wert anliegt (einmal pro millisekunde) diesen in Ihr Schieberegister speichern, sodass ich nach einer voreingestellten Menge von Abtastungen aus dem so enstandenen Array einen Signalverlauf mit äquidistant abgetasteten Werten erzeugen kann.

Hier fängt das Problem an. Die so gesammelten Werte sind eben nicht zeitlich äquidistant. Versuche mit/ohne Wartezeit, Zeitgesteuerter Schleife und auch mit ADS OCX, führen immer zu gleichen Durchlaufzeiten der Schleife. Meistens sind es zwei millisekunden, mal drei, mal vier und ganz selten auch mal eine millisekunde.
Sieht jemand eine Chance, diese Abfrage des Eingagssignals exakt einmal pro millisekunde ablaufen zu lassen, vllt mit einer synchronisierung auf eine der EtherCat Uhren? Oder kennt jemand ein Möglichkeit auf TwinCat seite einen Ringpuffer einzurichten, der nur mal alle paar 100 millisekunden ausgelesen wird.
Ich brauche letztlich "nur" einen nahtlosen zeitlich äquidistant abgetasteten Datenstream der gewandelten Sensorsignale von z.B. 2 Sekunden Länge und diesen z.B. alle 10 Sekunden.
Ich habe ein Beispiel .vi Angehängt, in dem man meinen Versuch der Signalabtastung mit AdsSyncReadReq zzgl. Spektralanalyse sieht.

Ich hoffe damit habe ich alles zusammen damit mir geholfen werden kann und nicht zu viele Forenregeln missachtet. Wenn nicht korrigiert mich. Wie gesagt ich bin neu hier.

Hallo SBarber,

nichts spezielles zu deinem Problem, aber generell gültige Sachen...
Zu dem Bild des VIs:
- Deine While-Schleife ist ihrem eigentlichen Zweck entsprechend eigentlich eine FOR-Loop. Dann verwende bitte auch eine solche, dies hätte den Vorteil des effizienteren Array-Handlings durch LabVIEW!
- Du liest wiederholt aus eine lokalen Variablen "Wirbelstrom", berechnest etwas und schickst diese Daten an die DLL. Wenn die Berechnung konstant ist (d.h. "Wirbelstrom" sich nicht ändert), dann brauchst du die Berechnung nur einmal außerhalb der Schleife durchführen!
- Dein Prozessor mag noch so schnell sein: Dein Schleifentiming wird von Windows beeinflusst! Und selbst 1kHz-Schleifen sind unter (Standard-)Windows reine Illusion, jeder Netzwerkzugriff/Festplattenzugriff/Virenscanner/wasweißich versaut dir dein Timing...
- Üblicherweise sind Abfragen von Einzelwerten "grottenschlecht" in ihrer Performance, da einfach zuviel Overhead drum rum besteht. Bietet deine Beckhoff-DLL andere Funktionen, die dir evtl. mehrere Werte ausgeben können?

Hallo GerdW,
danke für die schnelle Antwort.
-Die while Schleife war grundsätzlich mal eine for Schleife. Die hab ich nach verschiedenen Versuchen nur nicht zurück geändert, da sich kein spürbarer performance Unterschied ergeben hat.
-Das was du das als Berechnung mit "Wirbelstrom" siehst, ist nur die Erzeugung der ADS-Adressierung durch das Auslesen der globalen Variable Wirbelstrom (Adresse der Variablen in TwinCat) und das anschließende Umwandeln in die einzelnen Adressteile in einem SubVi für das AdsSyncReadReq. Adressieren mit INT Konstanten macht den ablauf auch nicht spürbar schneller.
-Das mit dem "1kHz Schleifen unter windows klappt nicht" will ich noch nicht wahr haben. Kann man Windows nicht mit irgendwelchen Erweiterungen das recht entziehen seine Prioritäten selbst zu verwalten?
-Ich habe noch ein andere Variable, bei der ich ein Array von TwinCat nach Labview übergebe. Dabei übergebe ich je aufruf ein Array aus 50 INT Werten. Das klappt aber spürbar genau so schnell wie bei einem einzelnen Wert.

Also im Moment glaube ich, das nicht meine von Dir aufgedeckte und zugegeben unsaubere Programmierung das Problem ist, sondern eben die magische 1kHz Grenze.
Sowas wie ein Puffer mit einer nahtlosen Aufzeichnung , den ich "irgendwann" mal bei TwinCat abhole könnte wirklich schon für meine Zwecke reichen. Da wären alle gefragt, die mit den Beckhoff komponenten Erfahrung haben.

(07.08.2012 21:30 )SBarber schrieb:  -Das mit dem "1kHz Schleifen unter windows klappt nicht" will ich noch nicht wahr haben.

Da gewöhnst du dich besser mal dran! Dazu bräuchtest du LV Realtime auf einem entsprechenden Controller, und dann hast du wenigstens die Gewsissheit einer deterministischen Abarbeitung...ob der Takt dann aber auch mit 1ms realisierbar ist, weiß ich nicht.

Evtl. kannst du mal bei Beckhoff nachfragen, ob man im Koppler einen Zeitstempel an die Daten anhängen kann. Dann wäre es zwar u. U. immer noch nicht äquidistant, aber immerhin korrekt darstellbar.

EtherCAT ist ja eigentlich extra für deterministische Datenübertragung gemacht. Für die LV-Anbindung gibts dazu folgendes:
http://www.ni.com/white-paper/10555/de

Also läuft's auf cRIO und damit wieder auf LV Realtime raus...


Gruß
Achim

(07.08.2012 21:30 )SBarber schrieb:  Also im Moment glaube ich, das nicht meine von Dir aufgedeckte und zugegeben unsaubere Programmierung das Problem ist, sondern eben die magische 1kHz Grenze.
Sowas wie ein Puffer mit einer nahtlosen Aufzeichnung , den ich "irgendwann" mal bei TwinCat abhole könnte wirklich schon für meine Zwecke reichen. Da wären alle gefragt, die mit den Beckhoff komponenten Erfahrung haben.

TwinCat kann das im Prinzip schon, aber das hängt auch wieder von der Lizenz ab was da alles möglich ist. Grundsätzlich ist aber zu sagen dass Du unter jedem beliebiegen heutigen Desktop OS (Windows, Linux, MacOS X) keine deterministische Laufzeitgenauigkeit auf 1ms herunter bekommst. Eine Loop kann zwar normalerweise durchaus schneller als 1ms sein und dementsprechend easy auch x mal pro ms laufen, ABER es gibt keinerlei Garantie, dass der Thread in dem die Loop läuft nicht durch das OS für einige ms (unter Windows mit hoher Interruptlast kann das durchaus auch mal 100ms sein) ganz einfach aufs Eis gelegt wird. Da kann auch TwinCat nicht viel daran ändern wenn es auf Windows läuft. Aber man kann TwinCat auf einen Beckhoff RT Controller laufen lassen und dann ist es eine ganz andere Geschichte.

Nur ist dann die nicht ganz so einfache Frage, wird es TwinCat auf einem Beckhoff Controller oder doch einfach LabVIEW RT auf einem cRIO. Kostenmässig ist es so oder so eine nicht vernachlässigbare Investierung.

Die kostengünstigste Variante ist wahrscheinlich ein Busklemmenkontroller statt einem Busklemmenkoppler, auf dem Du von TwinCat aus Routinen laufen lassen kannst, die zum Beispiel die Realzeiterfassung in einen Buffer vornmimmt und dann den ganzen Buffer in einem Rutsch an TwinCat auf dem PC transferiert. Was dabei die Komplikationen und Kosten sind kann ich Dir aber nicht sagen, da ich diese Variante bisher nur evaluiert habe, aber nie ausgeführt.

(10.08.2012 11:27 )rolfk schrieb:  TwinCat kann das im Prinzip schon, aber das hängt auch wieder von der Lizenz ab was da alles möglich ist. Grundsätzlich ist aber zu sagen dass Du unter jedem beliebiegen heutigen Desktop OS (Windows, Linux, MacOS X) keine deterministische Laufzeitgenauigkeit auf 1ms herunter bekommst. Eine Loop kann zwar normalerweise durchaus schneller als 1ms sein und dementsprechend easy auch x mal pro ms laufen, ABER es gibt keinerlei Garantie, dass der Thread in dem die Loop läuft nicht durch das OS für einige ms (unter Windows mit hoher Interruptlast kann das durchaus auch mal 100ms sein) ganz einfach aufs Eis gelegt wird. Da kann auch TwinCat nicht viel daran ändern wenn es auf Windows läuft. Aber man kann TwinCat auf einen Beckhoff RT Controller laufen lassen und dann ist es eine ganz andere Geschichte.

Die kostengünstigste Variante ist wahrscheinlich ein Busklemmenkontroller statt einem Busklemmenkoppler, auf dem Du von TwinCat aus Routinen laufen lassen kannst, die zum Beispiel die Realzeiterfassung in einen Buffer vornmimmt und dann den ganzen Buffer in einem Rutsch an TwinCat auf dem PC transferiert. Was dabei die Komplikationen und Kosten sind kann ich Dir aber nicht sagen, da ich diese Variante bisher nur evaluiert habe, aber nie ausgeführt.

Hallo rolfk,
habe ich da bei den Beckhoff-Angaben auch noch was falsch verstanden? Die Verbindung von den Klemmen, über den Buskoppler, über eine echtzeitkompatible intel Netzwerkkarte mit installiertem TwinCat RT Treiber, zur TwinCat Software kommuniziert doch in Echtzeit. Also die Datenkommunikation bis zur TwinCat Software findet doch deterministisch in jedem Zyklus statt, selbst bei noch kürzeren Zykluszeiten als 1ms.
Ich dachte mein Problem wäre erst dann der Schritt von dort die Daten auch ordnungsgemäß jeden Zyklus zu Labview zu bekommen. Daher mein Idee mit dem Puffer, programmiertechnisch. Weil die jeden Zyklus übertragenen Daten liegen ja dann schon in einem Speicherbereich des Computer, müssten dort "nur" noch für eine weile verbeleiben um am ende nach X Zyklen eine nahtlose Datenaufzeichnung abrufen zu können.
Wenn ich damit doch richtig liege, bleibt halt noch immer die Frage wie und wo richte ich solch einen Puffer ein?

Anzeige

(11.08.2012 13:55 )SBarber schrieb:  Hallo rolfk,
habe ich da bei den Beckhoff-Angaben auch noch was falsch verstanden? Die Verbindung von den Klemmen, über den Buskoppler, über eine echtzeitkompatible intel Netzwerkkarte mit installiertem TwinCat RT Treiber, zur TwinCat Software kommuniziert doch in Echtzeit. Also die Datenkommunikation bis zur TwinCat Software findet doch deterministisch in jedem Zyklus statt, selbst bei noch kürzeren Zykluszeiten als 1ms.
Ich dachte mein Problem wäre erst dann der Schritt von dort die Daten auch ordnungsgemäß jeden Zyklus zu Labview zu bekommen. Daher mein Idee mit dem Puffer, programmiertechnisch. Weil die jeden Zyklus übertragenen Daten liegen ja dann schon in einem Speicherbereich des Computer, müssten dort "nur" noch für eine weile verbeleiben um am ende nach X Zyklen eine nahtlose Datenaufzeichnung abrufen zu können.
Wenn ich damit doch richtig liege, bleibt halt noch immer die Frage wie und wo richte ich solch einen Puffer ein?

Grundsätzlich kann auch Beckhoff nicht zaubern. Wenn die Datenerfassung vom PC aus gemacht wird, hilft auch Echtzeitethernetkarte alleine noch nicht. Zwar kann der EtherCat Treiber mit entsprechender Hardware einiges tun, aber das muss alles auch konfiguriert und programmiert werden. Von sich aus macht der Treiber rein gar nichts. Dazu brauchst Du TwinCat und entsprechende Lizenzen. Und inwiefern die ganze Datenerfassung innerhalb des Treibers selbst gemacht werden kann weiss ich jetzt nicht. Ist vielleicht möglich aber meines Erachtens sicher nicht die ideale Lösung. Sobald aber ein Roundtrip nach TwinCat in irgendeiner Form vorhanden ist, gibts keine harten Garantien mehr. Innerhalb eines Kerneltreibers ist das noch einigermassen zu machen, auch wenn man da Windows durchaus ausbremst damit, aber eine Applikation hat nur sehr eingeschränkte Möglichkeiten um Windows davon abzuhalten sie ab und an mal für viele ms schlafen zu schicken.

Am einfachsten denke ich ginge es mit etwas lokaler Intelligenz auf der Klemmenseite, mittels eines Buskontrollers statt eines Buskopplers. Dort kannst Du von TwinCat aus dann Routinen laufen lassen.

Hallo rolfk,
so langsam verstehe ich wovon du im letzten Beitrag redest. Zudem habe ich meine LabView-Installtion mal vervollständigt und das Labview RealTime Module und den NI-Industrial Communications for EtherCAT 2.4 treiber installiert.
Ich habe auch einen VideoCast von NI gefunden, der die Anbindung von EtherCat an Labview erklärt.
https://ni.adobeconnect.com/_a56821929/p70868677/
Dabei wird ein compactRIO als EtherCat Master konfiguriert, alternativ könnte man auch ein NI PXI System als Master konfigurieren. Als EtherCat slave wird ein NI 9144 mit verschiedenen Einschüben verwendet.
So wie sich das dort darstellt, kann dann auch Labview deterministische zeitgesteuerte Schleifen durchlaufen, da diese dann mit der Scan-Engine synchronisiert werden.
NI Master Hardware habe ich aber nicht zur Verfügung. Wenn ich die folgenden links aber richtig verstehe, müsste es möglich sein, Twincat mit dem Realtime Treiber und der Netztwerkkarte als Ethercat master zu verwenden. Also ohne separate Master Hardware.

http://digital.ni.com/public.nsf/allkb/6...67007B01A9
http://digital.ni.com/public.nsf/allkb/6...enDocument

Kithara preist für ihren Softwarebasierten Ethercat master auch an, das er wie Twincat, (nur einfacher, toller, besser) an labview angebunden werden kann. Und weist auch noch mal darauf hin, das:"Bei der Steuerungs-Software - dem sogenannten EtherCAT Master - muss man zwischen SPS-basierten und damit eher komplexen "Black-Box"-orientierten Systemen einerseits und offenen Funktionsbibliotheken wie dem Kithara EtherCAT Master andererseits unterscheiden."

http://www.kithara.de/de/loesungen/ethercat-master

Ich finde nur nirgends eine Anleitung, wie man im Measurement and Automation Explorer einen "Third party EtherCat Master" einbindet.

Hast Du Oder sonst jemand hier dafür irgendwelche Tipps oder Anleitungen?

(14.08.2012 09:20 )SBarber schrieb:  Ich finde nur nirgends eine Anleitung, wie man im Measurement and Automation Explorer einen "Third party EtherCat Master" einbindet.

Der MAX (Measurement und Automation Explorer) ist ein NI Product und grundsätzlich nur für NI Hardware zuständig. Und obwohl NI natürlich Interesse hat ihre eigenen Produkte zu promoten ist das im Falle von MAX Hardware Unterstützung nicht die Hauptursache. Um das tun zu können was MAX alles erlaubt, braucht es eine sehr weitgehende Zusammenarbeit zwischen MAX und den Hardwaretreibern. Dies kann NI für ihre eigenen Produkte leicht garantieren, aber bei Drittherstellern ist das praktisch ein unlösbares Problem. Abgesehen davon dass es für NI keinerlei kommerziellen Sinn macht, diese Schnittstellen für Drittanbieter offen zu legen, würde eine solche Dokumentation der Schnittstellen automatisch jegliche Erweiterung in der Zukunft aufs Schwerste behindern, da nichts mehr an den einmal dokumentierten APIs verändert werden darf ohne dass irgendwelche Software die diese APIs in bestimmter Weise (miss)braucht plötzlich nicht mehr funktioniert.

Wenn das für einen NI Treiber passiert, dann bekommt der entsprechende Produktmanager halt eine Predigt vorgelesen, aber wenn das für andere Hersteller passiert ist es jeweils ein grosses Fingerzeigen von NI und dem Drittanbieter, wer nun die Schuld hat. Die technische Komplexität der Interfaces zu MAX sind zudem alleine schon viel komplexer als das was man von den meisten anderen Herstellern an kompletter Treiberunterstützung für ihre Produkte bekommt. Ausserdem ist es sehr uninteressant für Drittanbieter um sich in solche Abhängigkeit von NI zu begeben und würde eine solche Schnittstelle deshalb sowieso kaum verwendet, womit der Aufwand und die Einschränkungen die sich NI mit einer Offenlegung einhandelt nicht einmal mehr karitativen Character hätten, sondern schlichtweg aus dem Fenster geworfenes Geld wären.