TIA Warum werden Baustein-Eingänge auf interne Variablen rangiert?

Zuviel Werbung?
-> Hier kostenlos registrieren
Hach da wünsch ich mir die s5 zurück.
Da hast nie gewusst, ob dir ein externer treiber die daten verpfuscht.
Da hat man immer auf konsistenz programmiert. Weil man eben wusste, dass man nix weis :)
 
Hach da wünsch ich mir die s5 zurück.
Da hast nie gewusst, ob dir ein externer treiber die daten verpfuscht.
Da hat man immer auf konsistenz programmiert. Weil man eben wusste, dass man nix weis :)

Ja, bei ner S5 gabs auch so schöne Dinge. Ich hab da auch mal 3 Wochen am Stück nix anderes gemacht als nen Kommunikationsfehler bei einer RK512-Kommunikation zu nen Siemens BS200-Mainframe zu suchen. Nach den 3 Wochen hatte ich den Fehler soweit dass ich ihn reproduzieren konnte. Dann konnten sich die Siemens CP-Entwickler in Karlsruhe mit den BS2000-Kollegen rumschlagen. Gab dann nach Wochen ein Firmware-Update für die CP.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich meine auch, dass im Programming Style Guide von Siemens für die S7-1500 steht, dass der Zugriff auf interne Variablen (temps) ressourcenschonender sei. Wenn also im FC mehrfach auf den Eingang zugegriffen wird, kann es durchaus besser für die Zykluszeit sein, erst den Eingang auf einen Temp zu kopieren und den dann weiterzuverwenden.

Ist aber gefühlt auch so ein Ding, das für 0,01% aller Anwender relevant ist.
 
Ich hatte immer mal bei 300ern Probleme, daß sich Input-Variable im Baustein nicht an einen weiteren Baustein übergeben lassen. Ich denke, es waren keine Basistypen. Vermutlich scheiterte es daran, daß erweiterte Typen als byReference übergeben werden und dann eine weitere Übergabe nicht mehr compiliert werden kann. Diese und nur diese habe ich in einem solchen Fall auf Temp-Variable umkopiert.

1500er und HMI: Muss man sich dran gewöhnen. Ich verwende alle Eingaben aus der Visu nur an einem Punkt im Programm und bilde Ausgangswerte auch nur an genau einem Punkt aus Temp-Variablen.
 
vielen Dank für die vielen aufschlussreichen Kommentare - bin tatsächlich sogar etwas froh, dass die so banal klingende Ursprungsfrage letztlich doch so eine rege Diskussion angestoßen hat. Da sieht man, dass das Thema offenbar dann doch nicht jedem gleich so klar war...

ich dachte zunächst auch, dass es es sich um ein Relikt aus alten Zeiten handelt, aber die Erklärung mit dem call-by-value und call-by-reference leuchtet total ein(y)

und auch mit HMI-Signalen die ja quasi als Interrupt wirken, kann das somit durchaus Sinn machen, sie auf Baustein-interne Variablen zu rangieren (y)

Again what learned 🙂
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich meine auch, dass im Programming Style Guide von Siemens für die S7-1500 steht, dass der Zugriff auf interne Variablen (temps) ressourcenschonender sei. Wenn also im FC mehrfach auf den Eingang zugegriffen wird, kann es durchaus besser für die Zykluszeit sein, erst den Eingang auf einen Temp zu kopieren und den dann weiterzuverwenden.

Ist aber gefühlt auch so ein Ding, das für 0,01% aller Anwender relevant ist.
Naja ich rangiere im Code häufig abgefragte Input-Parameter in Temp-Variablen in unserem Standart um die Zykluszeit so minimal wie möglich zu halten. Ob das nun wirklich was Zyklus mäßig bringt weiß ich nicht. Wenn der Standart-Baustein aber 200 mal aufgerufen wird spare ich mir vielleicht so 1/10 einer Millisekunde 😂 Kostet ja nichts.
 
Bei den Temp Variablen ist aber noch zu beachten, das diese nicht systemseitig initialisiert werden bei nicht optimierten Bausteinen. D.h. immer zuerst schreiben dann lesen :)
 
Also ich kenne das auch so, daß die I/Os am Anfang in einen DB geschrieben werden und am Ende wieder raus.
Gerade wenn man das Progamm wiederverwendbar machen will. Außerdem lassen sich Änderungen einfacher umsetzen, ohne das Programm groß anfassen zu müssen.
Ist aber wahrscheinlich auch eine Frage wie komplex das Programm ist und welche Anforderungen im Raum stehen.
Gerade wenn da ein dickes Busnetz und vielleicht noch ein MES drüber steht hilft das durchaus.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zur Erinnerung: Hier im Thread geht es eigentlich nicht um den Sinn von umrangieren von I/O oder generelle Benutzung von TEMP-Variablen, sondern warum werden Baustein-Inputs/Outputs anscheinend unnötig auf TEMP-Variablen umkopiert...

Gründe können sein
* call-by-Reference bei Multitasking Problematik
* bessere Performance von TEMP-Zugriffen bei Mehrfach-Zugriffen (schnellerer und kürzerer Programmcode)
* Werte sollen an Bausteine weitergereicht werden
 
Zur Erinnerung: Hier im Thread geht es eigentlich nicht um den Sinn von umrangieren von I/O oder generelle Benutzung von TEMP-Variablen, sondern warum werden Baustein-Inputs/Outputs anscheinend unnötig auf TEMP-Variablen umkopiert...

Gründe können sein
* call-by-Reference bei Multitasking Problematik
* bessere Performance von TEMP-Zugriffen bei Mehrfach-Zugriffen (schnellerer und kürzerer Programmcode)
* Werte sollen an Bausteine weitergereicht werden
Sorry mein Fehler, wer lesen kann ist klar im Vorteil :)
 
Zurück
Oben