TIA Flackernde Digital-Ausgänge bzw. Ausgangs Byte CPU 1516F-3PN/DP

leitold1991

Level-1
Beiträge
4
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Liebe Forum Mitglieder,

ich lese schon lange dankend mit, doch nun kommt mein erster Beitrag zu einem mir nicht nachvollziehbaren Problem.

Kurzes Vorwort zur Situation:

Bei einer unseren Produktionslinien wurde ein Anlagenteil ausgetauscht. Der Lieferant hat seine eigene CPU (1516F-3PN/DP) verbaut.
Unsere Linie läuft über eine 1518T-4PN/DP CPU. Der Datenaustausch findet per I-Device über PN statt. Das ganze läuft in der TIA-Version V19 ab.

Nun zum eigentlichen Problem:

An der 1516F CPU haben wir das Problem, dass der DO A0.0 bzw. alle Bits am AB0 "flackern" sobald diese im FB angesteuert werden (ext. Peripherie ET200SP).
Nicht nur die LED´s sondern auch die Hardware (in diesem Fall ein Relais).
Ich kann den Fehler an allen 8 Bits reproduzieren.
DO-Karte ist eine 6ES7 132-6BF01-0BA0.

Bisherige Erkenntnis:

Wenn ich z.B. den A0.0 force funktioniert dieser auch einwandfrei.
Auch habe ich im OB1 im NW1 per AWL den Ausgang angesteuert und mit einem BEA die restlichen Aufrufe des Programmes deaktiviert, dann funktioniert der Ausgang ebenfalls reibungslos.

Nun bin ich ratlos, da es sich um ein doch recht großes Anwenderprogramm handelt.

Ich finde weder im Belegungsplan noch in der Querverweisliste etwas auffälliges wie z.B. eine Überschreibung eines Wortes o.ä.!

Hat hier zufällig jemand eine Idee wie so etwas zustande kommen kann? Habe im Internet bereits von indirekter Adressierung etc. gelesen welche so etwas verursachen kann. Jedoch kann ich den Fehler einfach noch nicht eingrenzen.

Wäre über jede Hilfe von euch dankbar :-)
 

Anhänge

  • Belegungsplan.jpg
    Belegungsplan.jpg
    63,9 KB · Aufrufe: 19
Mal versucht, dass Ausangsbyte auf eine andere freie Adresse zu legen? Am besten vielleicht auf eine relativ hohe.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Idee hatte ich auch schon, aber leider war noch kein Anlagenstillstand bzgl. Hardware-Konfiguration ändern.
Ich denke das würde das Problem beheben, aber die Ursache wäre für mich definitiv interessanter. :)
 
Ja es existieren 4 AWL-Bausteine in den "99.LIBRARY BLOCKS".

Könnte das Problem hier zu finden sein?

Besten Dank übrigens schon für die raschen Rückmeldungen!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... Auch habe ich im OB1 im NW1 per AWL den Ausgang angesteuert und mit einem BEA die restlichen Aufrufe des Programmes deaktiviert, dann funktioniert der Ausgang ebenfalls reibungslos...

Und ohne das BEA flackert's wieder? Platziere in dem Fall das BEA abschnittsweise nach "hinten". Ich würde das aber erst einmal im Simulator testen.

Deckt sich die Frequenz des Flackerns mit der Zykluszeit oder mit einem Weckalarm oder vielleicht auch mit einem Taktmerker?
Welche OBs werden verwendet?

Laut Belegungsliste wird vom AB0 nur das Bit 0 im Programm verwendet. Wenn bei deinen Tests die anderen Bits dieses Bytes auch flackern, wenn sie von dir gesetzt werden, dann könnte es an einer fehlerhaften indirekten Adressierung liegen, wie Jesper es wohl auch vermutet.
 
Zuletzt bearbeitet:
Ja genau, habe im OB1 auch ohne BEA den Ausgang angesteuert, da flackert dieser auch!

Genau das würde mich interessieren, was bedeutet eine „fehlerhafte indirekte Adressierung“ bzw. wie könnte man das feststellen?

