TIA Daten in Variablen oder Datenbaustein abspeichern - Unterschied

[Patrick_L]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Gemeinde,

ich programmiere zum spaß und habe mal eine S7-1200 gewonnen (Ja das gibts )
Nun habe ich mich mal wieder dran gesetzt und mich mit TIA beschäftigt.
Von "früher" habe ich es (woher auch immer) so im Kopf das ich meine Daten in einem DB oder Merker abspeichere, die ich irgendwann, irgendwo (selber oder anderer FB) wieder benötige.

Da ich mich wieder mit TIA beschäftige bin ich nun über die FB Variablen gefallen.
Mir ist bewusst, das ich diese "Input" sowie "Output" bei dem Call des entsprechenden FB übergeben und nehmen kann.

Mir stellt sich jetzt aber die Frage: Gibt es für diese FB Variablen ein "Best Practice" und Warum sollte ich die Variablen nehmen und nicht den Wert den ich nutzen möchte in einen "Daten DB" oder in Merker abspeichern?

Ich kann mir nur vorstellen, bei großen Projekten um Speicher der Steuerung "zu sparen". Durch Internet suche bin ich (für mich) keiner vernünftigen Antwort gekommen

 

[021aet04]

In den Programmbausteinen definierst du die Variablen die du nur dort benötigst.

Stelle dir vor du willst einen Baustein verwenden den du nicht selbst gemacht hast. Woher weißt du welche Variablen du benötigst?

Ein weiterer Vorteil wäre, dass er bibliothekskonform ist. Du kannst ihn in eine Bibliothek verschieben.

Mfg Hannes

 

[Januar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Prinzipiell kann ich den Programmierleitfaden von Siemens (hier) empfehlen.

Allgemein lässt sich sagen, dass das eine Frage der Wiederverwendbarkeit ist.
Ich habe in meinem jüngsten Projekt beispielsweise eine Gruppe von drei Pumpen, die abhängig von der Last mit unterschiedlicher Anzahl laufen. Wenn eine Pumpe zugeschaltet werden soll, sucht mein FB "AggregatePriorisieren" unter den inaktiven Pumpen nach derjenigen Pumpe mit den wenigsten Betriebsstunden.
Jetzt hab ich aber auch noch eine Gruppe von drei Kesseln, die das Wasser der Pumpen erhitzen sollen. Auch hier werden abhängig vom Bedarf verschieden viele Kessel benötigt.

Wenn ich in meinem FB "AggregatePriorisieren" direkt die Variablen "PumpeXAktiv" und "BetriebsstundenPumpeX" verwendet hätte, dann hätte ich einen zweiten FB schreiben müssen, in dem ich die Variablen der Kessel direkt verknüpfe.
Da ich aber im FB nur Input/Output-Variablen benutze, kann ich den FB sowohl für die Priorisierung der Pumpen als auch für die Kessel nehmen.

Ist also weniger eine Frage von "Speicher sparen". Wenn das das Ziel gewesen wäre, dann wäre es heute immer noch nicht möglich, ein Programm mit Kommentaren und Symboliken von einer Steuerung zurückzuladen.

 

[Larry Laffer]

Ich würde (auch) sagen, dass Wiederverwendbarkeit und Übersichtlichkeit der springende Punkt ist. Speicher sollte heute ja keine Rolle mehr spielen.
Ich nehme in einem Baustein also keine globalen Variablen direkt sondern gebe sie ihm über die Schnittstelle (IN, IN_OUT, OUT). Das können sowohl E's und A's, aber auch Parameter und andere Werte sein.
Um die da jetzt etwas Konkretes vorschlagen zu können müßte man aber wissen was du konkret machen willst ...

 

[PN/DP]

Von FB kann und muss man Instanzen mit den Variablen anlegen, Variablen die im FB deklariert sind, (in Static) bekommt jede Instanz automatisch seine eigenen Variablen, die sich nicht gegenseitig beeinflussen. Globale Variablen außerhalb der Instanz werden von allen Instanzen gemeinsam benutzt und können sich daher nichts für jede Instanz getrennt merken.

 

[Patrick_L]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich bin jetzt leider nicht vorOrt so das ich Bilder von meinem Programm erstellen kann, so das ich es etwas Visualisiert erklären kann.
Daher versuche ich es jetzt so:
Eine 2Klappen Steuerung mit zwei Motoren,4 Endschalter abhängig von der Temperatur.
-Bei Überschreitung von TempMax soll eine klappe aufgehen bis zum Endschalter, ist die Temperatur nach xMinuten immernoch drüber geht die 2. Klappe auf, bis zum eigenen Endschalter. Die Ausgänge hätte ich nicht in dem DB geschalten, sondern nur der Bool "Rechts auf" in einen DB. Das selbe mit der 2. Klappe sowie bei "zu") Das ganze mittels SR Bausteinen.
-In einem anderen FB, nehme ich her zum setzen der Uhrzeit in der Steuerung sowie zur Steckdosen Steuerung über eine Zeitschaltuhr (RIO) (Bitvergleich Uhrzeit und einem Struct in dem "DatenDB") Auch hier wieder mit Merker, oder einem Bool in dem DatenDB.
Von den beiden FB, die Merker oder "Einträge" in dem DatenDB werden dann wiederum in einem eigenen FB/FC abgearbeitet so das die entsprechenden Ausgänge gesetzt werden.

