TIA Status Baustein EN / ENO unterbrochen

schwimmer

Level-3
Beiträge
1.669
Reaktionspunkte
582
Zuviel Werbung?
-> Hier kostenlos registrieren
S7-400 [CPU 414-3 PN/DP] / TIA V19Upd3

Hallo Forum,
habe hier ein Verhalten was ich nicht so ganz nachvollziehen kann.
Zu einem bestehenden Programm wurde unter anderem einige FBs hinzugefügt und dabei stelle ich ein Verhalten fest, welches ich nicht nachvollziehen kann.
Bei einigen der FBs wird der Status vom Eingang En auch auf den Ausgang ENO "durchgeschleift", bei anderen nicht. Es werden aber alle Bausteine bearbeitet und das Programm wird auch richtig ausgeführt.
Wie kann ich es denn überhaupt beeinflussen ob der Status von EN => ENO durchgeschleift wird?

Danke für eure Tipps
 
Wie kann ich es denn überhaupt beeinflussen ob der Status von EN => ENO durchgeschleift wird?
KOP/FUP:
RET-Befehl

SCL:
ENO := TRUE; (oder False, je nach Bedarf)

Bei AWL weiß ich es Grade nicht auswendig.
Ist, je nach programmierstil, Recht üblich die erfolgreiche/fehlerhafte Ausführung über den ENO zu melden.
Ist ja (soweit ich weiß) der eigentliche Zweck von dem Ding ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Werde ich nächste Woche, wenn ich wieder an der Anlage bin mal ausprobieren.
Den RET-Befehl habe ich bisher nicht benutzt, deshalb bleibt eigentlich meine Frage warum bei manchen der selbst erstellten Bausteine ENO high ist und bei anderen nicht.
 
Da gibt es bei den Einstellungen glaube ich einen Punkt um den ENO automatisch high zu setzen. Schau einmal in den Bausteineigenschaften nach.
Mfg Hannes
 
Der ENO-Ausgang ist der Zustand des BIE-Bit aus dem CPU-Statusword. Das BIE-Bit kann man beeinflussen, um darüber einen bestimmten Zustand des ENO-Ausgangs zu erreichen. In AWL ist das die Anweisung SAVE, die den Zustand des VKE in das BIE-Bit kopiert. Weil das Beeinflussen des ENO-Ausgangs nur Sinn macht kurz vor dem Verlassen des Bausteins, wird der ENO-Ausgang in FUP/KOP mit der Anweisung RET gesteuert.

Bei einigen der FBs wird der Status vom Eingang En auch auf den Ausgang ENO "durchgeschleift"
Das kann nicht sein, da hast du wohl was falsch beobachtet oder die Beobachtung falsch interpretiert.
Wenn bei einem Baustein-Aufruf in FUP/KOP der EN = FALSE ist, dann wird der Baustein gar nicht aufgerufen und kann daher das FALSE gar nicht an seinen ENO-Ausgang weitergeben. Von den FUP/KOP/SCL-Compilern wird aber um den Bausteinaufuf (CALL) extra das BIE-Bit von vor dem nicht erfolgten Aufruf bzw. von nach dem Aufruf ins VKE geladen, wodurch der ENO-Ausgang scheinbar auch das FALSE weitergibt. Dieses Vorgehen ist notwendig, damit am ENO-Ausgang verknüpfte Anweisungen das FALSE vom EN-Eingang mitbekommen, um z.B. das VKE von vor dem Baustein an nach den Baustein weiterzugeben für nachfolgende Verknüpfungen. Tatsächlich kann ein Baustein nur EN = TRUE weitergeben oder das BIE für den ENO auf FALSE oder TRUE beeinflussen, wenn der Baustein auch ausgeführt wird.
 
Da gibt es bei den Einstellungen glaube ich einen Punkt um den ENO automatisch high zu setzen. Schau einmal in den Bausteineigenschaften nach.
Das ist so nicht ganz korrekt. Es gibt eine Einstellung "ENO automatisch setzen", die dafür sorgt, dass Fehler in diversen Anweisungen den ENO-Ausgang auf False setzen, wenn die Einstellung aktiviert ist. Wenn die Einstellung deaktiviert ist (Standard), dann wird der ENO gar nicht beeinflusst - er bleibt also einfach auf True.
 
