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

Koch

Level-1
Beiträge
82
Reaktionspunkte
6
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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.

Code:
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

Code:
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ß
 
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
 
Zuletzt bearbeitet:
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.

455.jpg


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.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
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ß
 
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:

750_474-Leitungsbruch.png

Grüße
 
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
 
Zurück
Oben