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

[Hexmex]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Forum,

wozu werden in so manchem Programmierstandard bzw. Programmierstyle die Baustein-Eingangsvariablen zuerst auf Baustein-interne Variablen (static oder temporär) rangiert, bevor sie im Baustein verwendet werden?

Man könnte doch genauso gut mit den Baustein-Eingängen direkt arbeiten...
Danke

 

[PeterPan-35]

Beides ist machbar und funktioniert identisch.

Das ist heutzutage eigentlich nur noch eine Geschmacksfrage.

Bei alten SPS-Systemen war das mal auf eine gewisse Weise nützlich.

Aber heute ist das eher ein relikt, bzw. weil es jemand schöner und strukturierter empfindet, "es schon immer so gemacht wurde".
Obwohl man heute auch mit den normalen E/A-Variablen strukturiert arbeiten kann.

Habe schon mit beidem arbeiten müssen, finde das rangieren jedoch in der heutigen Zeit eher lästig und unnötig.
Daher mache ichs nur, wenns jemand explizit fordert.

 

[winnman]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hat vorteile wenn du das Prog auf andere Hardware umziehst, . . .
brauchst dann nur einmalig die E/A anpassen, egal wie oft die intern verwendet werden, auch invertieren kann hier vernünftig erfolgen, . . .
Bei Analogwerten wird dann meist auch gleich normiert / denormiert, dann hast du intern den normierten Wert, . . . .

Würde ich auf alle Fälle empfehlen.

 

[Hexmex]

Entschuldigung, ich hab mich vermutlich nicht genau ausgedrückt. Das Arbeiten mit INPUTS/OUTPUTS aufgrund der Multiinstanz-Fähigkeit ist mir klar, mir geht´s hauptsächlich darum, warum z.B. der INPUT nochmals auf eine Static-Variablen rangiert wird.
Das macht für mich technisch wenig Sinn und sieht ein wenig nach individuellem Programmierstil aus, ohne einen konkreten Nutzen zu haben.
Aber es läuft mir so häufig über den Weg, dass es meine Neugier geweckt hat

 

[Hexmex]

Aber heute ist das eher ein relikt, bzw. weil es jemand schöner und strukturierter empfindet.
Obwohl man heute auch mit den normalen E/A-Variablen strukturiert arbeiten kann.

Habe schon mit beidem arbeiten müssen, finde das rangieren jedoch in der heutigen Zeit eher lästig und unnötig.
Daher mache ichs nur, wenns jemand explizit fordert.

so sehe ich das eigentlich auch und mache ich ebenfalls nur falls es konkret vorgegeben wurde

 

[PeterPan-35]

Zuviel Werbung?
-> Hier kostenlos registrieren

Entschuldigung, ich hab mich vermutlich nicht genau ausgedrückt. Das Arbeiten mit INPUTS/OUTPUTS aufgrund der Multiinstanz-Fähigkeit ist mir klar, mir geht´s hauptsächlich darum, warum z.B. der INPUT nochmals auf eine Static-Variablen rangiert wird.
Das macht für mich technisch wenig Sinn und sieht ein wenig nach individuellem Programmierstil aus, ohne einen konkreten Nutzen zu haben.
Aber es läuft mir so häufig über den Weg, dass es meine Neugier geweckt hat

Das würde ich auch als Stilrichtung sehen.

Habe ich so noch nie gemacht auch noch bei keinem Kundenstandard gesehen.

Sofern man das Signal dann nicht im Code nachträglich manipuliert und es daher umkopiert hat.

 

[PN/DP]

Der Grund ist, damit man sicher ist, bei der zweiten Abfrage den selben Wert wie bei der ersten Abfrage zu erhalten. Weil das ist nur garantiert bei Parameter-Übergabe "by value". Bei "by reference" könnte sich der Wert zwischendurch geändert haben. Man schafft sich quasi ein Prozessabbild des Eingangsparameters, ohne beachten zu müssen, wie denn gerade die Übergabe des Eingangsparameters stattfindet. Es ist also nicht "egal" oder "Geschmacksfrage".

 

[Blockmove]

Bei 1500er Steuerungen hast du keinen Zykluskontrollpunkt. Macht sich bei HMI oder Kommunikation bemerkbar. Ausserdem gibt es noch ein paar Besonderheiten bei "Call by Value" oder "Call by Reference".

Edit:
PN/DP war schneller

 

[Glasesba]

Zuviel Werbung?
-> Hier kostenlos registrieren

In dem gezeigten Bild werden ja die Input Parameter auf Static kopiert. Das ist ja eigentlich unnötig da die "Call-by-value" sind.

 

[PN/DP]

Ist bei dem (vermutlich vereinfachten) FB-Beispiel tatsächlich unnötig, Man ist aber ohne drüber nachzudenken auf der sicheren Seite. Und man kann den Code auch in einen FC kopieren und braucht auch da nicht drüber nachdenken. Solcher Code könnte auch aus einem FC stammen und funktioniert ohne Änderung auch in FB.

 

[Stups]

