# Wago AIs (z.B. 750-474), Drahtbruch auswerten



## Koch (3 November 2015)

Hallo zusammen

ich möchte an einer Wago-Steuerung 750-8203 den Drahbruch der verwendeten Analogeingänge detektieren. Die Karten sind entweder direkt hinter die Steuerung gesteckt (der E-Bus ist eine Modbusvariante) oder dezentral über CANopen angeschaltet.
Die entsprechenden AI-Karten 750-474 werten ein 4-20 mA Signal auf einen Wertebereich von 0..32767 aus. Dabei ist alles zwischen 0..4 mA eine 0. Die Karte selbst wertet Unter- und Überstrom aus und signalisiert das auch mit einer LED, bzw. schreibt das in ein eigenes Statusbyte. Leider wird dieses Statusbyte weder vom Modbus noch von CANopen unterstützt (soweit ich weiß ist das die Hauptproblematik), weswegen man dieses Statusbyte nicht direkt adressieren kann.
Im Thread http://www.sps-forum.de/wago/54939-drahtbruch-erkennen-wago-plc.html wird diegleiche Frage gestellt. Dort antwortet *Thruser* das man die Funktion GET_TERMINALDIAG aus der Bibliothek wagolibterminaldig.lib nehmen soll. Allerdings habe ich zu dieser Bibliothek keine Doku gefunden und wenn ich die Funktion einbinde, dann bricht an meiner Steuerung 8203 (zumindest) die Kommunikation zusammen. Sie läßt sich aber auch nicht mehr mit dem Schalter stoppen/resetieren... also passiert da bestimmt mehr. Ev. ein Interrupt der in eine Schleife führt o.s.ä.

Hab mich zu dem Thema in den letzten paar Monaten auch 2mal beim Wagosupport gemeldet und bekam da keine befriedigenden Antwortenbekommen: "Geht nicht" bis "Geht bestimmt, nur nicht so einfach". Schade eigentlich, bisher war ich mit dem Wagosupport sehr zufrieden.

Hoffe jemand kann mir weiterhelfen oder die Doku zu der Bibliothek wagolibterminaldig.lib hier reinstellen, falls es die jemals gab. oder mir erklären wieso die Funktion GET_TERMINALDIAG bei meiner Steurung nicht oder nicht mehr funktioniert.


Gruß Felix


----------



## Thruser (3 November 2015)

Hallo,

der Support konnte mir damals auch keine Doku geben.

Habe gerade mal das alte Programm und die Mails vom Support durchgesehen.

Mit EN := True Eingang wird der FB ausgeführt. Scheint nicht flankengesteuert zu sein.

Der Ausgang ENO wird True wenn eine Änderung stattgefunden hat, also ein Fehler gekommen oder gegangen ist und auch nur in diesem Zyklus. In TERMINAL steht die aktuelle Klemmennummer (Position der Klemme), CHANNEL gibt den Kanal an. In Diag der Fehler des Statusbyte, z.B. 0x41 für Unterschreitung und 0x42 für Überschreitung.

Gruß

/EDIT: die lib funktioniert auch nur mit an der lokalen Steuerung. Die meisten Buskoppler bieten nicht die Möglichkeit das Statusbyte der Klemme mit über den Bus zu schicken.


----------



## Thruser (4 November 2015)

Hallo,

ich muß obige Aussage korrigieren. Habe das jetzt mit einer 8204 und einer 457 ausprobiert.

Der Ausgand ENO wird gesetzt wenn der Baustein erfolgreich ausgeführt wurde.

Hier mal ein kleines Testprogramm, wie gesagt, getestet mit 8204 und einer einzelnen 457.


```
PROGRAM PLC_PRG
VAR
    td:GET_TERMINALDIAG;
    A1:WORD;
    A2:WORD;
    A3:WORD;
    A4:WORD;
    test:BOOL;
    terminal:WORD;
    channel:WORD;
    diag:WORD;
END_VAR
```


```
A1:=AIN1;
A2:=AIN2;
A3:=AIN3;
A4:=AIN4;

TD(EN:=test);

IF TD.ENO THEN
    test := FALSE;

(*    IF TD.DIAGDATA>0 THEN
        terminal := TD.TERMINAL;
        channel := TD.CHANNEL;
        diag := TD.DIAGDATA;
    END_IF*)

    IF TD.TERMINAL>0 THEN
        terminal := TD.TERMINAL;
        channel := TD.CHANNEL;
        diag := TD.DIAGDATA;
    END_IF
ELSE
    test:=TRUE;
END_IF
```

Daten werden aber nur bei Zustandsänderung Fehler gekommen/gegangen angezeigt. Bei anliegendem Fehler wird die nächste Änderung angezeigt oder TERMINAL ist 0.

Ist aber im Programm schön zu sehen. Ich habe aber keine Ahnung was passiert wenn mehrere Änderungen gleichzeitig auftreten, ob dann alle nacheinander signalisiert werden? In welcher Reihenfolge? Vielleicht kann der WAGO Support noch etwas dazu sagen.

Gruß


----------



## Koch (4 November 2015)

Hallo Thruser

danke für die Unterstützung.
Der Baustein GET_TERMINALDIAG erzeugt nur dann eine Antwort, wenn sich eines der Statusbytes ändert. Und dann bringt er nur die Rückgabewerte und Adresse der letzten Karte im Rack.

