TIA Merker in einem NW True und im anderen NW False

denz

Level-1
Beiträge
51
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich habe eine Leuchte, die blinken soll. Diese soll nur blinken wenn ein Merker gesetzt ist.
Leider funktioniert das bisher nicht.
Der Merker wird gesetzt. Die Online-Ansicht von Funktionblock A bestätigt dies:

Unbenannt1.png

In der Variablentabelle wird es auch angezeigt:

Unbenannt3.jpg

Aber im Netzwerk des Funktionsblocks B leider nicht:

Unbenannt.png

Andere Netzwerke in diesem Funktionsblock funktionieren.

Ich kann mir nun nicht erklären wieso es in dem einen Netzwerk und in der Variablentabelle als True angezeigt wird und in einem anderen Netzwerk als False.

Vielleicht hat ja jemand einen Tipp für mich.


Gruß
 
Wird der Merker noch woanders aufgerufen und zwischenzeitlich wieder zurückgesetzt? Schau dir mal die Querverweise zu dem Merker an.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Merker wird an mehreren Stellen gesetzt und zurück gesetzt, aber das findet erst in nachfolgenden Schritten statt.
Zumal dann ja auch in Baustein 1 und der Variablentabelle der Merker nicht gesetzt sein dürfte. Ich kann zwischen den Netzwerken umherspringen und immer sieht es so aus wie auf den Screenshots.
Deshalb dachte ich auch erst es stimmt irgendwas mit dem FB nicht, aber wie gesagt funktionieren ja andere Netzwerke in dem FB.
 
Aber am Ende verhält es sich dennoch mitunter so wie UDP bereits schrieb.

Wir sehen hier natürlich nur einen kleinen Auszug, daher ist es schickes Rätseln, würde daher auch auf UDPs Vorschlag achten.

Würdest Du die Bausteine bzw. Querverweisliste des Merkers veröffentlichen? In der Regel steht in der Querverweisliste meistens bereits die richtige Anordnung in welcher Reihenfolge er beschrieben wird.

Und am Rande: Der Merker befindet sich nicht in einem FB/FC der mehrfach aufgerufen wird?
 
Sieht halt trotzdem danach aus, als ob der Merker an einer Stelle zurück gesetzt wird, die du da nicht auf dem Schirm hast. Bezüglich dem Netzwerk wo er auf Eins ist: Du beobachtest du SPS in dem Zustand vom Zyklus, den die SPS an dieser Stelle im Programm hat. Dort ist er eins, da er gesetzt wird. Wenn du ihn später im Programm zurücksetzt (und dort immer setzt), dann wirst du ihn dort immer mit einer Eins beobachten können. Bei der Variablentabelle beobachtest du den Zustand den der Merker am Ende des Zyklus hat.

Generelle Frage, warum nutzt du den selben Merker mehrfach im Programm und setzt/rücksetzt ihn? Nimm doch für jede Informationen einen eigenen Merker (oder ein Bit in einem DB), dann kann man denen auch sinnvolle Namen geben, die im Nachhinein nochmal etwas über die Funktion des Merkers aussagen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Auch am Rande: Warum verwendest Du den LGF_Frequency für die Blinktakt-Erzeugung? Eine aufwendigere Variante für simples Blinken habe ich noch nicht gesehen...

Weiters: Weil Du Deinen Merker %M5.1 auf EN des FB LGF_Frequency gelegt hast: wenn %M5.1 FALSE ist dann wird der Baustein nicht aufgerufen und der Ausgang %Q1.1 erhält keine Zuweisung und bleibt wie er gerade ist - das kann dann auch Dauerlicht der Leuchte sein. Oder wird %Q1.1 auch noch an mehreren Stellen was zugewiesen?

Was ist das für eine SPS?
Am einfachsten: aktiviere in der CPU das Taktmerkerbyte (S7-1200: standardmäßig MB0), dann ist Dein Blinken eine simple UND-Verknüpfung:
Code:
       +-----+
       |  &  |
%M5.1--|     |      %Q1.1
       |     |     +-----+
%M0.5--|     |-----|  =  |
       +-----+     +-----+
%M0.5 ist der Taktmerker "Clock_1Hz"

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also ich habe jetzt die Querverweisliste durchgesehen. Passt aber alles. Ich kann ja mal ein bisschen weiter ausholen:

Es geht um einen Wagen der an mehreren Positionen halten soll. Er soll immer dann weiterfahren, wenn der Taster "Freigabe" gedrückt wurde. Dementsprechend habe ich einen Merker "MFreigabeNötig", welche immer gesetzt wird, wenn der Wagen an einer Halteposition ankommt und erst zurück gesetzt wird, wenn der Taster gedrückt wird. Ich verwende den Merker also mehrmals im Programm, aber inhaltlich gesehen immer nur für die gleiche Aufgabe. Daher macht es meiner Meinung nach auch Sinn hier nur einen Merker zu verwenden, anstatt 10.

Also der Merker wird gesetzt und dann erst wieder zurückgesetzt wenn jemand die Taste drückt. Solange die Taste nicht gedrückt wird, wird auch an keiner Stelle im Programm der Merker zurückgesetzt. Somit kann ausgeschlossen werden, dass der Merker während eines Zyklus gesetzt und zurückgesetzt wird. (Da ich die Taste ja nicht anfasse)