Ich vermute eben auch dass genau das dass Problem ist, jedoch gebe ich zu, dass meine Kenntnisse hier aufhören!
 
Du kannst da nur durch Eingrenzen dahinter kommen.
Im OB1 werden doch sicherlich mehrere Bausteine aufgerufen. Verschiebe jetzt einfach, wie vorgeschlagen, das BEA Baustein-Aufruf für Baustein-Aufruf nach hinten. Wenn es irgendwann wieder flackert hast du schonmal den Baustein.
Jetzt kann es natürlich sein, dass dieser Baustein wiederum weitere Bausteine aufruft. Da dann also wieder das gleiche Spiel.
Ruft der keine weiteren Bausteine auf dann schaue in dem Baustein selbst mal nach Pointern - also irgendetwas mit P#...
Gibt es davon mehrere Netzwerke dann hier auch wieder das BEA-Spiel (als erste Anweisung im Netzwerk).
Da du ja sagst, das dies nicht so dein Thema ist kannst du dann den Code des Bausteins, den du gefunden hast, hier auch posten.

Du brauchst also einen Stillstand der Anlage und Zeit ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hast Du noch Weckalarme benutzt, z.B. OB35? Oder weitere andere OBs?

Was heisst "Flackern"? Regelmäßig im 1s Takt oder unregelmässig alle 0,1s? Video?

Muss ja nicht zwingend ne (mehrfache) (indirekte) Zuweisung des Ausgangs sein, sondern könnte auch nen Programmierfehler an der regulären einmaligen Zuweisung. Stell hier mal den Code von der Zuweisung des Ausgangs im Programm rein.

Ziemlich schwierig aus der Ferne und ohne das Programm zu kennen hier Tips zu geben.
 
Zuletzt bearbeitet:
Ja genau, habe im OB1 auch ohne BEA den Ausgang angesteuert, da flackert dieser auch!
am Anfang oder am Ende vom OB1?
Hast Du nur ein Bit beschrieben oder das ganze Byte?

Der A0.0 ist nen normaler Ausgang oder nen fehlersicherer?

Spielt da irgendwie der F-Programmteil mit rein?

Wie oft wird der A0.0 im Programm beschrieben/verwendet?

Ganz wild, m.M. kann man auch über das HMI oder Put/Get Ausgänge beschreiben. Das findest nie, da hilft nur andere Adresse verwenden.

was ist mit dem Originalprogrammierer der 1516, kann man den mal anrufen?
 
Zuletzt bearbeitet:
Die Idee hatte ich auch schon, aber leider war noch kein Anlagenstillstand bzgl. Hardware-Konfiguration ändern.
Ich denke das würde das Problem beheben, aber die Ursache wäre für mich definitiv interessanter. :)
Das wäre ja nur der erste Schritt. Du hättest erstmal Ruhe vor dem Fehler und könntest dann ein Byte auf die alte Adresse legen und in Ruhe suchen, ohne dad die Ausgänge betroffen wären.

Ich hatte früheröfter das Problem, wenn über idevice auch safety lief, das es da manchmal Überschneidungen gab. Wenn ich mich recht erinnere, wurde das nicht im Belegungsplan nicht angezeigt (v17).
 
Bei einer unseren Produktionslinien wurde ein Anlagenteil ausgetauscht. Der Lieferant hat seine eigene CPU (1516F-3PN/DP) verbaut.
Unsere Linie läuft über eine 1518T-4PN/DP CPU.
Ich habe jetzt nicht alles gelesen. Was ich mir vorstellen könnte wäre noch, dass im Programm ( kann in AWL sein, ist in SCL aber auch möglich ) indirekt adressiert wurde ( also keine Querverweise ) und durch eure Programmänderung die DBs welche ggf. die Startadressen enthielten alle reinilialisiert wurden ( auf 0 ). Ggf. sorgen dann auch noch Peripheriezugriffe ( : P ) für das geflackere ( mehrfache Statusänderungen pro Zyklus ).

Nur mal als Gedankenanstoß
 
Zurück
Oben