TIA V17 FUP InOut kann nicht auf Output Variable zugreifen

Glon

Level-2
Beiträge
264
Reaktionspunkte
77
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich habe einen FC in dem eine Variable als InOut deklariert ist.
Beim Aufruf des FCs in einem FB soll eine Variable vom Typ Output an diesen InOut übergeben werden.
In SCL geht das super und jetzt wollte ich ein Teil des Programms in FUP umsetzen und siehe da: Das ist verboten.
Kann man dieses Verhalten abschalten?

1669957279338.png

PS:
Verwendet wird in diesem Fall eine CPU 1215
 
Ja, es ist halt generell keine gute Idee, ne Outvariable innerhalb eines FC oder FB zu lesen...
Sei zufrieden, dass wenistens FUP meckert...
Evtl. ist die IEC Prüfung für SCL deaktiviert.

Das Verhalten abzustellen ist keine gute Idee. Da kann man sich jetzt einige Situationen überlegen, wo ziemlicher Quatsch passiert.

Also Lösung: weder in SCL noch in FUP noch in AWL, weder in FCs noch in FBs Outvariablen lesen...
 
Die Lösung dazu ist mir schon klar.
Das Problem ist immer wieder:
Kleinste Steuerung nehmen aber bitte Zykluszeiten unter 3ms.
Also spart man an allen Enden, wenig Variablen, wenig hin und her kopieren usw.
Und für mich ist ein Output auch nur eine Variable im Speicher die ich nur schreiben möchte wenn es Notwendig ist.

Ziel war es eigentlich eine Variable auf TRUE zu setzen falls die Prüfung im FC dies für notwendig erachtet, falls nicht soll er die Variable einfach in Ruhe lassen. Falls sie nämlich schon TRUE ist dann soll das bitte auch so bleiben. Das könnte ich auch wieder anders lösen... elegant verwenden lässt sich das dann irgendwann im FUP nicht mehr.

Am Ende ist meine Lösung die gleiche wie von @PN/DP, aber es lässt sich nicht so schön Verwenden und macht das Programm größer als es müsste.

Trotzdem vielen Dank für eueren Input!
 
naja, vielleicht gehts, wenn Du die Variable im FB als INOUT deklarierst... Aber keine Ahnung, musst halt aufpassen, dass kein Quatsch passiert. z.B. Wenn Du die Variable vom HMI liest, ist halt undefiniert, wann das passiert und ob die grad schon gesetzt wurde ode noch nicht...

Ansonsten glaube ich jetzt nicht, dass die Verwendung einer zusätzlichen TempVariable an der Stelle die Zykluszeit erhöht. Vielleicht wird die sogar kürzer, weil schreiben auf Temp schneller als schreiben auf DB-Variable sein könnte 🤷‍♂️
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, es ist halt generell keine gute Idee, ne Outvariable innerhalb eines FC oder FB zu lesen...
Sei zufrieden, dass wenistens FUP meckert...
In einem FB ist das doch zu 100% definiert, eine Out-Variable zu lesen. Hier jetzt überall Zwischenvariablen verwenden zu müssen, nur damit der Compiler schweigt ist auch nicht zielführend, zwecks Wartbarkeit und Speicherverbrauch. Das ist ja auch bei der Verwendung von TON-Timern beim Ausgang Q der Fall. Bei bool-Variablen reicht es aber einfach eine logische Und/Oder Verknüpfung davor zu setzen, denn da scheint es das TIA-Portal nicht zu stören, wenn man da eine OUT-Variable liest. Aber das ist typisch TIA-Portal, da wird irgendein sinnloser Mist reinprogrammiert, und dann noch nicht einmal durchgängig.
 
Und für mich ist ein Output auch nur eine Variable im Speicher die ich nur schreiben möchte wenn es Notwendig ist.
FC-Outputs sind aber keine Variablen im Speicher, sondern liegen im Stack und müssen auf jeden Fall eine Zuweisung erhalten.