Jetz mal ne blöde frage: wie können sich am baustein verschaltete variablen in einem zyklus innerhalb eines bausteines ändern?
Natürlich gehe ich bei der frage davon aus, dass keine variablen ausserhalb/in einem anderen zyklus geschrieben werden.

 

[de vliegende hollander]

Zuviel Werbung?
-> Hier kostenlos registrieren

Jetz mal ne blöde frage: wie können sich am baustein verschaltete variablen in einem zyklus innerhalb eines bausteines ändern?
Natürlich gehe ich bei der frage davon aus, dass keine variablen ausserhalb/in einem anderen zyklus geschrieben werden.

wenn du am Prozessabbild vorbei direkt von der pheripherie lest.

 

[de vliegende hollander]

Hallo Forum,

wozu werden in so manchem Programmierstandard bzw. Programmierstyle die Baustein-Eingangsvariablen zuerst auf Baustein-interne Variablen (static oder temporär) rangiert, bevor sie im Baustein verwendet werden?

Man könnte doch genauso gut mit den Baustein-Eingängen direkt arbeiten...
Danke

Ich finde sowas auch Rotz.

 

[Richard P.]

Bei den S7-300/400 war das in komplexen FBs notwendig, wenn man mit dem AR2 arbeitet. Bevor man das AR2 verbiegt, hatte man Bausteineingänge meist auf temporäre Variablen rangiert. Am Ende, nach Wiederherstellung des AR2, ensprechend die Ausgänge.

Wahrscheinlich wurde diese Vorgehensweise von manch einem als besonders intelligent empfunden, und immer wieder und überall ohne Sinn und Verstand genutzt.

... Bei alten SPS-Systemen war das mal auf eine gewisse Weise nützlich...

So kann man es auch sagen .

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Jetz mal ne blöde frage: wie können sich am baustein verschaltete variablen in einem zyklus innerhalb eines bausteines ändern?
Natürlich gehe ich bei der frage davon aus, dass keine variablen ausserhalb/in einem anderen zyklus geschrieben werden.

vom HMI z.B. werden Variablen zu einem beliebigen Zeitpunkt während des OB1 beschrieben. Also wenn Du an Deinen Baustein nicht das E1000.0 dranhängst sondern eine vom HMI beschriebene DB-Variable (oder das E1000.0 vom HMI beschreibst )

Noch lustiger wirds, wenn Du einen Ausgang mehrfach beschreibst und liest, oder/und an mehrere Ausgänge, draussen die selbe Variable dranhängst...

 

[ducati]

Ist bei dem (vermutlich vereinfachten) FB-Beispiel tatsächlich unnötig, Man ist aber ohne drüber nachzudenken auf der sicheren Seite. Und man kann den Code auch in einen FC kopieren und braucht auch da nicht drüber nachdenken. Solcher Code könnte auch aus einem FC stammen und funktioniert ohne Änderung auch in FB.

jo, oder wenns dann doch INOUTs sind, oder Strukturen oder UDTs oder oder...

Macht halt Kopfschmerzen, ständig drüber nachzudenken, ob das jetzt in dem (Sonder)-Fall nicht doch call_by_reference ist...

 

[Stups]

Verstehe eure möglichkeiten total. Aber wenn ich solche relevanten daten azyklisch verwende, dass sie mir mein programm „zerschießen“, hab ich generell ein thema, entweder mit meinem konzept, oder mit meinem wissen.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

oder mit meinem wissen.

naja, es ist halt oft nicht so offensichtlich... (und Siemens hat da auch immer mal abundzu an dem call_by_reference/call_by_value dran rumgeändert)

was häufig vorkommt:
- Eine Eingabe vom HMI funktioniert manchmal nicht
- Eine HMI Variable flackert
- Manche Variablen eines größeren Datenaustausches machen manchmal komische Dinge
- IEC-Timer laufen parallel zum OB1 und sind nicht konsistent

selbst bei alten Hasen...

 

[Blockmove]

Verstehe eure möglichkeiten total. Aber wenn ich solche relevanten daten azyklisch verwende, dass sie mir mein programm „zerschießen“, hab ich generell ein thema, entweder mit meinem konzept, oder mit meinem wissen.

Bei ner S7 300 gibt es den Zykluskontrollpunkt. Die HMI-Daten werden am Zyklusbeginn aktualisiert und werden während des Zyklus nicht vom HMI verändert. Das ist bei einer 1500er nicht mehr so. Das HMI kann zu jeder Zeit die Daten schicken.
Und damit es richtig spaßig ist, gibt es auch noch Unterschiede wie die Daten übergeben werden. Im einen Fall verändern sich die Daten während der Bearbeitung im Baustein, im anderen Fall passen sie nicht, wenn der Baustein verlassen wird.
Ähnlich ist es auch bei der Kommunikation.

Jetzt kannst du dir raussuchen, ob du ein Problem mit Konzept hast, dein Wissen das Problem ist oder Siemens es einfach schei.. implementiert hat.

 

[de vliegende hollander]

Wenn du dich an Grundregeln hälst hast du nie stress mit dem HMI.
Was sind dann die Grundregel.
Die ungeschriebene