TwinCAT – Fehler 0x4466 bei EL7031/EL7041 ohne Encoder im Open-Loop-Betrieb

KlausiMausi

Level-2
Beiträge
7
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin zusammen,

ich bin noch relativ neu im Bereich TwinCAT und habe aktuell ein Problem beim Betrieb mehrerer Schrittmotorachsen im Open-Loop-Modus mit EL7031- und EL7041-Klemmen – jeweils in der Ausführung ohne Encoder.

Die Ansteuerung funktioniert grundsätzlich zuverlässig, aber nach einer gewissen Laufzeit tritt bei allen Achsen folgender Fehler auf:

Fehler | 'TCNC' (500): 'Y-Achse2' (Achs-ID: 3, Drive-ID: 3): Die Achse hat fr mehr als 3 durchgehende NC-Zyklen ungltige IO-Daten erkannt und ist gestoppt worden ('WcState' (Sim): encoder working counter error) (Fehlercode: 0x4466) !
Fehler | 'TCNC' (500): 'Y-Achse1Test' (Achs-ID: 6, Drive-ID: 6): Die Achse hat fr mehr als 3 durchgehende NC-Zyklen ungltige IO-Daten erkannt und ist gestoppt worden ('WcState' (Sim): encoder working counter error) (Fehlercode: 0x4466) !
Fehler | 'TCNC' (500): 'X-AchseNeu' (Achs-ID: 7, Drive-ID: 7): Die Achse hat fr mehr als 3 durchgehende NC-Zyklen ungltige IO-Daten erkannt und ist gestoppt worden ('WcState' (Sim): encoder working counter error) (Fehlercode: 0x4466) !
Fehler | 'TCNC' (500): 'Z-Achse1' (Achs-ID: 4, Drive-ID: 4): Die Achse hat fr mehr als 3 durchgehende NC-Zyklen ungltige IO-Daten erkannt und ist gestoppt worden ('WcState' (Sim): encoder working counter error) (Fehlercode: 0x4466) !
Fehler | 'TCNC' (500): 'Z-Achse2' (Achs-ID: 5, Drive-ID: 5): Die Achse hat fr mehr als 3 durchgehende NC-Zyklen ungltige IO-Daten erkannt und ist gestoppt worden ('WcState' (Sim): encoder working counter error) (Fehlercode: 0x4466) !

Nach meinem Verständnis muss man beim Open-Loop-Betrieb mit TwinCAT den Simulated Encoder aktivieren – das habe ich entsprechend eingerichtet.

Was mich irritiert:
Der Fehler tritt nicht direkt beim Start, sondern erst nach einiger Laufzeit auf – immer gleichzeitig auf allen Achsen, obwohl diese einzeln und sequenziell betrieben werden.

Folgende Punkte habe ich bereits geprüft bzw. angepasst:
  • Simulated Encoder eingestellt und verschiedene Encoder-Varianten ausprobiert
  • Schleppfehlerüberwachung und ähnliche Überwachungen deaktiviert
  • I/O-Zykluszeit auf bis zu 4 ms erhöht
  • Achsen im NC-Manager komplett neu angelegt und verknüpft
  • EtherCAT-Klemmen (EL7031 / EL7041) im I/O-Konfigurationsbaum neu eingelesen und eingerichtet
Mein Verständnis ist, dass TwinCAT bei Fehler 0x4466 meldet, dass über mehrere NC-Zyklen keine gültigen Encoderdaten empfangen wurden.
Das ist prinzipiell nachvollziehbar – allerdings verwende ich keine realen Encoder, da die Achsen im Open-Loop-Modus betrieben werden und ein Simulated Encoder verwendet wird. Zudem ist für mich unklar, warum dieser Fehler plötzlich und gleichzeitig bei allen Achsen auftritt, obwohl das System initial stabil läuft und jede Achse einzeln sequenziell betrieben wird.

Hat jemand Erfahrung mit dem Thema oder eine Idee, was in Bezug auf Verknüpfung, Synchronisation oder Taskstruktur typischerweise übersehen wird?

Jeder Hinweis ist willkommen – vielen Dank im Voraus!
 
Zuletzt bearbeitet:
Das klingt eher nach einem Wackelkontakt oder defekter Hardware.

