TIA Wenn ein PEW als Eingang an einem FC nicht erreichbar ist, wird FC nicht bearbeitet

ducati schrieb:
Wieso?
angenommen der Istwert ist weg, aber das Stellsignal wird noch versorgt: dann bleibt das Stellsignal da stehen wo es war, der Istwert bleibt eingefroren, z.B. die Visu zeigt den "alten" Istwert weiterhin an, und eine Handbedienung zum Zufahren des Stellgliedes ist nicht möglich...

Also ich kann den Vorteil in diesem konkreten Fall nicht sehen... ;)
Zum Vergrößern anklicken....
Na wenn das PEW eingefroren wird, dann hast du recht. Komisch, wenn ich micht recht entsinne, stand bei mir da immer eine "0" im PEW. Was dann z.Bsp. eine Druckregelung macht, wenn sie weiterhin aktiv bleibt, muss ich sicherlich nicht erklären. In den meisten Fällen ist es ohnehin ein GAU wenn plötzlich ein Slave bzw. irgendwelche Signale ausfallen.

Ich frage mich, was ihr tut um trotzdem eure Anlagen weiter laufen zu lassen? Es ist doch meistens nahezu unmöglich, alle Auswirkungen zu überblicken? Ok, bei manchen "unkritischen" Anlagen mache ich das auch. Dann stehen halt ein paar Fehlermeldungen an und ein Rührwerk einer Güllegrube läuft nicht. So etwas ist kein Problem. In der Regel sind heutige Anlagen jedoch etwas komplexer. Entweder man schaltet in solch einem Fehlerfall komplett ab oder man macht sich eine sehr aufwendige Sisyphusarbeit. Oder wie macht ihr das?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Onkel Dagobert schrieb:
Na wenn das PEW eingefroren wird, dann hast du recht. Komisch, wenn ich micht recht entsinne, stand bei mir da immer eine "0" im PEW. Was dann z.Bsp. eine Druckregelung macht, wenn sie weiterhin aktiv bleibt, muss ich sicherlich nicht erklären. In den meisten Fällen ist es ohnehin ein GAU wenn plötzlich ein Slave bzw. irgendwelche Signale ausfallen.

Ich frage mich, was ihr tut um trotzdem eure Anlagen weiter laufen zu lassen? Es ist doch meistens nahezu unmöglich, alle Auswirkungen zu überblicken? Ok, bei manchen "unkritischen" Anlagen mache ich das auch. Dann stehen halt ein paar Fehlermeldungen an und ein Rührwerk einer Güllegrube läuft nicht. So etwas ist kein Problem. In der Regel sind heutige Anlagen jedoch etwas komplexer. Entweder man schaltet in solch einem Fehlerfall komplett ab oder man macht sich eine sehr aufwendige Sisyphusarbeit. Oder wie macht ihr das?
Zum Vergrößern anklicken....

Also bei diesem PEW Problem der 1500er ist es so, wenn das PEW nicht erreichbar ist, wird der FB nicht mehr bearbeitet, und alle Werte im IDB bzw. wo auch immer der FB Daten hinschreibt bleiben so, wie sie vorher waren. Weiterhin wird jegliche Reaktion auf den PEW Ausfall, welcher in diesem FB eigentlich projektiert ist, nicht bearbeitet.

Generell kann man in seiner Software nie auf alle Anlagenstörungen vorbereitet sein. Wir sind es aber bei den Analogwerten in Bezug auf Drahtbruch und auch auf eine "nicht Erreichbarkeit" des PEW wodurch auch immer dieser ausgelöst wird. Damit wird dann wie in Deinem Beispiel der Regler gestoppt und das Ausgangssignal z.B. auf 0 gesetzt.

Bei den Tests zu dieser "nicht Erreichbarkeit" von PEWs ist uns dieser Bug hier aufgefallen.

Gruß.
 
Onkel Dagobert schrieb:
Na wenn das PEW eingefroren wird, dann hast du recht. Komisch, wenn ich micht recht entsinne, stand bei mir da immer eine "0" im PEW. Was dann z.Bsp. eine Druckregelung macht, wenn sie weiterhin aktiv bleibt, muss ich sicherlich nicht erklären. In den meisten Fällen ist es ohnehin ein GAU wenn plötzlich ein Slave bzw. irgendwelche Signale ausfallen.

Ich frage mich, was ihr tut um trotzdem eure Anlagen weiter laufen zu lassen? Es ist doch meistens nahezu unmöglich, alle Auswirkungen zu überblicken? Ok, bei manchen "unkritischen" Anlagen mache ich das auch. Dann stehen halt ein paar Fehlermeldungen an und ein Rührwerk einer Güllegrube läuft nicht. So etwas ist kein Problem. In der Regel sind heutige Anlagen jedoch etwas komplexer. Entweder man schaltet in solch einem Fehlerfall komplett ab oder man macht sich eine sehr aufwendige Sisyphusarbeit. Oder wie macht ihr das?
Zum Vergrößern anklicken....