Ziel war es eigentlich eine Variable auf TRUE zu setzen falls die Prüfung im FC dies für notwendig erachtet, falls nicht soll er die Variable einfach in Ruhe lassen. Falls sie nämlich schon TRUE ist dann soll das bitte auch so bleiben.
Wie aufwändig ist es, das Zuweisen von TRUE an eine Variable zu verhindern, die eh' schon TRUE ist? Und wie schädlich ist es, die eigentlich unnötige Zuweisung trotzdem zu machen?

Im übrigen sollte sowieso im FC generell nur eine einzige Zuweisung an einen Output stattfinden, für den Fall daß der Output-Parameter per Referenz übergeben wird.

Am Ende ist meine Lösung die gleiche wie von @PN/DP, aber es lässt sich nicht so schön Verwenden und macht das Programm größer als es müsste.
Die eine Kopieraktion am Ende des Bausteins macht den Programmcode tatsächlich unerträglich größer und viel langsamer ;)

Harald
 
In einem FB ist das doch zu 100% definiert, eine Out-Variable zu lesen.
Ja, aber der von mir oben skizzierte Fall mit dem HMI Zugriff oder Unterbrechung durch Weckalarm führt zu Inkonsistenzen... Im FC ists auf jeden Fall nen großes Problem, weshalb man es sich auch für FBs nicht angewöhnen sollte...

Aussdem mehrfach auf den Out rumzuschmieren ist sowieso unschön, wenn da mal jemand anders nachvollziehen will, warum der jetzt grad true oder false ist. Da hilft dann aber auch nicht die eine Tempvariable sondern mehrere für jede Verwendung...
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, aber der von mir oben skizzierte Fall mit dem HMI Zugriff oder Unterbrechung durch Weckalarm führt zu Inkonsistenzen... Im FC ists auf jeden Fall nen großes Problem, weshalb man es sich auch für FBs nicht angewöhnen sollte...

Aussdem mehrfach auf den Out rumzuschmieren ist sowieso unschön, wenn da mal jemand anders nachvollziehen will, warum der jetzt grad true oder false ist. Da hilft dann aber auch nicht die eine Tempvariable sondern mehrere für jede Verwendung...
Bei der Verwendung als InOut stimme ich dir zu. Aber den Fehler erzeugt TIA-Portal auch bei nur lesendem Zugriff von Out-Variablen eines FBs. Wie gesagt, in SCL scheint das nicht geprüft zu werden, und wenn man eine boolsche Verknüpfung davorsetzt, dann ist es dem TIA auch egal.

Als ob da an einen Praktikanten ein Auftrag ausgegeben wurde: Mach bitte mal ein paar Warnungen, damit das so aussieht als machen wir hier was Professionelles. Ergebnis: Irgendwelche Warnungen werden erzeugt. Auftrag abgeschlossen. Prüft das bei Siemens überhaupt jemand? Warum ist das nur in FUP/KOP eine Warnung und nicht in SCL? Warum ist das bei einem FB überhaupt eine Warnung? Warum nicht wenn ich das bei einer boolschen Verknüpfung mache? Der Mist ist seit etlichen Versionen im TIA-Portal enthalten, und keinem bei Siemens fällt auf, dass hier völliger Müll programmiert wurde.
 
Für SCL wäre mal zu prüfen, ob da die IEC Prüfung aktiv ist.
Ansonsten hast Du natürlich recht. Ich bin da der letzte, der das TIA irgendwie verteidigen würde ;) Nur der Kollege TE hätte gerne weniger/garkeine Warnungen. Ich hätte gerne mehr Warnungen ;) Weil da zu Recht gewarnt wird.
Ich bin der Meinung, zu dem Thema gabs schonmal ne Diskussion, kriegs aber nichtmehr zusammen.
Zu den Warnungen/Fehlern hat sich auch über die TIA Versionen einiges geändert, weshalb ne Hochrüstung von TIA alt nach neu manchmal an der Stelle Probleme macht...
 