Der "Encoder" ist aus Sicht der NC-Achse immer vorhanden und zwar in der EL70x1. Dort wird ein virtueller Encoder verwendet, wenn kein echter angeschlossen ist. Siehe z.B. CoE 8012:08 bei der EL7041-1000

Der für Anfänger richtige Weg ist: Neues Projekt anlegen, auf das Zielsystem verbinden, scannen, alle Fragen mit Ja beantworten, bzw. "NC-Konfiguration" auswählen. Dann ist alles richtig vorbereitet. Dauer: 1 Minute.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das klingt eher nach einem Wackelkontakt oder defekter Hardware.

Der "Encoder" ist aus Sicht der NC-Achse immer vorhanden und zwar in der EL70x1. Dort wird ein virtueller Encoder verwendet, wenn kein echter angeschlossen ist. Siehe z.B. CoE 8012:08 bei der EL7041-1000

Der für Anfänger richtige Weg ist: Neues Projekt anlegen, auf das Zielsystem verbinden, scannen, alle Fragen mit Ja beantworten, bzw. "NC-Konfiguration" auswählen. Dann ist alles richtig vorbereitet. Dauer: 1 Minute.
Vielen Dank für die schnelle Rückmeldung!

Danke für den Hinweis bezüglich der EL70x1 und des virtuellen Encoders. Ich verwende eine EL7051-0052, bei der der genannte CoE-Eintrag (8012:08) nicht vorhanden ist – aber der virtuelle Encoder dürfte dann ja trotzdem vorhanden sein.

Einen Wackelkontakt oder Hardwarefehler kann ich ziemlich sicher ausschließen: Ich habe alle Verbindungen mehrfach geprüft, und die Fehler treten nicht sporadisch, sondern nach stabiler Laufzeit plötzlich auf. Bei einem physischen Kontaktproblem würde ich eher mit fortlaufenden oder wiederkehrenden Fehlern rechnen:
1747909937166.png
Die Hardware ist zudem recht neu, daher halte ich einen Defekt ebenfalls für unwahrscheinlich.

Deinen Vorschlag, ein Projekt „von Null“ mit Standardkonfiguration neu aufzusetzen, finde ich sinnvoll – allerdings funktioniert das System grundsätzlich mit meiner Konfiguration. Da der Fehler aber erst nach einiger Zeit auftritt, vermute ich, dass irgendwo eine Einstellung fehlt (z. B. ein Häkchen, eine Verknüpfung oder ein Zusammenhang mit der Zyklusstruktur).
 
Zuletzt bearbeitet:
Bei diesem Fehler gibt es keinen Haken. Der EtherCAT läuft komplett Zeitsynchron und wird durch den NC und der PLC an-getriggert.
Ich kenne den Fehler, wenn man z.B. CAT5e Standard-Patchkabel verwendet, da können schon mal Kontaktprobleme auftreten.
Oder nach der Beschreibung zu urteilen: Wie ist denn das mit der thermischen Auslastung?

Was sagt denn der Lost Frames -Zähler des EtherCAT-Masters?
 
Welche CPU ist im Einsatz?
Mit welcher Zykluszeit wird diese betrieben?
Wie hoch ist die Auslastung der CPU?
Welche Ausdehnung hat der EtherCAT-Bus?
Oder hängen alle Klemmen direkt hinter der CPU?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ein kurzer Hinweis zur Fehlersuche:
Der Fehlercode 0x4466 ist meistens nur das Symptom – die eigentliche Ursache liegt oft etwas weiter oben in der Fehlerliste.

Schau dir deshalb die gesamten Meldungen an – vor allem die allererste „Störung“, aber auch Warnungen und Mitteilungen können Hinweise liefern, z. B. zu Kommunikationsabbrüchen oder Spannungsproblemen. Wenn du kannst, poste die ersten paar Einträge hier – das könnte sehr aufschlussreich sein.

Zur Vorgehensweise:
  • Kontrolliere die ersten Einträge in der Fehlerliste – nicht nur den 0x4466!
  • Sieh nach, ob im EtherCAT-Master „Lost Frames“ oder „Invalid Frames“ gezählt werden – z. B. über den Emergency-Scan
  • Schau dir das PDF zur EtherCAT-Diagnose an
  • Beantworte die bisherigen Rückfragen (CPU, Zykluszeiten, Bus-Aufbau etc.) – dann können wir dir über das Forum gezielter helfen.