Du kannst aber in deinem Programm auf eine "0" reagieren. Wenn der Baustein nicht bearbeitet wird ist das ja irgendwie nicht möglich. Was passiert eigentlich mit z.B. Ausgängen. Werden die bei Nichtbearbeitung des Bausteins auf FALSE gesetzt oder bleiben die wie sie sind ?

Wenn ich Analogwerte außerhalb des erwarteten Bereiches habe gib es eine Fehlermeldung und die Anlage wird in diesem Bereich gestoppt.
 
Lipperlandstern schrieb:
Was passiert eigentlich mit z.B. Ausgängen. Werden die bei Nichtbearbeitung des Bausteins auf FALSE gesetzt oder bleiben die wie sie sind ?
Zum Vergrößern anklicken....
Also bei FBs bleiben die Ausgänge wie sie sind, da es ja Daten im IDB sind.
Bei FCs ist es ne gute Frage, denke die sind undefiniert/zufällig. Das müsste man mal testen, ich denke die Zuweisung des am Ausgang verschalteten Signals wird hoffenlich aber nicht ausgeführt, wobei diese dann aber u.U. undefiniert sind, wenn es Temp-Variablen sind...

Langsam wird mir auch ganz schlecht, wenn ich dran denke, welche möglichen ähnlichen Bugs noch im TIA stecken :sb5:

Gruß.F
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Lipperlandstern schrieb:
Was passiert eigentlich mit z.B. Ausgängen. Werden die bei Nichtbearbeitung des Bausteins auf FALSE gesetzt oder bleiben die wie sie sind ?
Zum Vergrößern anklicken....
Das Verhalten "müsste" "logischerweise" genauso sein, wie wenn an dem Baustein in FUP/KOP der EN false ist oder in AWL/SCL der Aufruf übersprungen wird:
wenn ein Baustein nicht aufgerufen wird, dann werden die Ausgangswerte nicht in die angeschlossenen Aktualvariablen kopiert - diese bleiben also wie sie sind. Das ist identisch bei FB und FC (hat also nichts mit Übergabe über IDB oder TEMP zu tun).

Nachtrag:
Wenn bei einem FB eine Variable nicht direkt beim CALL angeschlossen ist, sondern später ala "L #Instanz_1.Output" versorgt wird, dann liefert das den Ausgangswert, der zuletzt in der Instanz zugewiesen wurde - bleibt also ebenfalls wie er ist. (Es sei denn, der Output der Instanz wird woanders von außen beschrieben).

Harald
 
Zuletzt bearbeitet:
@Harald

folgendes nicht ganz unübliches Konstrukt:

Du schreibst nen FC mit nen Eingang WORD und nem Ausgang REAL

diesen FC ruftst Du auf und verschaltest am Eingang nen PEW128 und am Ausgang ne Temp.-Variable z.B. Messwert...
Weil Du das Ergebnis des FC noch irgendwie weiter verarbeitest.

wenn Du danach L Messwert aufrufst, ist Messwert undefiniert bzw. hat noch irgendeinen Wert von einer vorherigen Verwendung...

Also z.B. hat Messwert im NW 1 den Wert der Aussentemperatur, NW 2 sollte eigentlich die Raumtemperatur liefern, aber da FC im NW2 nicht bearbeitet wurde, hat Messwert im NW2 immer noch den Wert der Aussentemperatur...

Ganz ganz interessant ;)

Gruß.
 
Wenn man sich das so überlegt, fahren Achsen gegen die Wand,
Druckbehälter bekommen ordentlich Druck, Windräder werden mal
richtig schnell auf der einen Seite wird geheizt bis die Flüssigkeit
sich in Nebel aufgelöst hat oder gekühlt bis Meter dickes Eis
erzeugt wird.

Schlimm wird es wenn in einen Atom Kraftwerk die Brennstäbe
sich langsam nach Japan durchfressen.

Automatisieren Sie mit TIA, werfen Sie alles über Bord was Sie
mal gelernt haben und lassen sich überraschen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@RN wir haben für uns schon festgelegt, 1200/1500 für wichtige Anlagen bis auf weiteres nicht einzusetzen. Davon haben wir auch den Siemens Vertrieb informiert. Weiterhin haben unter der Hand die Siemens eigenen Projektleute uns auch davon abgeraten, 1200/1500 für wichtige Anlagen einzusetzen. Angeblich sind noch weitere gröbere Bugs drin. Weiterhin werde ich jedem Kunden der mich fragt, von der 1200/1500 abraten.
Was der Vetrieb bzw. Einkauf macht, darauf hab ich leider direkt keinen Einfluss. D.h. wenn ich 1200/1500 einsetzen MUSS, werde ich jeweils immer schriftlich meine Bedenken äussern.
Gruß.
 
rostiger Nagel schrieb:
Wenn man sich das so überlegt, fahren Achsen gegen die Wand,
Druckbehälter bekommen ordentlich Druck, Windräder werden mal
richtig schnell auf der einen Seite wird geheizt bis die Flüssigkeit
sich in Nebel aufgelöst hat oder gekühlt bis Meter dickes Eis
erzeugt wird.