Zuletzt bearbeitet:
Was beim Lesen oder Schreiben einer Outvariablen passiert ist halt verschieden. Je nachdem ob FC oder FB, optimiert/nichtoptimiert, elementarer Datentyp ja/nein, dieser komische Haken remanent im IDB, 300 oder 1500er, TIA alt/neu...
Da das im Tagesgeschäft niemand überblicken kann: Outvariablen innerhalb des FC/FB NIEMALS lesen und nur EINMAL beschreiben...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
FC-Outputs sind aber keine Variablen im Speicher, sondern liegen im Stack und müssen auf jeden Fall eine Zuweisung erhalten.
Ich will ja den Output vom FB Manipulieren und nicht vom FC.

Vielleich sollte ich doch nochmal konkreter werden.
Diese Meldung von TIA Portal in FUP verhindert das Compilieren! Es ist also keine Warnung sondern ein Fehler... und das dies in FUP anders behandelt wird als in SCL und das noch im selben FB finde ich doch äußerst inkonsistent.

Was möchte ich denn eigentlich mit meinem merkwürdigen Konstrukt machen?
Ich entwickle, für die Siemens Maschinen die wir hier so bauen, ein neues Meldekonzept. Dieses soll so einfach wie möglich zu bedienen sein, da damit Entwickler jeglichen Wissensstands mit Arbeiten sollen. Das Anlegen einer Multiinstanz ist bei manchen schon "zu" schwierig. Die alten Maschinen wurden ja auch nur mit FC und ein paar DBs Programmiert. Zusätzlich darf dieses "neue" Zeug nicht langsamer als die alte Programmstruktur sein (Zykluszeit <=4ms -> deswegen leider kein Program_Alarm).

In der alten Software gibt es einen Merker(Schmiermerker), der bei definierten Alarmen die ganze Maschine abgeschaltet hat (Not-Aus usw).
Auf diesen wurde nur bedingt geschrieben und dieses Konzept wollte ich einfach nachbauen, damit sich die Kollegen heimisch fühlen ;-)

Vll. nochmal zum Thema HMI und Weckalarm:
Um beim HMI flackern zu verhindern, weil der Zugriff undefiniert erfolgt, schreibe ich die Variablen nur bei Änderung oder am Ende.

Weckalarme gibt es zum allergrößten Teil nicht. Wobei ich mir dort eine Fehlerhafte Abarbeitung nicht vorstellen kann, bzw. wird das im nächsten SPS Zyklus korrigiert.

Danke nochmals für eure Beiträge!
 
Ich will ja den Output vom FB Manipulieren und nicht vom FC.
Ach ja, das hatte ich missverstanden. Ich dachte Du willst einen Output in einem FC lesen.

Wie Thomas_v2.1 schon schrieb, dürfte das formal nicht angemeckert werden. Der SCL-Compiler läßt das ja auch klaglos durchgehen.
Meiner Meinung nach ist das ein Fehler im FUP/KOP-Compiler, aber anscheinend ein von Siemens schon mindestens seit TIA V13 so gewolltes Feature für "Dummies". Wende Dich an Siemens und bitte sie, daß sie diese Fehlermeldung abstellen. Viel Erfolg ... ;)

Vielleicht steht dazu auch was im Programmierleitfaden. Immerhin hilft die Fehlermeldung bei der Erzeugung von Code, dem es egal ist, ob er in einem FC oder FB verwendet wird. Man muß ja nicht alles ausnutzen, was in manchen speziellen Fällen vielleicht funktioniert (wie z.B. TEMP-Variablen ohne Initialisierung lesend verwenden), man kann sich auch merken, daß man Outputs generell nicht rücklesen soll und ist damit auf der sicheren Seite für den Fall, daß man mal mit SPS zu tun hat wo das Probleme macht.

Harald
 
Zurück
Oben