Die Rückfragen von asci25 und Cassandra zielen genau auf diese Punkte: Timing, Bus-Topologie, EMV, Spannungs-Versorgung – das sind typische Quellen für EtherCAT-Probleme.
 
Ich entschuldige mich für die späte Rückmeldung – ich war zwischenzeitlich der Annahme, das Problem gelöst zu haben. Nachdem ich die Zykluszeiten sowie die Prioritäten der Tasks angepasst hatte, lief das System zunächst stabil, allerdings stellte sich das leider als Trugschluss heraus.

Bei diesem Fehler gibt es keinen Haken. Der EtherCAT läuft komplett Zeitsynchron und wird durch den NC und der PLC an-getriggert.
Ich kenne den Fehler, wenn man z.B. CAT5e Standard-Patchkabel verwendet, da können schon mal Kontaktprobleme auftreten.
Oder nach der Beschreibung zu urteilen: Wie ist denn das mit der thermischen Auslastung?

Was sagt denn der Lost Frames -Zähler des EtherCAT-Masters?
Welche CPU ist im Einsatz?
Mit welcher Zykluszeit wird diese betrieben?
Wie hoch ist die Auslastung der CPU?
Welche Ausdehnung hat der EtherCAT-Bus?
Oder hängen alle Klemmen direkt hinter der CPU?

Vielen Dank für eure Rückmeldungen und Hinweise! Hier noch ein paar ergänzende Informationen zu meinem System:
  • CPU: Intel i7-1360P
  • Topologie: Alle Klemmen hängen direkt hinter der CPU – ich bin mir aber nicht ganz sicher, ob ich die entsprechende Frage korrekt verstanden habe.
  • CPU-Auslastung: durchgehend gering
  • Lost Frames: keine – der Zähler bleibt auf 0
  • Systemmeldungen: keine Warnungen, auch sonst nichts Auffälliges
  • Screenshots:
Screenshot 2025-05-26 110921.jpgScreenshot 2025-05-26 110759.jpgScreenshot 2025-05-26 110015.jpgScreenshot 2025-05-26 105952.jpgScreenshot 2025-05-26 105939.jpg

Ein kurzer Hinweis zur Fehlersuche:
Der Fehlercode 0x4466 ist meistens nur das Symptom – die eigentliche Ursache liegt oft etwas weiter oben in der Fehlerliste.

Schau dir deshalb die gesamten Meldungen an – vor allem die allererste „Störung“, aber auch Warnungen und Mitteilungen können Hinweise liefern, z. B. zu Kommunikationsabbrüchen oder Spannungsproblemen. Wenn du kannst, poste die ersten paar Einträge hier – das könnte sehr aufschlussreich sein.

Zur Vorgehensweise:
  • Kontrolliere die ersten Einträge in der Fehlerliste – nicht nur den 0x4466!
  • Sieh nach, ob im EtherCAT-Master „Lost Frames“ oder „Invalid Frames“ gezählt werden – z. B. über den Emergency-Scan
  • Schau dir das PDF zur EtherCAT-Diagnose an
  • Beantworte die bisherigen Rückfragen (CPU, Zykluszeiten, Bus-Aufbau etc.) – dann können wir dir über das Forum gezielter helfen.
Die Rückfragen von asci25 und Cassandra zielen genau auf diese Punkte: Timing, Bus-Topologie, EMV, Spannungs-Versorgung – das sind typische Quellen für EtherCAT-Probleme.
Den Hinweis mit dem Emergency-Scan werde ich gleich mal umsetzten und mir auch das angesprochene PDF genauer anschauen.
 
  • CPU: Intel i7-1360P
  • Topologie: Alle Klemmen hängen direkt hinter der CPU – ich bin mir aber nicht ganz sicher, ob ich die entsprechende Frage korrekt verstanden habe.