Das kann nicht sein, da hast du wohl was falsch beobachtet oder die Beobachtung falsch interpretiert.
Ich habe mich da vielleicht falsch ausgedrückt.
Im OB1 werden in einem Netzwerk 2 FBs hintereinander aufgerufen, ohne irgendwelche Bedingungen.
1729675529298.png
Der Baustein 2 wird nun nicht mehr bearbeitet, weil ENO von Baustein 1 false ist. Dies ist aber nicht bei allen FBs der Fall und ich habe das ENO noch nie bearbeitet oder irgendwie beeinflusst. Deshalb wundert es mich, dass es bei diesem Projekt mal so und mal so ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dann ist entweder im FB4 das "ENO automatisch setzen" aktiviert (und eine Anweisung signalisiert einen Fehler) oder der FB4 setzt den ENO explizit auf False. Oder die CPU hat einen Firmware-Fehler?
In welcher Programmierspache ist der FB4 programmiert?
 
Dann ist entweder im FB4 das "ENO automatisch setzen" aktiviert (und eine Anweisung signalisiert einen Fehler) oder der FB4 setzt den ENO explizit auf False.
In welcher Programmierspache ist der FB4 programmiert?
Im Baustein verwende ich KOP und ENO kann ich nirgend in den Bausteineigenschaften setzen oder beeinflussen
 
Bei S7-300/400 gibt es das "ENO automatisch setzen" nur bei SCL-Bausteinen.
Bei KOP muss explizit eine -(RET)-Anweisung vorhanden sein. Oder eine AWL-Anweisung SAVE, falls das bei S7-300/400 in TIA geht.
Oder bei igendeiner FUP-Anweisung ist explizit "ENO generieren" aktiviert.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei KOP muss explizit eine -(RET)-Anweisung vorhanden sein.
Mich wundert es nur, dass es so unterschiedlich ist.
Obwohl ich alle FBs mit der gleichen Vorgehensweise erstellt und nirgends die RET-Anweisung benutzt habe, scheint es nur bei einigen das ENO False zu sein. Ich werde es nächste Woche, wenn ich wieder an die Anlage komme testen.
 
Ja, das ist ja so nen Ding. Der ENO wird ja oft in FUP "mißbraucht", um mehrere Bausteine in einem Netzwerk aufrufen zu können.
Wenn dann aus irgendeinem Baustein mal ENO=false rauskommt, ist das Erwachen groß...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Oder bei igendeiner FUP-Anweisung ist explizit "ENO generieren" aktiviert.
Wie gesagt, ich habe diese Funktion noch nie verwendet und wie es scheint ist es bei der S7-400 unter TIA auch nicht möglich. Alles wo ENO dabeisteht ist nicht zu aktivieren.
Ja, das ist ja so nen Ding. Der ENO wird ja oft in FUP "mißbraucht", um mehrere Bausteine in einem Netzwerk aufrufen zu können.
Wenn dann aus irgendeinem Baustein mal ENO=false rauskommt, ist das Erwachen groß...
Genau deswegen ist es mir ja auch aufgefallen, mich wundert es halt warum sich die Bausteine so unterschiedlich verhalten. Diesen Fall hatte ich bisher noch nie. Anscheinend liegt es wohl doch an irgendeiner Besonderheit der S7-400
 
Anscheinend liegt es wohl doch an irgendeiner Besonderheit der S7-400
Nicht dass ich wüsste. Man müsste mal deinen speziellen Baustein genau analysieren, wo und warum das BIE-Bit gelöscht wird.
Vielleicht ist es auch ein Fehler in einer Firmware-Version? Oder fügt TIA das unerwartet irgendwie ein? Passiert das in einer realen CPU oder in PLCSIM?
 
Zurück
Oben