@PN/DP Danke für den Hinweis mit dem Ausgang Q. Ich hatte vorher auch die einfache Variante wie du sie vorschlägst. Aber da hatte es halt nicht funktioniert. Dort hat es seltsamerweise ab und an ein Flackern der Leuchte gegeben.

Das ist vielleicht das Stichwort. Mit der vorherigen Variante hat es ja geklappt, dass die Leuchte zur richtigen Zeit aufgeleuchtet ist. Also der Merker gesetzt war.
Hier war dann aber das Problem, dass es zum Einen unregelmäßig war, oder zumindest so aus sah. Und zum Anderen war es nicht 1 Hz sondern sehr viel schneller und sehr schwaches Blinken für kurze Zeit, dann garnichts und dann wieder usw....
 
Zuletzt bearbeitet:
Poste doch gerne einfach mal die Querverweisliste, so kann man leider nur im dunkeln raten. Ließt du den Merker an mehreren Stellen und schreibst ihn nur an einer (das wäre gut und dann ist die Verwendung von nur einem Signal auch in Ordnung) oder schreibst du den Merker auch an mehreren Stellen (dann wäre es sinnvoll, den Merker eben nicht x-mal zu "recyclen", sondern eigenen Signale dafür zu verwenden).
 
Hier die Querverweisliste:

Unbenannt.jpg

Der Merker wird mehrmals gesetzt und zurückgesetzt. Also Position 1 -> setzen -> Taste drücken -> zurücksetzen -> Position 2 -> setzen -> Taste drücken -> zurücksetzen ....

Eine Ausnahme: Bei dem ersten Verweis in der Liste: Beim FB Antrieb gibt es in NW3 einen SR Flipflop. Hier wird der Merker gesetzt wenn jemand die Stop-Taste gedrückt hat und zurückgesetzt wenn wieder die Taste Freigabe gedrückt wurde.
 
Der Effekt, das die LED Flackert, liest sich für mich so, als ob du dauernd zwischen den Schritten hin- und herspringst.
Probier doch mal die weiteren Schritte bzw. die Weiterschaltung temporär abzublocken.
 
Noch nicht kontrolliert, ob MB5, MW4, MW5, MD2, MD3, MD4 oder MD5 irgendwo geschrieben werden?

Und zum Anderen war es nicht 1 Hz sondern sehr viel schneller und sehr schwaches Blinken für kurze Zeit, dann gar nichts und dann wieder usw....

"Schwaches Blinken" bedeutet vermutlich, dass die Leuchte sehr viel kürzer ein- als ausgeschaltet ist?

Wenn Du Dich nicht von dem BlinkBaustein trennen willst:
versorg den EN konstant mit 'true' und verknüpf den Ausgang des Bausteins über UND mit dem M5.1 und steuer damit die Leuchte an.

 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Dein FB 6 wird direkt nach FB12 aufgerufen? Arbeitest du mit indirekten Zugriffen auf Merkerbereiche?

Arbeitest du immer mit einer direkten Zuweisung in deinem Programm auf den Merker und liest den nur an einer Stelle? Das kann dann auch nicht funktionieren, weil du immer die Informationen aus den vorherigen Zuweisungen überschreibst, egal ob mit Eins oder Null. So wäre dann nur der letzte Schreibzugriff vor dem lesen auf den Merker relevant. Wenn du keine mehrfachen Merker verwenden möchtest, kannst du auch überlegen die Schreibzugriffe zusammenzufassen, sodass der Merker nur an einer Stelle geschrieben wird (also z.B. in Station 1 oder Station 2 etc...). Damit sollte so ein undefiniertes Verhalten des Merkers, abhänging von der Stelle im Programm an der man grade schaut, auch verhindert werden.
 
Zuletzt bearbeitet:
Ok jetzt funktioniert es.

Zum Einen habe ich wieder die einfache Variante mit einfachem UND-Baustein und dem Taktmerker für 1Hz und zum anderen hat @Heinileini den richtigen Hinweis gegeben:

Der Taktmerker 1 Hz liegt im Clock_Byte MB20 und ich hatte noch einen, längst vergessenen und auch nicht mehr benötigten, MW20 woanders in Verwendung.


Vielen Dank euch allen. Es waren sehr nützliche Hinweise dabei, die mir auch im Allgemeinen mehr Verständnis über die Funktionsweise der SPS verschafft haben.
 
Anhang anzeigen 49538

Als Tipp, da das mit den bisherigen Querverweisen nicht ganz so einfach war und die Lösung ja nun eigentlich nicht für uns plausibel ist (MW20 hat mix M5.1 nix zu tun, wohl aber mit einer vorherigen Lösung die wir hier nicht sehen können)

Wenn Du im TIA-Portal in der linken Spalte z.B. auf Programmbausteine einen Rechtsklick ausführst, dann Belegungsplan öffnest, findest Du solch eine Tabelle vor.

Einzelne Punkte mitten drin: Direkte Zuweisungen mittels E5.5 oder M5.6 etc.
Linien über ein, zwei oder mehr Bytes sind Überlappungen die mehr als nur ein Bit umfassen.
Wenn man diese hovert, bekommt man auch den Tag der Variable angezeigt.
Wählt man diese aus und öffnet in der unteren Leiste Info->Querverweise, dann werden die Vorkommen alle angezeigt.

Meistens findet man hierdurch die Fehler bei doppelten Zuweisungen einfacher.
 
Zurück
Oben