Mit Topologie war gemeint, wie der EtherCAT Bus bei Dir genau aufgebaut ist. @Cassandras Frage, ob die Klemmen direkt an der CPU hängen, bezieht sich (vermutlich) auf die CX CPUs von Beckhoff, wo im Gehäuse ein EtherCAT Master direkt mit einem "Buskoppler" verdrahtet ist und an dem dann die Klemmen hängen. Da dies aber unsichtbar im CX verborgen ist spricht man davon, dass die Klemmen direkt an der CPU angeschlossen sind.
Aufgrund Deiner Angaben vermute ich, dass Du einen regulären PC als SPS einsetzt und bei diesem einen Netzwerkanschluss als EtherCAT Master, an diesen dann einen Buskoppler (z.B. EK1100) und an diesem hängen dann die Klemmen.
Zeig doch hier bitte einmal die genaue EtherCAT Topologie auf.
Nachtrag: Habe aufgrund Deiner Screenshots gerade gesehen, dass Du wohl tatsächlich keinen Beckhoff-IPC einsetzt. Da wäre jetzt die Frage, welchen Chipsatz (Hersteller) Deine Netzwerkkarte hat?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit Topologie war gemeint, wie der EtherCAT Bus bei Dir genau aufgebaut ist. @Cassandras Frage, ob die Klemmen direkt an der CPU hängen, bezieht sich (vermutlich) auf die CX CPUs von Beckhoff, wo im Gehäuse ein EtherCAT Master direkt mit einem "Buskoppler" verdrahtet ist und an dem dann die Klemmen hängen. Da dies aber unsichtbar im CX verborgen ist spricht man davon, dass die Klemmen direkt an der CPU angeschlossen sind.
Aufgrund Deiner Angaben vermute ich, dass Du einen regulären PC als SPS einsetzt und bei diesem einen Netzwerkanschluss als EtherCAT Master, an diesen dann einen Buskoppler (z.B. EK1100) und an diesem hängen dann die Klemmen.
Zeig doch hier bitte einmal die genaue EtherCAT Topologie auf.
Nachtrag: Habe aufgrund Deiner Screenshots gerade gesehen, dass Du wohl tatsächlich keinen Beckhoff-IPC einsetzt. Da wäre jetzt die Frage, welchen Chipsatz (Hersteller) Deine Netzwerkkarte hat?
Jetzt habe ich es verstanden – danke für die Erklärung! Ich verwende tatsächlich einen PC, und die vorhandene Netzwerkkarte ist eine Intel (23) I219-V. Hier auch nochmal die Topologie zur Übersicht:

1748268298734.png
 
Zuletzt bearbeitet:
Jetzt habe ich es verstanden – danke für die Erklärung! Ich verwende tatsächlich einen PC, und die vorhandene Netzwerkkarte ist eine Intel (23) I219-V. Hier auch nochmal die Topologie zur Übersicht:

Anhang anzeigen 87891
OK, laut dieser Liste sollte der Chipsatz unterstützt werden.
1748269377197.png
Du könntest zur Sicherheit im Gerätemanager mal die Karte auswählen und deren Eigenschaften öffnen, auf dem Reiter "Details" bei Eigenschaft "Hardware-IDs" auswählen und schauen, ob da "VEN_8086&DEV_1570" steht.
Hier mal als Beispiel die Eigenschaften einer Intel 82574L.
1748269638175.png
 

Installation der TwinCAT Realtime-Treiber​

Um einen Standard Ethernet Port einer IPC-Steuerung mit den nötigen Echtzeitfähigkeiten auszurüsten, ist der Beckhoff Echtzeit-Treiber auf diesem Port unter Windows zu installieren
-> siehe hier
 
Zuviel Werbung?
-> Hier kostenlos registrieren

Installation der TwinCAT Realtime-Treiber​

Um einen Standard Ethernet Port einer IPC-Steuerung mit den nötigen Echtzeitfähigkeiten auszurüsten, ist der Beckhoff Echtzeit-Treiber auf diesem Port unter Windows zu installieren
-> siehe hier
Der dürfte aber schon installiert sein, ansonsten wäre keine EtherCAT Kommunikation möglich.
 
Das Problem liegt an dem PC bzw der Config.

Der genaue Name des Netzwerk Treibers ist hilfreich.
Der "Intermediate Treiber" wäre NOK.
Ansonsten würde ich einen Core isolieren und die NC Task darauf laufen lassen.
Last not least: Was rennt noch parallel zur TwinCat Echtzeit was auf Treiberebene massive Resourcen benötigt (beliebt: Graphik-Rendering oder...).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
OK, laut dieser Liste sollte der Chipsatz unterstützt werden.
Anhang anzeigen 87892
Du könntest zur Sicherheit im Gerätemanager mal die Karte auswählen und deren Eigenschaften öffnen, auf dem Reiter "Details" bei Eigenschaft "Hardware-IDs" auswählen und schauen, ob da "VEN_8086&DEV_1570" steht.
Hier mal als Beispiel die Eigenschaften einer Intel 82574L.
Anhang anzeigen 87893
Tatsächlich wird bei mir eine andere Hardware-ID angezeigt – ich werde den alternativen Treiber mal installieren und testen.
1748420068999.png

