Frage zu Temp-Variablen...

[godi]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

Genau das habe ich gemeint.

 

[godi]

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:

U "Motor1".Running
U "Motor2".Running
U "Motor3".Running
U "Motor4".Running
= "enable_Transport"

Das stimmt schon, dass es einfach und in manchen Fällen auch übersichtlich ist.
Das Problem liegt eher an der Entwicklungsumgebung Step7 und TIA das es möglich ist die Out-Parameter auch zu beschreiben.
Besser wäre wenn zb mit "Motor1".out.running nur lesend darauf zugegriffen werden kann und mit Absoluten Operanden gar nicht.
Das selbe gilt natürlich für in (nur lesend) in_out (schreiben und lesen) und stat (gar kein Zugriff).

Aber da hinkt Siemens beim TIA mit der Abwärtskompatibilität zum Simatic Manager hinten nach.

 

[spirit]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mit "Lokalen Variablen" von Instanzdaten meint godi deren private gekapselte Daten (die Daten der aufgerufenen Funktion, ein Zugriff auf diese ist tabu)...

Harald

... also doch die Variablen des zugehörigen FB's oder? Und das sind doch, wenn ich STAT-Variablen deklariere, nicht die lokalen Variablen.

 

[ducati]

... also doch die Variablen des zugehörigen FB's oder? Und das sind doch, wenn ich STAT-Variablen deklariere, nicht die lokalen Variablen.

Ohh mann... Begriffe sind oft Schall und Rauch. Der eine verwendet sie und der andere versteht das Gegenteil darunter.

Lokale statische Variablen sind statische Variablen in nem (Instanz)-DB welche man nicht extern (ausserhalb des zugehörigen FBs) verwenden sollte. Es sind aber eigentlich globale statische Variablen, da sie trotzdem extern verfügbar sind. Die liegen auch nicht im Lokaldatenstack sondern in nem DB.

Gruß

 

[godi]

In der S7-Welt versteht man unter Lokalen Variablen alle die in dem Bausteinkopf deklariert werden.
Egal ob sie jetzt im stat, temp, in, in_out, out bereich liegen. Also alle Variablen auf die man mit "#Variablenname" zugreift.

Globale Variablen sind zb Merker. Diese können in jedem Baustein verwendet werden.
Auch die Daten in einem Datenbaustein sind Global.