Die RIO "normal" unter Netze konfiguriert.
1x DB für das (Zwischen)speichern von Werten
Sowie eigene FB/FC für die Aufgaben von oben.


Ich hoffe ich konnte das etwas beschreiben was ich vorhabe, auch ohne Bilder.

Nun habe ich mir etwas Gedanken gemacht welche Vorteile ich mit den IN/OUT Variablen hätte und was so der Best Practice ist. Den Link zu der Siemens KB Schaue ich mir noch an.

 

[DCDCDC]

Ich bin jetzt leider nicht vorOrt so das ich Bilder von meinem Programm erstellen kann, so das ich es etwas Visualisiert erklären kann.
Daher versuche ich es jetzt so:
Eine 2Klappen Steuerung mit zwei Motoren,4 Endschalter abhängig von der Temperatur.
-Bei Überschreitung von TempMax soll eine klappe aufgehen bis zum Endschalter, ist die Temperatur nach xMinuten immernoch drüber geht die 2. Klappe auf, bis zum eigenen Endschalter. Die Ausgänge hätte ich nicht in dem DB geschalten, sondern nur der Bool "Rechts auf" in einen DB. Das selbe mit der 2. Klappe sowie bei "zu") Das ganze mittels SR Bausteinen.
-In einem anderen FB, nehme ich her zum setzen der Uhrzeit in der Steuerung sowie zur Steckdosen Steuerung über eine Zeitschaltuhr (RIO) (Bitvergleich Uhrzeit und einem Struct in dem "DatenDB") Auch hier wieder mit Merker, oder einem Bool in dem DatenDB.
Von den beiden FB, die Merker oder "Einträge" in dem DatenDB werden dann wiederum in einem eigenen FB/FC abgearbeitet so das die entsprechenden Ausgänge gesetzt werden.

Die RIO "normal" unter Netze konfiguriert.
1x DB für das (Zwischen)speichern von Werten
Sowie eigene FB/FC für die Aufgaben von oben.


Ich hoffe ich konnte das etwas beschreiben was ich vorhabe, auch ohne Bilder.

Nun habe ich mir etwas Gedanken gemacht welche Vorteile ich mit den IN/OUT Variablen hätte und was so der Best Practice ist. Den Link zu der Siemens KB Schaue ich mir noch an.

Merker brauchst du nicht, dafür nutzt du Variablen in Datenbausteinen. Systemmerker sind da wieder anders, darüber bekommst du ein sauberes true und false Signal, aber auch pulsierende Signal direkt vom System, ohne dafür etwas programmieren zu müssen.

InOut nur für Daten welche innerhalb der Funktion gelesen und geschrieben werden. Für alles andere gibt es getrennte Bereiche.

Denk daran physische Ausgänge nur einmal zu beschreiben.. lieber an die Ausgänge deiner Funktionen Bitvariablen parametrieren und dann daraus ein ODER zu basteln.

Instanzen von Funktionsbausteinen können auch im statischen Bereich eines anderen Funktionsbausteins deklariert werden.

 

[circlehook]

statischen Bereich vom OB1

Meine Organisationsbausteine haben sowas nicht

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Meine Organisationsbausteine haben sowas nicht

Ups.. OBs nicht.. natürlich.

 

[Patrick_L]

Die Bilder habe ich nicht vergessen, die sind jetzt in meinem 2. Post Angehängt