Weiß einer ob das auch mit Baugruppen funktioniert, die über CAN open angeschlossen sind?

Gruß Felix


----------



## wat84 (5 November 2015)

Mit der 750-455 (4-Kanal, 4 - 20 mA, single ended) funktioniert das, da diese Karte den Dezimalwert 3 ausgibt, wenn Drahtbruch bzw. das Signal < 4 mA ist. Bei anderen Karten ist das ähnlich. 750-468 z.B. gibt 32761 als Wert bei Überspannung.
Ich weiß jetzt nicht inwieweit ein Wechsel des Analogeingangs deinerseits möglich ist. Man kann zumindest zukünftig die Anleitung dahingehend prüfen.





Edit: Jetzt sehe ich auch gerade warum. Weil deine Karte mit 16 bit auflöst und die 455 mit 12 bit. Da bleiben also von den 16 bit die übertragen werden 4 bit für den Status.


----------



## Thruser (5 November 2015)

Hallo,


Koch schrieb:


> Hallo Thruser
> 
> danke für die Unterstützung.
> Der Baustein GET_TERMINALDIAG erzeugt nur dann eine Antwort, wenn sich  eines der Statusbytes ändert. Und dann bringt er nur die Rückgabewerte  und Adresse der letzten Karte im Rack.



hatte gestern ein paar Probleme mit meinem Controller  und konnte erst jetzt testen. Da hast Du recht, wenn eine der hinteren  Karten oder auch Kanäle einen Fehler hat wird kein neuer Fehler bei  einer weiter vorne liegenden Karte oder Kanal mehr angezeigt. Da hat  WAGO mal wieder schlampig gearbeitet, wie bei vielem. Sieht man ja schon  bei der Doku zu der Funktion, ist einfach nicht vorhanden, obwohl in  den meisten Handbücher angegeben wird die Doku dazu ist unter  www.wago.com zu finden.

Ich habe mir noch die Funktion  KBUS_ERROR_INFORMATION aus der mod_com.lib angesehen, aber die  funktioniert auch nicht. Hängt wohl unter anderem mit der Einschränkung  bezüglich der synchronen KBUS Aktualisierung zusammen. Auch ist die Doku  unter wago.de dazu veraltet. Dort werden noch die beiden Parameter  ERROR und ERROR_ARG genannt, in der aktuellen lib sind die aber als  RESERVED benannt, wie auch in der CoDeSys Hilfe wenn man z.B. den 881  als Target gewählt hat. 

Schlampig eben.



> Weiß einer ob das auch mit Baugruppen funktioniert, die über CAN open angeschlossen sind?



Da mußt Du sagen wie Du die mit CANOpen angeschlossen  hast, aber beim 337 Buskoppler ist es unverständlich erklärt. Da wird  bei anderen Koppler wie der 352 (Modbus TCP / EthernetIP) wenigstens  angegeben, daß das Statusbyte nicht übertragen wird. Im CAN Konfigurator  habe ich auch nichts finden können.

Die gesamte Geschichte mit  den Statusbytes wird sowieso sehr stiefmütterlich behandelt, wie Du ja  auch bereits feststellen mußtest. 

Wir haben das damals dann auch  nicht richtig weiterbehandelt. Bei meinem aktuellen Projekt verwende  ich jetzt die 12bit Klemmen, wegen der unteren drei Fehlerbit.

Am  besten ist es wohl, wenn man eine höhere Auflösung benötigt, die  Ausführung mit S5 Datenformat zu nehmen, da kann man zusätzlich auch  noch darauf reagieren, wenn die Werte etwas ausserhalb des 4-20mA  Bereichs liegen.

Gruß


----------



## .:WAGO::016346:. (9 November 2015)

Hallo Koch,
das Statusbyte wird über den CAN Bus in einem Emergency Telegramm verschickt.
Bei Kabelbruch oder Überstrom wird das Telegegramm 00 FF 81 DD 07 PP SK NN gesendet. Beschrieben im Handbuch des CANopen Kopplers.
DD gibt das Statusbyte der entsprechenden Klemme wieder. Im Fall der 750-474 0x42 = Überstrom und 0x41 = Leitungsbruch.
PP: Position der Busklemme
SK: Fehlerstatus/Kanalnummer. MSB: True := gekommen, False := gegangen. Bit 2-0: Kanalnummer.
NN: Anzahl der Anliegenden Busklemmenfehler.
Das Emergency Telegramm kann über den Funktionsbaustein DiagGetState aus der BusDiag.lib ausgelesen werden. Dies ist im Handbuch des PFC200 im Kapitel "Erstellen von Diagnosefunktionen in CODESYS 2.3" beschrieben.
Im Array Extendedinfo sind die Emergencytelegramme nach dem vierten Element enthalten.

Das folgende Bild zeigt die Ansicht der DiagGetState Instanz mit einem anliegenden Leitungsbruch:




Grüße


----------



## Koch (10 November 2015)

Danke zusammen

da die Auswetung von Unter-/Überstrom zu umständlich ist habe ich mich im speziellen Anwendungsfall für ein Auswerten von 0 entschieden. Der Sensor bei dem ich Ausfallprobleme habe misst die luftfeuchte, da ist 0 g/kg eh nicht möglich.
Da wir gerade auf CoDeSys3 umsteigen werde ich da jetzt keine zeit mehr rein investieren.

Gruß Koch


----------

