WC State auslesen

[bonatus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

gibt es eine Möglichkeit den WC-State aller EtherCat Teilnehmer eines Masters in einem Array auszulesen? Analog dem Baustein FB_EcGetAllSlaveStates, in dem man den Zustand auslesen kann?

Ich benutze eine Beckhoff Steuerung mit E-Bus Teilnehmern

 

[bonatus]

Hallo,

da es wahrscheinlich nicht so mit dem Auslesen des States funktioniert, würde mich interessieren ob ihr den WC-State verwendet und wenn ja wie ihr eine Zustandsänderung handhabt?

 

[brcc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo, also ich kenn das nur über die Statusvariablen im Systemmanager. Da gibt es für jeden EtherCAT Frame ein Word, jedes Bit steht da für den Wc eines Datagrams. Solange da alles 0 ist ist alles gut. Warum willst du das aus der SPS auslesen? Das ginge dann ja über ADS und ist damit nicht mehr in Echtzeit - bekommst dann also nicht mehr hart in jedem Zyklus mit, ob der letzte Buszyklus erfolgreich war.
Ich mach üblicherweise einen FB zwischen jede Klemme und die Applikation, der die Klemmendaten nur weitergibt wenn Wc=0 und der Status stimmt. Ansonsten eben Warnung ausgeben.
Gruss, brcc

 

[bonatus]

Hallo,

Also der Grund fürs auslesen ist folgender: Wir haben herausbekommen das, wenn der WC State ungültig ist - werden die letzten Zustände von Eingangsklemmen eingefroren. Das ist relativ gefährlich. Das mit der Echtzeit ist bei unseren Anlagen nicht so kritisch, 1 Sekunde Verzögerung wäre noch nicht kritisch.
Mich würde interessieren wie du den FB zwischen jede Klemme und Applikation einbindest. Wir haben Anlagen mit bis zu 500 E/A Klemmen.

 

[trinitaucher]

Wir haben herausbekommen das, wenn der WC State ungültig ist - werden die letzten Zustände von Eingangsklemmen eingefroren.

Das ist so gewollt, weil der Frame beschädigt sein könnte und die Daten dann ungültig wären.
Die NC z.B. reagiert automatisch darauf und setzt die Achsen in Fehlerzustand.

...Da gibt es für jeden EtherCAT Frame ein Word, jedes Bit steht da für den Wc eines Datagrams. Solange da alles 0 ist ist alles gut.

Ich würde's auch über das Word vom Prozessabbild des EtherCAT-Masters machen. Ist einfacher als die einzelnen Bits der Slaves abzufragen.
Die Slaves werden eh zu "Sync Units" gruppiert. Wenn ein Slave aus der Gruppe einen Fehler hat, werden alle Prozessdaten der anderen Salves dieser Gruppe ebenfalls ungültig. Also genügt es den de WC-Status der Gruppe abzufragen.

Die Sync Units kann man übrigens auch selbst anlegen, also Slaves verschiedenen Gruppen zuordnen, z. B. eine Gruppe für alle Klemmen eines Schaltkastens. Dann sind im Fehlerfall nicht die Slaves aus anderen Gruppen betroffen:
http://infosys.beckhoff.de/index.ph...html/ethercat_syncunitassignment.htm&id=10504

 

[bonatus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das mit der Zuordnung von SyncUnits haben wir schon realisiert. Also jeder Koppler bekommt eine Unit. Vom EtherCat her gibt es dann auch noch eine Unterteilung in Ein- und Ausgänge.
Es geht nur darum eine Möglichkeit zu finden den WC State aus der PLC auszulesen. Damit man einzelne Teile der Anlage gezielt abschalten kann.
Über die EtherCat Adresse, machen wir zur Zeit eine Fehlerauswertung über den Status (Init, PreOp, SafeOp und Op). Wenn ein Teilnehmer nicht im Op ist geben wir eine Fehlermeldung an und Zeigen dann in der Visu den Fehlerhaften Teilnehmer mit dem Namen als String aus dem System Manager an z.B.: "I123 (EL1008)".
Zusätzlich wollen wir halt den WC State als zusätzlichen Fehler ausgeben.

 

[trinitaucher]

Das mit der Zuordnung von SyncUnits haben wir schon realisiert. Also jeder Koppler bekommt eine Unit.

Ich hoffe ihr habt nicht nur die Koppler, sondern auch alle daran hängenden Klemmen in die gleiche Sync Unit gepackt. Die "Koppler" sind ja keine Koppler im Sinne der "BK...", sondern wandeln nur die Physik auf E-Bus, werden Datentechnisch aber wie Klemmen behandelt.

 

[bonatus]

Ja. In der Zuordnung der SyncUnits kann man die Koppler nicht zuordnen.
Also wir haben alle Klemmen eines Koppler (ohne den Koppler selber) als Sync UNit

 

[soma]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir haben Anlagen mit bis zu 500 E/A Klemmen.

alter Schwede, was automatisiert ihr denn!!!*vde*

 

[Raydien]

Hallo,

Also der Grund fürs auslesen ist folgender: Wir haben herausbekommen das, wenn der WC State ungültig ist - werden die letzten Zustände von Eingangsklemmen eingefroren. Das ist relativ gefährlich. Das mit der Echtzeit ist bei unseren Anlagen nicht so kritisch, 1 Sekunde Verzögerung wäre noch nicht kritisch.
Mich würde interessieren wie du den FB zwischen jede Klemme und Applikation einbindest. Wir haben Anlagen mit bis zu 500 E/A Klemmen.

Das Schlimme ist auch das deine Eingänge einfrieren die Ausgänge aber funktionieren... um dies zu beseitigen musst du im System Manager mit der Sync Unit Zuordung arbeiten (zB. für jeden Buskoppler eine eigene Sync Unit) dies verhindert dann auch wenn 1 Teilnehmer in Stop geht das der gesamt Bus steht.


--- Edit ---

Thred sollte man schon zuende lesen...

 

[Pippen]

@bonatus
Wieso willst Du der WcState aller Klemmen in einem Array?
Wir haben auch pro Klemme einen FB, welcher alle verknüpfbaren Variablen, somit auch den WcState, enthält. So kannst Du gezielt etwas abschalten oder eine Warnung ausgeben.
Auch wir haben zum Teil mehrere hundert Klemmen an einem Master.

Frage:
Habt ihr keine Probleme bei grossen Konfigurationen im SystemManager?

 

[MarkusP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Probleme?

@Pippen

Probleme welcher Art meinst Du?
Beckhoff hat keine Probleme... (nur ich)

Generell ist das mit dem WcState so eine Sache. Wenn ich das für meine Programme fertig durchdenke, müsste man jeden Eingang auch noch auf Gültigkeit prüfen und entsprechend reagieren, wenn der WcState ungültig ist. Da besteht dann das Programm mehr aus Code wegen dem Ethercat als wegen dem Programm an sich... Ich glaube diese Problematik ist nicht jedem wirklich bewußt, bis es wie bei uns das erste mal richtig knallt.

Die BK9000 frieren den Eingangszustand übrigens auch ein, wenn z.B. das Netzwerkkabel abgezogen wird. Habe das bei der Entwicklung schon vorgeschlagen, es ähnlich zu machen wie z.B. beim Profibuskoppler, da kann man wählen wie die Eingänge im Fehlerfall reagieren sollen. Wurde sogar in Aussicht gestellt, aber bis dato ist leider nichts passiert.

Schönes WE

 

[bonatus]

Hallo,

Beckhoff hat keine Probleme... (nur ich)

*ACK*

Das kenne ich. Die Fehler die wir haben, sind laut Aussage von Beckhoff nur bei uns.

Ich bin auch der Meinung man sollte sich nicht um den ganzen Trödel mit dem Bussystem nicht in der PLC kümmern sollte. Der Aufwand wächst in unermessliche. Wir fangen an den WC-State von einer Ein- und Ausgangsklemme in einen Busskoppler in die PLC zu holen. (Wir geben jedem Koppler eine SyncUnit)
Es wäre programmtechnisch halt besser den WC State aus der PLC aus lesen zu können, da wäre der Aufwand etwas überschaubarer.