Es wird aber zwischen Globalen Datenbausteinen (die du selbst anlegst und Global_DB auswählst) und Instanzdatenbausteinen (die zu einem FB gehören und somit die Lokalen Variablen* des FB's beinhalten) unterschieden.
Da es sich aber bei beiden Datenbausteinen um das selbe "Speicherkonzept" handelt gibt es keinen Unterschied beim Zugriff auf die Bausteine.

Also wenn du jetzt in einem FB eine Variable im Stat-Bereich namens "Wert" definierst so kannst du im FB mittels #Wert auf den Speicherbereich zugreifen.
Ausserhalb des FB's könntest du aber auch über den Instanzdatenbaustein zugreifen mittels DBx.Wert => Dies ist nicht elegant.

*Ausser die Temp-Variablen, dessen Speicherbereich liegt im Stack.

 

[spirit]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also wenn du jetzt in einem FB eine Variable im Stat-Bereich namens "Wert" definierst so kannst du im FB mittels #Wert auf den Speicherbereich zugreifen.
Ausserhalb des FB's könntest du aber auch über den Instanzdatenbaustein zugreifen mittels DBx.Wert => Dies ist nicht elegant.

Ok, vielen Dank! Soweit ich das jetzt verstanden habe, ist das ja exakt der Vorschlag von Harald...

Ansonsten blieb halt nur der Weg über die Temp-Variablen, da ich ja außerhalb des FB's auf seinen Speicherbereich zugreife.

 

[godi]

Ok, vielen Dank! Soweit ich das jetzt verstanden habe, ist das ja exakt der Vorschlag von Harald...

Ansonsten blieb halt nur der Weg über die Temp-Variablen, da ich ja außerhalb des FB's auf seinen Speicherbereich zugreife.

Es bleibt nicht nur der Weg über die Temp-Variablen.
Du kannst die Werte in jedem beliebigen Speicherbereich (Temp, Stat, anderer DB, Merkerbereich) zwischenspeichern.
Jedoch wenn du die Werte nur Lokal (also in dem Baustein) und nur während eines Zyklus benötigst dann genügt es wenn diese Werte im Temp Bereich liegen.

Ja das S7-Speicherkonzept kann am Anfang zu Verwirrung führen!

 

[spirit]

Oki, vielen Dank godi!

Aber zumindest hätte ich (als Anfängerin) bei einem Zugriff über den InstanzDB auf die statischen Variablen des FB's etwas mehr Sicherheit, dass diese auch im nächsten Zyklus (zwingend) noch identisch sind...

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also wenn du jetzt in einem FB eine Variable im Stat-Bereich namens "Wert" definierst so kannst du im FB mittels #Wert auf den Speicherbereich zugreifen.
Ausserhalb des FB's könntest du aber auch über den Instanzdatenbaustein zugreifen mittels DBx.Wert => Dies ist nicht elegant.

Soweit ich das jetzt verstanden habe, ist das ja exakt der Vorschlag von Harald...

Nein ist es nicht. Ich würde nie vorschlagen, von außen auf Instanz-Variablen im STAT-Bereich zuzugreifen. Ich habe nur gezeigt, wie man von außen auf Variablen des IN- und OUT-Bereichs zugreift. Das ist für mich etwas anderes ...

Um jetzt allen Grundsatzdiskussionen um Instanzdaten und Programmierstrategien aus dem Weg zu gehen:
Benutze Zwischenvariablen aus dem TEMP-Bereich - so wie Du es von Anfang an gewollt hast. Solange sichergestellt ist, daß Dein FB1 in diese TEMP-Variablen schreibt, bevor der FB2 daraus liest und niemand diese Variablen verändert, solange ist alles korrekt und gut.

Harald

 

[PN/DP]

Aber zumindest hätte ich (als Anfängerin) bei einem Zugriff über den InstanzDB auf die statischen Variablen des FB's etwas mehr Sicherheit, dass diese auch im nächsten Zyklus (zwingend) noch identisch sind...

OOOOOhhhhhhh, DAS ist tatsächlich noch viel gefährlicher als innerhalb eines Zyklus von einem Netzwerk zum nächsten eine TEMP-Variable zu nutzen.

Frag' lieber nicht warum

Harald

 

[godi]

OOOOOhhhhhhh, DAS ist tatsächlich noch viel gefährlicher als innerhalb eines Zyklus von einem Netzwerk zum nächsten eine TEMP-Variable zu nutzen.

Frag' lieber nicht warum

Harald

Jep, und genau da beginnt das Problem beim Zugriff auf Instanzdatenbausteine.
Man sieht außerhalb des FB's nicht in welchen Bereich sie liegen und man kann darauf auch schreibend zugreifen.

So wie bei deinem Beispiel mit dem Motor wird dann von einem unwissenden oder einfach in der Eile / Unachtsamkeit nicht "Motor".start = 1 sondern "Motor".running = 1 geschrieben.
=> Schlechtestenfalls crash da ein Endschalter oder sonstiges damit überbrückt wird. Da hilft dir dann der best-getestete Motorbaustein nichts mehr.

 

[spirit]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Harald: Nein, ich frage schon nicht warum - würde es vermutlich eh nicht verstehen... aber du hast doch geschrieben, dass ich im FB1 die Ausgänge unbeschaltet lassen soll u. das geht doch nur mit stat. Variablen. Ansonsten bekomme ich doch einen Fehler.

@Allgemein: In der Tat habe ich in meinem Beispiel (Beitrag #21) die Variablen "druck_hoch" und "druck_niedrig" als statische Variablen in den FB's deklariert. Und das soll jetzt echt falsch sein, oder wie? *binamverzweifeln*

 

[godi]

@Harald: Nein, ich frage schon nicht warum - würde es vermutlich eh nicht verstehen... aber du hast doch geschrieben, dass ich im FB1 die Ausgänge unbeschaltet lassen soll u. das geht doch nur mit stat. Variablen. Ansonsten bekomme ich doch einen Fehler.

@Allgemein: In der Tat habe ich in meinem Beispiel (Beitrag #21) die Variablen "druck_hoch" und "druck_niedrig" als statische Variablen in den FB's deklariert. Und das soll jetzt echt falsch sein, oder wie? *binamverzweifeln*

Im Beitrag 21 hast du die Variablen "druck_hoch" und "druck_niedrig" im ersten Baustein als out und im zweiten als in deklariert.
Ansonsten würden sie beim Bausteinaufruf nicht angezeigt werden.
Input werden immer links und Output immer rechts angezeigt.

Merke dir:
Wenn du einen wiederverwendbaren Baustein haben willst, dann deklarierst du alle Variablen die von außerhalb des Bausteines kommen als in.
Alle Variablen die du außerhalb des Bausteines lesen willst, deklarierst du als out.
Alle anderen Variablen die du zb zur internen Berechnung benötigst werden als stat oder temp deklariert.

Du kannst bei einem FB auch die Ausgänge unbeschaltet lassen da diese (wie die stat Variablen) im Instanzdatenbaustein gespeichert sind.
Somit lest du dann deine Out-Variable von FB1 aus dem zugehörigen Inst.DB. Deshalb ist Haralds Vorschlag möglich:

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.

CALL "Alarme","FB2_DB"    //Aufruf des FB2
 druck_hoch      :="FB1_DB".druck_hoch
 druck_niedrig   :="FB1_DB".druck_niedrig
 druck_fehlerhaft:="Fehler"

Harald

 

[Tigerente1974]

Leider sind die Antworten etwas abgedriftet. Ich denke Du stehst noch am Anfang und bist etwas überfordert mit Dingen wie Absolutzugriffe auf Instanz-DBs von außen.

Wenn man es einfach halten will, macht man es genauso wie Du es vor hattest. Die Variable als OUT bzw. IN wird an die Schnittstelle gehängt. Du kannst im OB1 auch TEMP-Variablen dafür verwenden, musst aber natürlich die Reihenfolge der Bausteinaufrufe beachten.

Sofern Du in dem Baustein selbst keine Ergebnisse speichern willst, kannst Du sogar einen FC anstelle eines FB nehmen.

 

[spirit]

Zuviel Werbung?
-> Hier kostenlos registrieren

Im Beitrag 21 hast du die Variablen "druck_hoch" und "druck_niedrig" im ersten Baustein als out und im zweiten als in deklariert.
Ansonsten würden sie beim Bausteinaufruf nicht angezeigt werden.

Danke godi; es ist ja herrlich zu sehen, dass du mein Programm besser kennst als ich selbst!

Also du hast Recht; hatte hier die Variablen schon als In- bzw. Out deklariert!

Ja Tigerente, stimmt - stehe ziemlich am Anfang und verlassen in der S7-Welt... aber es ist ja noch keine Meisterin vom Himmel gefallen...

Auch wenn Harald es mir ja fast verboten hat nachzufragen - meine Neugierde ist mittlerweile so groß geworden, dass ich nicht anders kann:

Was wäre denn das Problem, wenn ich (wie ja eigentlich von mir angenommen) die Variablen nicht als IN bwz. OUT deklariert hätte, sondern als STAT?

evtl. dass ich sie dann von außen steuern kann? (nur so ein Verdacht!)

aber ein Ausgang lässt sich doch auch von Außen steuern...

Ob ich das hier noch kapiere???

Lieben Dank' euch für eure Mühe - sehe schon, bin ein schwerer Fall!

 

[ducati]

Was wäre denn das Problem, wenn ich (wie ja eigentlich von mir angenommen) die Variablen nicht als IN bwz. OUT deklariert hätte, sondern als STAT?

Du verlierst den Überblick im Programm, da Du den FB nicht mehr losgelöst vom restlichen Programm betrachten/debuggen kannst. Es ist einfach "unsauber" wenn irgendwelche anderen Programmteile in den Variablen eines FBs von aussen herumfuschen...

gruß.

 

[godi]

Lese dir den Wiki Artikel über Datenkapselung durch. Du wirst das am Anfang höchstwahrscheinlich noch nicht ganz verstehen aber du hast es zumindest mal gelesen und wenn du dann mal weiter beim Programmieren bist wirst du das auch verstehen.

Vorallem bei diesem Abschnitt ersetzt du einfach Klasse mit Funktionsbaustein:

Eine Klasse hat eine Schnittstelle, die darüber bestimmt, auf welche Weise mit der Klasse interagiert werden kann. Dies verhindert das Umgehen von Invarianten des Programms. Vom Innenleben einer Klasse soll der Verwender – gemeint sind sowohl die Algorithmen, die mit der Klasse arbeiten, als auch der Programmierer, der diese entwickelt – möglichst wenig wissen müssen (Geheimnisprinzip). Durch die Kapselung werden nur Informationen über das „Was“ (Funktionsweise) einer Klasse nach außen sichtbar, nicht aber das „Wie“ (die interne Repräsentation). Dadurch wird eine Schnittstelle nach außen definiert und zugleich dokumentiert.

 

[spirit]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

habe mal übersetzt:

"Ein FB hat eine Schnittstelle, die darüber bestimmt, auf welche Weise mit dem FB interagiert werden kann. Durch die Kapselung werden nur Informationen über das „Was“ (Funktionsweise) eines FB's nach außen sichtbar, nicht aber das „Wie“ (die interne Repräsentation)."

Soll das nun heißen:

Das Problem mit dem Zugriff auf STAT-Variablen von Außen ist dadurch begründet, dass STAT-Variablen im Gegensatz zu IN- oder OUT-Variablen die Möglichkeit besitzen, Daten zu speichern und somit auch von außen zu verändern?

 

[ducati]

Ich denke, Du brauchst erstmal mehr Erfahrung und Verständnis mit der S7-Welt, bevor Du verstehst, was wir Dir hier sagen wollen...

 

[Tigerente1974]

Der Zugriff auf STAT-Variablen durch Zugriffe von außen ist möglich. Das verleitet vielleicht auch dazu, das zu machen. Wie so oft beim Programmieren kann man Aufgaben unterschiedlich angehen. Manchmal kommen dabei auch so Dinge heraus, dass die Reihenfolge von Netzwerken eine Bedeutung erhält. Z.B. bei der Verwendung von TEMP-Variablen. Jetzt gibt es diejenigen die sagen "Das ist Dein Programm und wenn Du weißt was Du tust, ist das so in Ordnung". Und dann gibt es diejenigen, die sagen "Das kann man so machen, dann isses aber Kacke...", z.B. weil Veränderungen am Programm unbemerkt zu Fehlern führen können. Das gilt vor allem bei externen Zugriffen auf STAT-Variablen, wenn in dem IDB durch Veränderungen Adressen verschoben werden. Dann passen die externen Zugriffe nämlich nicht mehr.

Die vielleicht aufwändigere Variante ist das Beschalten der IN/OUT-Schnittstelle. Das ist die "sichere" Variante den Baustein an die Außenwelt zu koppeln, die ich Dir als Neuling auch uneingeschränkt empfehlen würde.