Schlimm wird es wenn in einen Atom Kraftwerk die Brennstäbe
sich langsam nach Japan durchfressen.

Automatisieren Sie mit TIA, werfen Sie alles über Bord was Sie
mal gelernt haben und lassen sich überraschen.
Zum Vergrößern anklicken....


Ach Helmut..... Das Stichwort heisst Redundanz. Du darfst dich halt nicht nur auf einen Analogwert verlassen sondern noch zusätzlich ein paar Sensoren zur Absicherung einbauen. Gibt es bestimmt alles beim S zu kaufen :ROFLMAO: ...
 
ducati schrieb:
diesen FC ruftst Du auf und verschaltest am Eingang nen PEW128 und am Ausgang ne Temp.-Variable z.B. Messwert...
Weil Du das Ergebnis des FC noch irgendwie weiter verarbeitest.

wenn Du danach L Messwert aufrufst, ist Messwert undefiniert bzw. hat noch irgendeinen Wert von einer vorherigen Verwendung...

Also z.B. hat Messwert im NW 1 den Wert der Aussentemperatur, NW 2 sollte eigentlich die Raumtemperatur liefern, aber da FC im NW2 nicht bearbeitet wurde, hat Messwert im NW2 immer noch den Wert der Aussentemperatur...
Zum Vergrößern anklicken....

Das Beispiel mit den dann womöglich uninitialisierten Temp-Variablen sollte man Siemens mal dick und fett vorlegen. Das zeigt nämlich genau, dass das Verhalten was die da eingebaut haben unmöglich toleriert werden kann.

Vor allem wenn es mit so einem FAQ mehr oder weniger nebenbei als unwichtig abgetan wird, nachdem die Steuerung jetzt 4 Jahre auf dem Markt ist.
Wenn das Verhalten wirklich so geplant war aber dann in keinem Handbuch dokumentiert wird, dann würde ich mich noch auf ganz andere Effekte einstellen die anscheinend ebenfalls nicht einer Erwähnung im Handbuch würdig sind.
 
@Thomas, ich werd den SR nächste Woche noch mal aus der Versenkung holen und Siemens noch mit einigen neuen Erkenntnissen füttern
@Harald, falls ich nächste Woche etwas Zeit habe, schau ich mir das mal in FUP näher an.

Ansonsten hat ich jetzt auch mal im Siemens-Forum nen Thread erstellt. Wer Lust und Zeit hat, kann dort auch noch seinen Senf zu dem Thema abgeben

https://support.industry.siemens.co...endung-von-pew-paw/156851/?page=0&pageSize=10


Gruß, schönes Wochenende.F
 
Hatte jetzt nochmal Kontakt mit dem Siemens Support,

konkret zu dem Thema
- Migrationsfähigkeit
- undefinierte/zufällige Temp. Variablen
- Verhalten von F-Bausteinen
- Verhalten bei verschiedenen FW-Versionen

da kam dann nurnoch das hier zurück:

Wie mein Kollege bereits mitteilte, ist diese Funktionalität als Standard zu betrachten. Allerdings wird die Funktion explizit noch einmal neu beschrieben werden im Handbuch und in der Onlinehilfe. Diese Änderung ist geplant für das nächste Servicepack.
Zum Vergrößern anklicken....

Was soll man sagen....
 
Ja, schon peinlich irgendwie, da muss es wohl irgendein gröberes Problem bei der 1200/1500 geben dass man das Verhalten nicht so einfach ändern kann.

Doku alleine ist zu wenig, da muss mindestens ne Compilerwarnung per PEW-Übergabe sein.

Das PEW-Problem wird auch nicht das einzigesein dass zum Abbruch führt. Womöglich stehen in der V14SP1-Doku (natùrlich gut versteckt) dann eine ganze Liste von Dingen die das auslösen können.
 
Siemens Zitat ( von Ducati am 31.10.2016 in #134 eingestellt )
Wie mein Kollege bereits mitteilte, ist diese Funktionalität als Standard zu betrachten. Allerdings wird die Funktion explizit noch einmal neu beschrieben werden im Handbuch und in der Onlinehilfe. Diese Änderung ist geplant für das nächste Servicepack.
Zum Vergrößern anklicken....

Mein Zitat mit der Vermutung, wie das ganze enden wird ( vom 6.10.2016 in #26 )
Wäre interessant, was Siemens dir dazu antwortet. Dieses Verhalten
habe ich bis jetzt noch in keiner Dokumentation gelesen ( wird vielleicht jetzt nachgeplegt :smile: )
Zum Vergrößern anklicken....

Anscheinend ist der einfachste Weg der beste ( allerdings nicht für uns )
 
Zuletzt bearbeitet:

Similar threads

T
Step 7 FC wird nicht bearbeitet
Antworten
1
Aufrufe
785
Tonyodi
T
N
Step 7 FC wird nicht bearbeitet (zu viele Interne Variable ?)
Antworten
11
Aufrufe
3K
vollmi
vollmi
F
Step 7 Problem mit Hex Eingang eines FC
Antworten
17
Aufrufe
2K
flummy
F
Zurück
Oben