Sicher?
Ich hatte normal immer Beckhoff-Hardware, meine aber mich erinnern zu können, dass mir der Support einmal empfohlen hatte den Treiber zu installieren. Doppelt hält besser... ;)
Danke auf jeden Fall für den Hinweis, ich werde den Treiber also noch einmal neu installieren.

Das Problem liegt an dem PC bzw der Config.

Der genaue Name des Netzwerk Treibers ist hilfreich.
Der "Intermediate Treiber" wäre NOK.
Ansonsten würde ich einen Core isolieren und die NC Task darauf laufen lassen.
Last not least: Was rennt noch parallel zur TwinCat Echtzeit was auf Treiberebene massive Resourcen benötigt (beliebt: Graphik-Rendering oder...).

Wenn ich das richtig verstanden habe, handelt es sich bei dem „Intermediate-Treiber“ vermutlich um den aktuell aktiven?

Parallel läuft bei mir noch eine Bildverarbeitungssoftware, allerdings zeigt der Task-Manager keine auffällige CPU-Last – zumindest nicht in dem Ausmaß, den du vermutest. An die Core Isolation habe ich bisher gar nicht gedacht – das werde ich ebenfalls mal testen.
 
Parallel läuft bei mir noch eine Bildverarbeitungssoftware, allerdings zeigt der Task-Manager keine auffällige CPU-Last – zumindest nicht in dem Ausmaß, den du vermutest. An die Core Isolation habe ich bisher gar nicht gedacht – das werde ich ebenfalls mal testen.

Nur mal zum generellen Verständnis: Die SPS-Runtime läuft nicht innerhalb des Windows. Darum kann das Windows und alle Programme im Windows die TC-Runtime nicht abwürgen. Es ist genau genommen anders herum: TwinCAT ist in der Lage Windows abzuwürgen. Darum gibt es die CPU-Last-Einstellung, die standardmäßig auf 80% steht. Damit wird dem Windows eine Prozessorreserve von 20% garantiert.

Wenn ich das richtig verstanden habe, handelt es sich bei dem „Intermediate-Treiber“ vermutlich um den aktuell aktiven?

Es ist noch schlimmer. Der „Intermediate-Treiber“ kommt nur für Simulationszwecke zum Einsatz, wenn die verwendete Netzwerkkarte nicht echtzeitfähig ist. Versuche zuerst mit dem Tool RTE-Install den TwinCAT Realtime Treiber auf die Karte zu bekommen. Wenn das wegen Inkompatibilität nicht geht, brauchst Du schlicht und einfach eine andere Netzwerkkarte.
Installation TwinCAT Realtime Treiber
 
Es ist noch schlimmer. Der „Intermediate-Treiber“ kommt nur für Simulationszwecke zum Einsatz, wenn die verwendete Netzwerkkarte nicht echtzeitfähig ist. Versuche zuerst mit dem Tool RTE-Install den TwinCAT Realtime Treiber auf die Karte zu bekommen. Wenn das wegen Inkompatibilität nicht geht, brauchst Du schlicht und einfach eine andere Netzwerkkarte.
Soweit es nicht mehrere Karten von Intel mit der Device ID (0x0DC6) gibt, sollte die Karte vom OP aber unterstützt werden, zumindest laut der Beckhoff Webseite.
1748421274502.png
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Soweit es nicht mehrere Karten von Intel mit der Device ID (0x0DC6) gibt, sollte die Karte vom OP aber unterstützt werden, zumindest laut der Beckhoff Webseite.
Dann wird der erste Schritt "Installiere den TwinCAT Realtime Treiber" ja funktionieren und der zweite Schritt "brauchst Du schlicht und einfach eine andere Netzwerkkarte" ist überflüssig. Aber der Reihe nach.
 
Zuletzt bearbeitet:
Zurück
Oben