Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 14

Thema: TwinCat 3: Emergency Message

  1. #1
    Registriert seit
    31.07.2010
    Ort
    Bei Frankfurt/Main
    Beiträge
    49
    Danke
    7
    Erhielt 14 Danke für 13 Beiträge

    Frage


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo und guten Abend,

    ich schreibe aktuell einen Baustein zur Anbindung von Yaskawa-Sigma7-Servos an eine Beckhoff-Steuerung. Die Kommunikation läuft über EtherCat.
    Das klappt auch wirklich hübsch inzwischen, allerdings macht mir das Error-Handling Kopfzerbrechen. Dabei geht es mir um die im Regler anfallenden
    Fehlermeldungen, die im Prinzip per SDO aus einem Objekt gelesen werden können.

    1) in dem Vorgängerbaustein unter CANopen hatte ich einen Zugriff auf die von der Steuerung empfangenen Daten des Emergency Telegramms.
    Hier findet sich u. a. der Fehlercode des Regler wieder. In der Beckhoff-Hilfe wird auch öfters von diesem gesprochen und die empfangenen Daten
    landen auch im Output-Bereich von Twincat, aber ich finde einfach nicht, wie ich diese Daten von meinem SPS-Programm aus abholen kann.
    Gibt es da eine Möglichkeit.

    2) das zweite Problem ist ein wenig merkwürdig und es ist mir nicht ganz klar, ob die Steuerung oder der Servo dies erzeugt: mit dem Auftreten
    eines Fehler springt der Regler aus dem Zustand Operational heraus und tauscht keine PDOs mehr aus. Man kann nun in der Steuerung einen
    automatischen Neuverbindungsversuch anhaken ... aber so richtig hübsch ist das nicht. Dies führt im Regler zu einem neuen Fehler
    (einem Kommunikationsfehler), der den ursprünglichen überschreibt. Kann man das Verhalten irgendwie einstellen?

    Vielen Dank
    K. Kilper
    Viele Grüße
    Klaus Kilper

    ======================================
    Bretzel GmbH, Ing. Büro für Antriebs- und Elektrotechnik
    www.bretzel-gmbh.de
    Zitieren Zitieren TwinCat 3: Emergency Message  

  2. #2
    Registriert seit
    31.07.2010
    Ort
    Bei Frankfurt/Main
    Beiträge
    49
    Danke
    7
    Erhielt 14 Danke für 13 Beiträge

    Standard

    Hallo allerseits,

    Frage 2 hat sich inzwischen geklärt. Dies ist ein Bug in der Reglerfirmware, der herstellerseitig gelöst werden wird.

    Nach wie vor würde mich aber interessieren, wie man den Inhalt des Emergency-Telegramms unter Twincat herankommt.

    Viele Grüße
    Klaus Kilper
    Viele Grüße
    Klaus Kilper

    ======================================
    Bretzel GmbH, Ing. Büro für Antriebs- und Elektrotechnik
    www.bretzel-gmbh.de

  3. #3
    Registriert seit
    17.12.2015
    Beiträge
    32
    Danke
    0
    Erhielt 9 Danke für 9 Beiträge

    Standard

    Hallo,
    Der Inhalt des Emergency-Telegramms kann über ADS ausgelesen werden.
    vielleicht hilft dir dieser Link etwas weiter:
    http://infosys.beckhoff.com/content/...49112661022181
    Geändert von Paulchen_1 (22.06.2016 um 07:26 Uhr)

  4. #4
    Registriert seit
    10.08.2012
    Beiträge
    245
    Danke
    0
    Erhielt 70 Danke für 66 Beiträge

    Standard

    @Paulchen: Dein Link führt zum CANOpen Master.
    Was Klausbre allerdings fragt ist die Emergency-Nachricht vom EtherCAT-Device. Diese sind standardisiert, ich habe sie auch ab- und an schon gesehen aber mir sie noch nie logisch in ein PLC-Programm (o.ä.) integriert.

    @Klausbre: Die CANOpen Emergency Lösung ist wichtig damit eine Info tatsächlich auf dem Bus übermittelt werden. Bei EtherCAT sind aber alle Prozesstelegramme zyklisch sodass du immer eindeutig weisst ob der Slave betriebsbereit ist (WcState = 1 und State = OP).

    Guga

  5. #5
    Registriert seit
    17.12.2015
    Beiträge
    32
    Danke
    0
    Erhielt 9 Danke für 9 Beiträge

    Standard

    Hallo,

    meinst du diesen Telegrammaufbau, Guga?
    http://infosys.beckhoff.com/content/...15214316414213

    Die Emergency-Nachricht sieht dann so aus:
    Struktur der Emergency-Nachricht
    Das Emergency-Objekt ist stets 8 Byte lang; es enthält zunächst den 2-Byte Error Code, dann das 1-Byte Error Register und schließlich den 5 Byte großen Additional Code. Dieser teilt sich in ein 2-Byte Bitfeld und ein 3-Byte Parameterfeld auf:
    11-bit Identifier 8 Byte Nutzdaten
    0x80 (128dez) + Node-ID EC0 EC1 EReg Bitfeld0: Comm Bitfeld1: DevErr EMCY Trigger Info0 Info1

  6. #6
    Registriert seit
    10.08.2012
    Beiträge
    245
    Danke
    0
    Erhielt 70 Danke für 66 Beiträge

    Standard

    Hi Paulchen,

    die Emergency-Objekte werden von den EtherCAT-Slaves geworfen. Das passiert klassischerweise wenn die Konfig nicht stimmt. Der Mechanismus ist von CAN abgeleitet. Wie gesagt macht es bei CAN sehr viel Sinn um sicherzustellen das die Info auch im Master ankommt. Im EtherCAT bin ich mir hier nicht sicher das es relevant ist.

    Wenn der EtherCAT-Master den Slave nicht zum laufen bringt sehe ich die Ursache en Detail. Wenn der Slave noch antwortet (PreOp oder höher) dann ist im allgemeinen der Fehler auch irgendwo in einem CoE-Objekt im Slave hinterlegt. Wenn der Slave nicht kommuniziert... ist eh alles hinfällig.

    Da aber einige EtherCAT-Implementierungen eine Portierung von einem CANopen Device zu grunde liegt haben einige Hersteller die Emergency-Telegramme im Slave. Dein Link zielt wieder auf CAN... hat also nichts mit EtherCAT zu tun.

    Guga


    emergency.jpg

  7. #7
    Registriert seit
    17.12.2015
    Beiträge
    32
    Danke
    0
    Erhielt 9 Danke für 9 Beiträge

    Standard

    Hi Guga,
    danke für den Hinweis. Habe es nicht richtig gelesen und dachte, der Servo läuft als CAN-Slave.
    Direkt im Ethercat sollte es doch noch einfacher sein!?
    Wenn das Gerät es zulässt, müsste doch ein Zugriff über CoE / ADS möglich sein.
    Gibt es keine Beschreibung der Daten auf dem Gerät?
    Gruß Paulchen

  8. #8
    Registriert seit
    07.09.2016
    Beiträge
    14
    Danke
    7
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Ich weiß der Thread ist alt, aber ich stehe aktuell vor einem sehr ähnlichen Problem.

    Verstehe ich das richtig so, das man unter EtherCAT die Emergency Nachrichten nicht benötigt weil die Fehler auch an andere Stelle im Slave abrufbar sind und einfach zyklisch gepollt werden können?
    Unter Codesys gibt es die Möglichkeit die letzte Emergency Msg auszulesen (IoDrvEtherCATLib.ETC_CO_Emergency : struct), unter TwinCat fehlt mir diese Möglichkeit jedoch...


    Mein Aufbau soll gleichermaßen mit Codesys 3.5 und Beckhoff Tc3.1 Steuerungen laufen und die gleichen Funktionalitäten bieten. Die Programmarchitektur wird daher bis auf herstellerspez. Lib. Bausteine gleich sein.

  9. #9
    Registriert seit
    16.12.2015
    Ort
    Innsbruck
    Beiträge
    36
    Danke
    11
    Erhielt 8 Danke für 8 Beiträge

    Standard

    Unterstützt dein Regler ein Standard Protokoll wie das CiA402? also mit controlWord und statusWord?
    Falls ja kannst du doch im Statuswort das Fehlerbit pollen, das sollte ja zyklisch kommen und dann wenn es kommt dieses Diagnosedatum rauflesen.
    Normalerweise ist das einfach ein Parameter mit Index und Subindex den liest du mit dem Baustein FB_ECCoESdoRead (https://infosys.beckhoff.com/content.../56996235.html) ein.

    Falls kein Standardprotokoll hinterlegt ist, kannst du sicher irgendein Fehler/Warnungs Bit in das zyklische Abbild geben und dann pollst du eben dieses.

    Wir mussten uns eigentlich für jeden CoE-fähigen Controller deren spezifisches ErrorHandling einbauen. Am schönsten war bis jetzt immer noch das von der ETG standardisierte Format, das ist so ähnlich aufgebaut wie oben erklärt -> ein Datum aus ein paar Byte (kein Standard-Datentyp). Den liest man in ein Array of Byte ein und mit einem Union kannst du dann gemütlich aus der parallel liegenden Struktur auf die Daten zugreifen.

    Sg

  10. Folgender Benutzer sagt Danke zu seehma für den nützlichen Beitrag:

    stseme04 (15.05.2017)

  11. #10
    Registriert seit
    07.09.2016
    Beiträge
    14
    Danke
    7
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von seehma Beitrag anzeigen

    Wir mussten uns eigentlich für jeden CoE-fähigen Controller deren spezifisches ErrorHandling einbauen. Am schönsten war bis jetzt immer noch das von der ETG standardisierte Format, das ist so ähnlich aufgebaut wie oben erklärt -> ein Datum aus ein paar Byte (kein Standard-Datentyp). Den liest man in ein Array of Byte ein und mit einem Union kannst du dann gemütlich aus der parallel liegenden Struktur auf die Daten zugreifen.

    Sg
    Der Teil mit dem spezifischen ErrorHandling beruhigt mich schon mal. PL möchte nämlich eine universelle Lösung - die Eierlegende Wollmichsau des Diagnosehandlings sozusagen...
    Ich hatte gehofft ich könnte über das Standard Protokoll gehen und die Emergencies direkt abfangen. Der von dir vorgeschlagene Weg über Mapping SDO<->PDO war von mir auch schon als Alternative angedacht, scheint als ob mir erstmal nichts anderes übrig bleibt.

    Der Teil mit dem Union erschließt sich mir allerdings noch nicht ganz, hatte vor die Daten stur in ein Byte Array zu speichern, über die Auswertung hatte ich mir bisher noch keine Gedanken gemacht

Ähnliche Themen

  1. InTouch - I/O Message
    Von jbloder im Forum HMI
    Antworten: 1
    Letzter Beitrag: 14.10.2011, 12:57
  2. Twincat, Unterschied zw. ADS-Hauptgerät (Message-Router) und anderen
    Von JoergHedt im Forum CODESYS und IEC61131
    Antworten: 2
    Letzter Beitrag: 18.04.2011, 16:57
  3. Message Box in Twincat Visu
    Von gloeru im Forum CODESYS und IEC61131
    Antworten: 3
    Letzter Beitrag: 27.02.2011, 20:37
  4. Bewertung einer EMO-Abschaltung (Emergency OFF) nach DIN 13849
    Von andrejtm im Forum Maschinensicherheit - Normen und Richtlinien
    Antworten: 5
    Letzter Beitrag: 28.01.2011, 18:10
  5. CANopen/CoDeSys 2.3 - Verarbeitung der Emergency Message
    Von Hoh im Forum CODESYS und IEC61131
    Antworten: 2
    Letzter Beitrag: 12.04.2010, 13:12

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •