Frage zu Temp-Variablen...

Zuviel Werbung?
-> Hier kostenlos registrieren
Habe jetzt doch mal ne Grafik angehängt, damit ich keinen Blödsinn erzähle... ;-)

@Harald: Könnte ich deinen geposteten Aufrufcode auch auf meine Bedürfnisse umändern? Dass quasi die OUT-Parameter von FB1 als IN-Parameter von FB2 gelesen werden...




FB.jpg
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
@Harald: Könnte ich deinen geposteten Aufrufcode auch auf meine Bedürfnisse umändern?
Ich habe hier gerade kein TIA, doch das müßte etwa so aussehen:

Bei FB1 die Ausgänge unbeschaltet lassen.
Bei FB2 an den Eingängen die Ausgänge der FB1-Instanz angeben.
Code:
CALL "Alarme","FB2_DB"    //Aufruf des FB2
 druck_hoch      :="FB1_DB".druck_hoch
 druck_niedrig   :="FB1_DB".druck_niedrig
 druck_fehlerhaft:="Fehler"

Harald
 
Du kannst in deinem Fall ohne schlechten Gewissen Lokaldaten verwenden.
Würde ich sogar besser finden als auf den Instanzdatenbaustein so wie es PN/DP vorschlägt zuzugreifen.
Jedoch solltest du den Lokaldaten schon einen Namen im Bausteinheader zuweisen.
 
@Tigerente: Nun, eigentlich sollten im FB2 halt nur alle Alarme stehen - Aufrufe über einzelne Merker! Dachte das wäre so übersichtlicher...

@Harald: Ja, dies über die FB-Instanz zu lösen klappt & ist sehr elegant! ;)

Lieben Dank!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du kannst in deinem Fall ohne schlechten Gewissen Lokaldaten verwenden.
Würde ich sogar besser finden als auf den Instanzdatenbaustein so wie es PN/DP vorschlägt zuzugreifen.
Jedoch solltest du den Lokaldaten schon einen Namen im Bausteinheader zuweisen.

Einen Namen zuweisen bedeutet dann einfach unter TEMP im OB1 einen Namen zu deklarieren, oder?

Aber es ist doch eigentlich vor der Verwendung von TEMP-Variablen hier etwas gewarnt worden - bin jetzt etwas verwirrt!

Danke!
 
Eine der möglichen guten Varianten ist im Beitrag #23 von PN/DP zu finden.
Warum was mit Temp-Variablen herumbasteln wenn es anders besser geht?
Wenn ich ein Netzwerkkommentar lese "dieses Netzwerk muss nach Netzwerk xy kommen, weil sonst das Programm nicht mehr funktioniert" dann wäre ich schon sehr misstrauisch.
 
@borromeus:

... nun mich hatte einfach die Aussage von godi etwas irritiert!

Aber habe es jetzt so realisiert, wie von Harald vorgeschlagen...

Danke!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Aber es ist doch eigentlich vor der Verwendung von TEMP-Variablen hier etwas gewarnt worden - bin jetzt etwas verwirrt!

Wenn man weiss, was man tut, kann man TEMP schon verwenden. Man darf halt nur keine Fehler machen... Im nächsten Zyklus ist der Wert der Tempvariablen halt undefiniert, das ist das "Gefährliche". D.h. immer zuerst einen Wert zuweisen und dann verwenden.
Statische Variablen behalten im nächsten Zyklus den Wert des Vorigen, was den Vorteil hat, dass erstmal kein alzugroßer Quatsch drinstehen kann, und sind deshalb "sicherer".
Aber, wenn ich Temp-Variablen vor der Zuweisung abfrage, dann ist das ein Programmierfehler. Und bei Programmierfehlern funktioniert das Programm halt nicht, das ist so.

Fazit: Wenn Du nicht gezwungen wirst, Speicherplatz zu sparen, verwende statische Variablen und gut ist. So mach ich das.

Gruß.
 
Zuletzt bearbeitet:
Aber es ist doch eigentlich vor der Verwendung von TEMP-Variablen hier etwas gewarnt worden - bin jetzt etwas verwirrt!
Die Warnungen kannst Du vergessen, die kommen aus der Rubrik "Pferde kotzen sehen" und teilweise Unwissenheit. Du bist der Programmierer, es ist Dein Projekt und Du wirst die theoretisch möglichen Schweinereien natürlich nicht nutzen.

So wie bike schon sofort im Beitrag #2 sagte:
Wenn du die Variablen zuerst zuweist und dann [...] danach abfragst, dann funktioniert es.

Harald
 
Die Warnungen kannst Du vergessen, die kommen aus der Rubrik "Pferde kotzen sehen" und teilweise Unwissenheit.

Naja, wenn man die Beiträge hier im Forum zum Thema TEMP verfolgt, sind da schon Einige auf die Nase gefallen...

Und manchmal (immer?) gehts bei der Inbetriebnahme auch chaoitsch zu, und da schreibt man auch mal schnell noch ne Codezeile dazu, ohne dran zu denken, dass die Variable jetzt Temp war...

Das Dumme dran ist, dass man den Fehler nicht immer gleich merkt, da "undefiniert" auch bedeuten kann, dass abundzu das Richtige drinsteht...

Gruß.
 
Ja, und drum sollte man grundsätzlich alles so "industrietauglich" wie möglich programmieren. Speicherplatz und Geschwindigkeit ist im Regelfall nämlich egal.
 
Du bist der Programmierer, es ist Dein Projekt und Du wirst die theoretisch möglichen Schweinereien natürlich nicht nutzen.

Jep genau deshalb halte ich nichts von dem Zugriff auf den Instanzdatenbaustein weil das eben die "Lokalen-Variablen" des FB's sind. Siehe Datenkapselung.
Des weiteren gibt es noch den Begriff der Kopplung. In diesem Fall wäre dies gleich mal eine Bereichskopplung. Naja nicht so gut.
Ob jetzt Temp oder Statische Variablen zum Datenaustausch verwendet werden ist natürlich Ansichtssache des Programmierers.
In diesem Fall würden eben Temp-Variablen reichen, da die Überwachung bzw das Einlesen des Sensors sowieso vor dem Auswerten des Alarmes geschehen sollte. Sonst wird beim Einschalten höchstwahrscheinlich gleich ein Fehler ausgegeben. Solche Anlagen habe ich auch schon gesehen wo man vorher alle Falsch-Meldungen Quittieren muss bis die Anlage gestartet werden kann.

Aber in diesem Forum hat es schon sehr viele Diskussionen über den Zugriff auf Instanzdatenbausteine gegeben.
Es soll jeder Programmierer selbst (bzw die Firma oder Kunde) entscheiden wie er seine Projekte umsetzt.

godi
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, und drum sollte man grundsätzlich alles so "industrietauglich" wie möglich programmieren. Speicherplatz und Geschwindigkeit ist im Regelfall nämlich egal.

Zu aller erst mal sollte man beim programmieren wissen was man warum wo tut, dann wirds schon fast von selbst industrietauglich,
und wenn man Temp-Variablen als das verwendet was Sie sind, und auch so wie sie gedacht sind, wird man damit NIE ein problem haben.

Mfg
Manuel
 
Jep genau deshalb halte ich nichts von dem Zugriff auf den Instanzdatenbaustein weil das eben die "Lokalen-Variablen" des FB's sind. Siehe Datenkapselung.
Des weiteren gibt es noch den Begriff der Kopplung. In diesem Fall wäre dies gleich mal eine Bereichskopplung. Naja nicht so gut.
Ob jetzt Temp oder Statische Variablen zum Datenaustausch verwendet werden ist natürlich Ansichtssache des Programmierers.

Tja, und auf Grund dieser immer wiederkehrenden Grundsatzdiskussion bin ich froh, die meisten Anlagen mit CFC programmieren zu können. Weil dort ist das alles kein Thema, da es automatisch im Hintergrund passiert...

Man programmiert einfach seine Bausteine und verschaltet sie im CFC grafisch, ohne sich Gedanken über "Schmiermerker" etc. machen zu müssen...

Gruß.
 
Jep genau deshalb halte ich nichts von dem Zugriff auf den Instanzdatenbaustein weil das eben die "Lokalen-Variablen" des FB's sind.
godi

Sorry, wenn ich da jetzt nochmals nachhaken muss...

Bedeutet das nun, dass der Zugriff auf den Instanzdatenbaustein nichts anderes ist, als würde ich gleich die TEMP-Variablen verwenden?

Die TEMP-Variablen sind doch die Lokalvariablen!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Jep genau deshalb halte ich nichts von dem Zugriff auf den Instanzdatenbaustein weil das eben die "Lokalen-Variablen" des FB's sind.
Das Zugreifen auf Ausgangsvariablen einer FB-Instanz verstehe ich nicht als Zugriff auf gekapselte "Lokale Variablen", schließlich sind die ja in der öffentlichen Übergabeschnittstelle (*).
Gerade bei mehrfach-Instanzen von FB finde ich das direkte Verwenden der Instanz-Ausgänge sinnvoll, einfach und übersichtlich, und es kommt auch gut in den Referenzdaten:
Code:
U "Motor1".Running
U "Motor2".Running
U "Motor3".Running
U "Motor4".Running
= "enable_Transport"

Bei den IEC-Timern hat doch wohl auch kaum ein Programmierer Skrupel, direkt "TON_xyz".Q zu verknüpfen ...

Aber in diesem Forum hat es schon sehr viele Diskussionen über den Zugriff auf Instanzdatenbausteine gegeben.
Es soll jeder Programmierer selbst (bzw die Firma oder Kunde) entscheiden wie er seine Projekte umsetzt.
*ACK*

(*) Man muß allerdings mehr auf die Bausteinkonsistenz achten als bei Nutzung von Zwischen-/Rangiervariablen - was aber ebenfalls eine "Bereichskopplung" ist.

Harald
 
Bedeutet das nun, dass der Zugriff auf den Instanzdatenbaustein nichts anderes ist, als würde ich gleich die TEMP-Variablen verwenden?

Die TEMP-Variablen sind doch die Lokalvariablen!
Mit "Lokalen Variablen" von Instanzdaten meint godi deren private gekapselte Daten (die Daten der aufgerufenen Funktion, ein Zugriff auf diese ist tabu), während die ebenfalls nutzbaren TEMP-Daten als Zwischenvariablen die lokalen privaten Variablen des Aufrufers sind - und der kann mit seinen privaten Variablen machen was er will, hauptsache die Variablen enthalten auch etwas sinnvolles beim Lesezugriff.

Harald
 
Sorry, wenn ich da jetzt nochmals nachhaken muss...

Bedeutet das nun, dass der Zugriff auf den Instanzdatenbaustein nichts anderes ist, als würde ich gleich die TEMP-Variablen verwenden?

Die TEMP-Variablen sind doch die Lokalvariablen!

Nein, das ist was anderes.
Jeder FB-Aufruf bedingt einen existierenden DB.
In diesem sind die IN/OUT/IN_OUT/STAT abgebildet.
 
Zurück
Oben