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

leitold1991

Level-2
Beiträge
10
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: 25
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 angezeigt (v17).
 
Zuletzt bearbeitet:
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ß
 
Wir hatten hier im Form vor einiger Zeit mal Jemanden mit einem ähnlichen Problem. Obwohl sie korrekt programmiert war, hatte bei ihm eine Flankenerkennung nicht funktioniert. Er hatte dann sein Programm hier hochgeladen und der Fehler wurde in kürzester Zeit gefunden. Damals bstand der Fehler darin, dass ein FB im OB1-Zyklus und mit der selben Instanz in einem anderen OB aufgerufen wurde.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@ducati : Safety und HMI fällt aus meiner Sicht raus, da das Ganze ja korrekt läuft mit einem BEA im OB1. Das Gleiche gilt n.m.M. auch für Blinkmerker ...
theoretisch ja, mit dem BEA (am Anfang vom OB1) wird aber die Zykluszeit des OB1 so stark verkürzt, dass ein eventueller externer Zugriff (aus nem anderen OB oder von ner anderen SPS oder sonstwoher) viiiiel schneller wieder übergebügeld werden würde...
 
Zuletzt bearbeitet:
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 ...

Ja das dachte ich mir fast.
Das müsste ich dann im Stillstand einplanen.

Das mit dem Code des Bausteines kann ggf. nach meinem Urlaub in den nächsten 2-3 Wochen ggf. nachholen :)
 
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.

Es werden definitiv mehrere OB´s genutzt. Ob der OB35 dabei ist kann ich nicht auswendig sagen, da ich nun im Urlaubsmodus bin. Kann aber eben in den nächsten 2-3 Wochen mehr dazu sagen.

Das "Flackern" äußert sich durch ein unregelmäßiges hochfrequentes permanentes Flackern.
Video kann ich dann ggf. auch nachreichen.

Ja werde das natürlich nachholen und mehr Infos posten. Vielen Dank für die Inputs bisher.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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?

Habe das am Anfang und am Ende vom OB1 versucht, bei beiden Varianten war das Flackern weiterhin vorhanden.

A0.0 ist ein ganz normaler Ausgang.

F-Programmteil denke ich nicht, müsste ich mir in dieser Richtung genauer ansehen.

Der A0.0 wird nur in einer stelle laut Querverweisinformationen verwendet.

HMI ist auch eine gute Überlegung, wusste ich gar nicht dass das auch möglich ist :) Und wieder danke...!
Von euch lernt man jede menge dazu 😊

Der Anlagenhersteller/Programmierer war sogar noch vor Ort. Den hat das nicht wirklich interessiert.
Der hat einfach den Draht vom A0.0 auf einen DO von einer naheliegenden S120 CU umgelegt, das Programm angepasst und fertig.
Obwohl ich ihm schon die Info gab, dass der Ausgang beim forcen funktioniert. 😅 Der hatte 5 Minuten nachgesehen was los sein könnte, und dann aber scheinbar klein bei gegeben.
 
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 angezeigt (v17).

Die Idee finde ich auch gut. Wird wahrscheinlich die sinnvollste Lösung sein.
Da die Anlage 24/7 betrieben wird ist das die beste Option.

Ah okey? Dann habe ich hier auch wieder einen Ansatz welchen ich verfolgen könnte.
Danke auch dir Mrtain. 🙂
 
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ß

Auch dir danke ich für diesen Ansatz. Ja AWL und SCL Bausteine sind vorhanden.
Aber wie könnte man das nachverfolgen? Bzw. wie würdest du an die Sache ran gehen?

Mir ist bewusst dass das schwierig ist, ohne das Programm vor sich zu haben.

Bin jedoch trotzdem über jeden Lösungsvorschlag überaus dankbar!
 
Zurück
Oben