TIA TIA V13 Querverweise von statischen FB-Variablen

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der bezieht sich auf mehrfach geänderte interne Berechnungswerte während der FB-Asuführung. Es ist offensichtlich, dass hier ein azyklischer Zugriff nicht zielführend ist.
Wenn am Ende eines FBs in den entspr. Instanz-DB-Bereich Werte für den lesenden Austausch mit anderen Programmteilen geschrieben werden, worin besteht nun der Unterschied dazu, wenn nach der Ausführung des FBs, die gleichen Werte nochmal an einen lokalen DB übergeben werden? Ich konnte in dem Thread bisher keine technische Erklärung finden.

Das ist auch keine Technische Erklärung sondern eine Philosophische.
Der Programmierer eines FBs muss sich nicht darum kümmern dass die Statischen Variablen für externe Zugriffe valid sind. Er kann sich aber drum kümmern, dann kann man technisch gesehen bedenkenlos drauf zugreifen.

Das ist wie mit GOTO. Technisch gesehen spricht nichts dagegen. Es wird aber nicht als guter Stil angesehen.

Wenn man sich des fehlenden Zykluskontrollpunkts bei der 1500/1200/400 bewusst ist, kann man auf Instanzen zugreifen. Man sollte sich aber nicht wundern dass man beim nächsten Arbeitgeber damit aber dann nicht gut ankommt, insbesondere wenn der die Styleguides von Siemens zugrunde legt (welche Siemens ja auch nicht erfunden hat)

 

[DCDCDC]

Das ist auch keine Technische Erklärung sondern eine Philosophische.
Der Programmierer eines FBs muss sich nicht darum kümmern dass die Statischen Variablen für externe Zugriffe valid sind. Er kann sich aber drum kümmern, dann kann man technisch gesehen bedenkenlos drauf zugreifen.

Das ist wie mit GOTO. Technisch gesehen spricht nichts dagegen. Es wird aber nicht als guter Stil angesehen.

Wenn man sich des fehlenden Zykluskontrollpunkts bei der 1500/1200/400 bewusst ist, kann man auf Instanzen zugreifen. Man sollte sich aber nicht wundern dass man beim nächsten Arbeitgeber damit aber dann nicht gut ankommt, insbesondere wenn der die Styleguides von Siemens zugrunde legt (welche Siemens ja auch nicht erfunden hat)

This. Es geht nicht darum, dass es nicht möglich ist, sondern es geht mehr einfach um eine Methodik für best practices. Und gerade weil man auf einer SPS auf einer sehr tiefen und auch im Verbund mit mechatronischen Systemen arbeitet, sollte man schon alleine für sich selbst sagen, dass man soweit wie möglich sämtliche best practices implementiert. Damit erleichtert man sich selbst das Leben und jedem anderen der an dem Projekt arbeiten muss, in welcher Zukunft auch immer.

Der Aufwand der hier in diesem Thread steckt zeitlich und energetisch, hätte man dafür nutze können um einfach die gebrauchten Variablen und Werte in der Funktion nach außen zu legen.

Entweder der TE möchte die best practices anwenden, oder eben nicht, ist jedem freigestellt.. aber diese Diskussion führt zu keinem Endergebnis, da es hier um angwendete Philosophien und Methoden geht.

 

[Fluffi]

Zuviel Werbung?
-> Hier kostenlos registrieren

naja, best practices ist auch, nicht unnötig den Speicherverbrauch und die CPU Auslastung zu erhöhen. Zudem bezieht sich der Stylegudie darauf, nicht wie blöd schreiben und lesend in Instanz-DBs von außen rumzuwerkeln. Wenn man einen klar dafür vorgesehenen konsistenten und reinen Lesebereich schafft ist das ein anderes Thema und kann denke ich nicht pauschal damit abgekanzelt werden.
Auf meine Frage wo bei meinem Fall das Problem sei, war ja zunächst ein angeblicher technischer Einwand die Antwort. Jetzt ist es nur noch "best practices".
Und wenn man sich zu guter letzt so manche Beispielprojekte von der Firma anschaut, welche den Styleguide erstellt hat, dann wird man feststellen, dass die das ähnlich wie ich handhaben. Außerdem ist es kontraproduktiv auf einer SPS halbwegs dynamisch zu programmieren, wenn man nach jedem Aufruf nochmals händisch alles verwursten muss.

 

[DCDCDC]

naja, best practices ist auch, nicht unnötig den Speicherverbrauch und die CPU Auslastung zu erhöhen. Zudem bezieht sich der Stylegudie darauf, nicht wie blöd schreiben und lesend in Instanz-DBs von außen rumzuwerkeln. Wenn man einen klar dafür vorgesehenen konsistenten und reinen Lesebereich schafft ist das ein anderes Thema und kann denke ich nicht pauschal damit abgekanzelt werden.
Auf meine Frage wo bei meinem Fall das Problem sei, war ja zunächst ein angeblicher technischer Einwand die Antwort. Jetzt ist es nur noch "best practices".
Und wenn man sich zu guter letzt so manche Beispielprojekte von der Firma anschaut, welche den Styleguide erstellt hat, dann wird man feststellen, dass die das ähnlich wie ich handhaben. Außerdem ist es kontraproduktiv auf einer SPS halbwegs dynamisch zu programmieren, wenn man nach jedem Aufruf nochmals händisch alles verwursten muss.

Wie hoch fällt denn der zusätzliche Speicherverbrauch und die Auslastung aus? Bitte an reelllen Beispielen belegen.

Du hast ja anscheinend schon einen "vorgesehen konsistenten Lesebereich", warum das nicht einfach in den dafür vorgesehenen Bereichen definieren anstatt alles in den statischen Bereich zu ballern?

Im Styleguide wird das Wort "nur", was auch andersausgedrückt "ausschlieslich" bedeutet im bezug auf statische Variablen in einem FB erwähnt, da ist es egal ob dein Programm nur aus OB1, FC1 und FB1 besteht oder du damit eine halbe Produktionslinie steuerst.

Weil irgendjemand bei Siemens (300.000 MA) sich nicht an den Styleguide hält musst du es also auch nicht, jetzt sind wir wirklich in der achten Klasse angekommen.

Warum ist es kontraproduktiv ein dynamisches Konzept auf Steuerungssystemen zu verwenden? Ich hab schon diverse Bandsteuerungen für Linien mit multi-instanzierten Graph Bausteinen realisiert bei denen alle Zugriffe indirekt über die Schnittstelle erfolgten und es hat mir viel Arbeit erspart im Nachgang, bzw. genrell, kostet aber bei der initialen Erstellung etwas fleiß.

Wenn du weiterhin auf deine Instanzen zugreifen möchtest dann tu das doch gerne, aber du möchtest gar kein Umdenken im Bezug auf deine Arbeitsweise und best practices die dir der OEM mitgibt.