TC2 Eingänge werden vom CX5010 nur im freerun angesprochen.

Beiträge
5.754
Reaktionspunkte
1.201
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich habe mal wieder ein seltsames Problem. An meinem CX5010 (2254) ist eine KL1408, eine KL2809 und natürlich ein KL9010 montiert. Lasse ich nach Geräten und dann nach Boxen suchen und anschließend den Free Run starten, kann ich die Ausgänge setzen und sehe an den Eingängen was für Signale anliegen. Sobald ich jedoch die Konfiguration aktiviere erkennt die Eingangskarte keine Signale mehr. Dies passiert mit und ohne verknüpftem SPS-Projekt und es ist auch egal, ob Variablen zugeordnet sind.
Wer kann hier helfen?

Gruß

Oliver

Von irgendwas mit Internetzugang gesendet.
 
Der Klassiker wäre das die PLC-Task nicht läuft.
Jeder Feldbus im TwinCAT benötigt eine zyklischen Trigger. Wenn die PLC noch nicht gestartet ist fehlt dieser.
Der Freerun ist wie der Name sagt keine Echtzeit und der benötigt diesen Trigger nicht.

Alternative zur PLC Task: Zusaetzliche freie Task erstellen mit einem Eingang, diese auf eine Eingangs-Klemme verknüpfen sodass der Trigger über diese TAsk kommt. Bei TC2 bitte darauf achten das bei dieser freie Task auch der Autostart - Haken gesetzt ist (nicht der Default).

Guga
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Guga,
danke für Deine prompte Antwort. Es war auch der Klassiker, aber nicht nur. Ich arbeite den Kunden meist nur zu, daher habe ich mit der Hardwareseite meist nichts zu tun und so habe nicht mehr daran gedacht, dass das SPS-Programm laufen muss. Das Hauptproblem ist jedoch ein anderes was ich allerdings auch nicht ganz verstehe. Ab einer Zykluszeit von 100ms oder langsamer werden die Eingänge nicht mehr bearbeitet.

Von irgendwas mit Internetzugang gesendet.
 
Auch dafür gibt es eine Erklärung. Der Watchdog der Klemmen schlägt zu. So ab 80 msec dürfte es je nach EtherCAT Slave der Fall sein.

-> seperate Task wie oben gesagt oder Watchdog ausschalten (naja, wirklich empfehlen tue ich das nicht) oder aber die PLC Task schneller durchführen (wenn die Auslastung des Systems es hergibt was ich aber erst einmal glaube). 100msec ist EtherCAT-technisch mehr als eine Ewigkeit.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Guga,
100msec ist EtherCAT-technisch mehr als eine Ewigkeit.
Erstmal muss ich ein Missverständnis aufklären, ich habe KL-Klemmen und nicht EL-Klemmen, also einen K-Bus und keinen E-Bus.
Auch dafür gibt es eine Erklärung. Der Watchdog der Klemmen schlägt zu. So ab 80 msec dürfte es je nach EtherCAT Slave der Fall sein.
Dann muss der Watchdog aber eine Standardvorgabe sein, denn ich habe keinen definiert. Richtig verrückt ist es geworden, als ich neben der Standard-Task eine zweite Task mit einer Zykluszeit von 1 Sekunde angelegt hatte und dieser das Lauflicht zugewiesen hatte. Bei einer Zykluszeit der Standard-Task von 10ms war alles in Ordnung, zumindest soweit ich dies ohne Oszi beurteilen kann, aber als ich die Zykluszeit auf 250ms gesetzt hatte blitzte der jeweils aktive Ausgang vom Lauflicht jeweils vier mal auf und das Eingangssignal kam wieder nicht in der SPS an, obwohl die LESD leuchtete.
 
Hallo MasterOhh,

Ja, weil ich es so wollte. ;-)

Aber im Ernst, das Lauflicht sollte ca. jede Sekunde weiterschalten und da habe ich in meinem jugendlichen Leichtsinn das Ganze halt über eine Zykluszeit von 1s gelöst.

Mit einem einfachen Timer hättest du wahrscheinlich weniger Probleme gehabt ;)

Interessant ist das Thema allemal, ich nutzen idR immer die Standard 10ms Zykluszeit. Nur wenn ich z.B. für Kommunikationsgeschichten einen schnelleren Task brauche mache ich einen 2ten auf. Kürzere Zykluszeiten scheinen die Steuerungen scheinbar besser zu verkraften als längere.
 
Zurück
Oben