Sinnhaftigkeit des Datentyps ANY im In/Out bzw. Out Bereich bei dynamischer Funktion

nutellahase

Level-2
Beiträge
180
Reaktionspunkte
28
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute!

Mit dem ANY-Pointer kann man ja ganz schöne Dinge anstellen, die so manchen zur Verzweiflung bringen. Ein Anwendungsfall für den ANY-Pointer ist z.B. um dynamische Funktionen zu erstellen. Da hatte ich bisher den Datentyp ANY im Eingangsbereich deklariert.

Vielleicht ein kleines Beispiel ... Ich habe ein Array mit 500 Elementen vom Datentyp INT ... dieses Array ist in einem Datenbaustein abgelegt und wird im restlichen Programm mit Werten gefüllt. Wenn ich jetzt eine dynamische Funktion benötige welche das komplette Array auf eine bestimmte Zahl durchsucht, kommt hier der symbolisch übergebene ANY-Pointer ins Spiel.

Ich weiß dass ein Element 2 Bytes groß ist. Nun kann ich mir aus den ermittelten Daten die im ANY-Pointer hinterlegt sind ja die Gesamtanzahl an Elementen berechnen. Die Zugriffsbreite beträgt 1000 Byte => 1000/2 = 500 Elemente. Die Datenbausteinnummer kann ich mir auch aus dem ANY-Pointer holen. Nun kann ich im weiteren Programm indirekt den DB durchsuchen und das Array auf eine bestimmte Zahl durchsuchen.

Der "Vorteil" bei diesem Vorgehen ist, dass ich dann jederzeit von außen ein anderes Array beschalten kann vorausgesetzt es ist vom Datentyp (bzw. bei Einsatz eines UDTs die Grundstruktur) gleich aufgebaut. Ist also meine übergebene Datenmenge nur 500 Byte groß, dann habe ich insgesamt 250 Elemente...

kurz gesagt: Ich lese aus einem dynamischen Bereich Informationen heraus.

Aber wie verhält es sich nun in die andere Richtung?? Ich möchte jetzt z.B. in einen dynamischen Bereich eine Information schreiben.
Und da fängt es bei mir dann ein wenig an zu haken ... mit schreiben verbinde ich mal automatisch einen Outputparameter. Habe ich allerdings einen ANY-Datentyp als Outputparameter und beschalte mein Array mit den 500 Elementen und möchte jetzt z.B. jedes ungerade Element mit einer bestimmten Zahl beschreiben, dann müsste ich doch erst wieder die Informationen aus dem ANY lesen => was dann wieder für Inputparameter spricht. Oder genauer gesagt wäre das ja dann ein In/Out Parameter (ich lese und schreibe in/aus einem Bereich).

Ich hoffe meine Frage ist halbwegs verständlich :ROFLMAO: .. vielleicht hat ja jemand ein Beispiel wo er schon mal einen ANY im In/Out bzw. Out Bereich verwendet hat. Für mich machen sie bei dynamischen Funktionen eigentlich nur im Inputbereich einen Sinn..

mfg
 
Ich glaube, ich verstehe, was du meinst. ;)
Ich lege solche Any auf IN/OUT, das dient dem besseren Verständnis (Falls ich mal in 5 Jahren das Programm lese oder ein Kollege) und kann ja im Prinzip auch bei Daten erfolgen, die nur als IN verwendet werden. Da ja nur die übergebenen Adressdaten verwendet werden, kann man grundsätzlich auch nur ein IN nutzen und dann indirekt auf die Daten schreiben, aber das sieht man dann nicht an der Schnittstelle "Außen".
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Egal, ob Du lesen oder schreiben willst: Du übergibst als Eingangsparameter einen ANY mit der Adresse und Größe des zu lesenden und/oder zu schreibenden Bereichs. Mit dem übergebenen Bereich kannst Du machen was Du willst - lesen und beschreiben.

Man kann als Hinweis darauf, daß in diesen Bereich auch geschrieben wird, den ANY an IN_OUT angeben - was imho allerdings nicht ganz korrekt ist, weil ja nicht die Variable beschrieben wird, die den ANY enthält, sondern der Bereich, auf den der ANY zeigt (es soll ja nicht ein ANY zurückgegeben werden).

Parameterübergaben "per Reference" bzw. überhaupt die ganze Pointer-Geschichte in Step7 ist von Siemens nicht gerade leicht verständlich und konsistent implementiert worden, z.B. ist beim SFC20 BLKMOV der DSTBLK-ANY ein OUT-Parameter!

Harald
 
Hallo Harald!

Demzufolge greift der SFC20 intern auch lesend auf die Variable DSTBLK zu. Ansonsten wüsste er ja nicht wohin mit den Daten. Soweit korrekt? Also ist das quasi nur eine "optische" Verbesserung. Man könnte ja genausogut hergehen und die Variable DSTLBLK ebenfalls als IN deklarieren. Und genau das ist eigentlich meine Frage, wieso es dann überhaupt möglich ist eine Variable vom Typ ANY überhaupt in den In-Out bzw. Out Bereich zu deklarieren.

So wie Ralle und du es bereits geschrieben habt, dient es eg nur als Hinweis, damit man vermuten kann, dass in der Folge auf den Bereich ein schreibender Zugriff erfolgt.
 
ANY als Bausteinparameter

Richtig, es ist nur "Optik".

Egal ob ein Bausteinparameter vom Typ ANY ein IN-/OUT-/INOUT-Parameter ist:
- alle werden vor dem Bausteinaufruf mit der Adresse des Aktualparameters beschrieben (nie mit dem Inhalt, auch wenn es eine ANY-Variable ist)
- alle Parameter können im Baustein gelesen und auch beschrieben werden
- der Inhalt des Parameters wird nach dem Bausteinende verworfen (einfach nicht ausgewertet, kein Kopieren in die Aktualparameter-Variable)

--> Der aufrufende Baustein behandelt alle ANY-Parameter wie IN-Parameter.
--> Soll der aufgerufene Baustein einen Wert über einen ANY-Parameter zurückgeben, dann muß er ihn selbst in die Aktualparameter-Variable schreiben. Die Rückgabe kann auch über IN-Parameter erfolgen!

Man kann einem Baustein nicht ansehen, ob ein OUT-ANY-Parameter nur als IN-Adressübergabe benutzt wird oder ob der Baustein tatsächlich einen ANY (oder Wert) zurückgibt (z.B. als Adresse einer Fundstelle). Man kann auch nicht sehen, ob der Baustein die übergebenen Datenbereiche nur liest oder auch beschreibt.

Ob ein ANY-Parameter ein IN-/OUT-/INOUT-Parameter ist hat nur Einfluß auf die Referenzdaten:
- ANY als IN-Parameter wird als R-Zugriff gewertet
- ANY als OUT-Parameter wird als W-Zugriff gewertet
- ANY als INOUT-Parameter wird als RW-Zugriff gewertet

PS: Ich habe nur FC getestet (ich sehe aber auch keinen Grund, warum es bei FB anders gehandhabt werden könnte).

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich finde das verwirrende kommt ja nur wenn man einen Ausgang von Typ ANY eine Variable vom Typ ANY anlegt, da dann ja nicht in die Varaible sondern in die Daten auf die sie zeigt geschrieben wird. Man kann ja aber an den Ausgang ja auch direkt z.B. eine Symbolische DB Adresse anlegen, und dann schreibt man intern in dem FC ja auf den dort angelegten Zielbereich und es ist so wie man es eigentlich logisch denkt...
 
Wenn das ganze schön gekapselt ist und beschrieben wird und in einem FB oder FC abgeliegt ist, dann bin ich bei euch.

Sollte aber irgendwo im "normalen" Programm wer damit losleegen, dann -> return to Sender.

Das muss so dokumentiert und nachvollziehbar sein, dass auch der Stift im 3. LJ das nachvolziehen kann! (also beim Aufruf des FB ein ausreichender Kommentar was da abläuft!)

Dann bin ich voll bei euch.

Wird das einfach irgenwo im Prog eingebaut mit zu wenig oder gar keinem Kommentar -> return to Sender.

Die Geräte sind langlebig (Wir haben immer noch viel S5 am laufen) und viele Mitarbeiter die eher Schlosser als Programmierer sind. Aber die Leute halten das System am laufen!
 
Wenn das ganze schön gekapselt ist und beschrieben wird und in einem FB oder FC abgeliegt ist, dann bin ich bei euch.

Sollte aber irgendwo im "normalen" Programm wer damit losleegen, dann -> return to Sender.

Das muss so dokumentiert und nachvollziehbar sein, dass auch der Stift im 3. LJ das nachvolziehen kann! (also beim Aufruf des FB ein ausreichender Kommentar was da abläuft!)

Dann bin ich voll bei euch.

Wird das einfach irgenwo im Prog eingebaut mit zu wenig oder gar keinem Kommentar -> return to Sender.

Die Geräte sind langlebig (Wir haben immer noch viel S5 am laufen) und viele Mitarbeiter die eher Schlosser als Programmierer sind. Aber die Leute halten das System am laufen!

Na ja, wenn ich z.Bsp. einen Baustein für die Kommunikation mit einem Scanner erstelle, dann hat der u.a. 2 IN/OUT (Any), die heißen SendString und RCVString und liegen auch genau so in einem DB, werden also symbolisch an den FB geschrieben. Da sollte man nicht mehr viel extra erklären müssen, was damit zu machen ist, denn wer das nicht erkennt, sollte dann doch lieber dir Finger von der SPS lassen. Im Baustein wird dann vom Datenbereich des SendString gelesen und in den Datenbereich des RCVString das empfangene Ergebnis hineingeschrieben. Was soll ich da dann noch als Erklärung schreiben? Im FB steht natürlich, was in dem Netzwerk, in welchem das umkopieren der Any erfolgt, passiert. Aber egal was du da schreibst, der Stift im 3.LJ muß schon sehr gut sein, um das nachzuvollziehen, ich zumindest kenne bisher keinen, da ist manchmal die Prozentrechnung schon der Supergau. ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn das ganze schön gekapselt ist und beschrieben wird und in einem FB oder FC abgeliegt ist, dann bin ich bei euch.

Sollte aber irgendwo im "normalen" Programm wer damit losleegen, dann -> return to Sender.

Das muss so dokumentiert und nachvollziehbar sein, dass auch der Stift im 3. LJ das nachvolziehen kann! (also beim Aufruf des FB ein ausreichender Kommentar was da abläuft!)

Dann bin ich voll bei euch.

Wird das einfach irgenwo im Prog eingebaut mit zu wenig oder gar keinem Kommentar -> return to Sender.

Die Geräte sind langlebig (Wir haben immer noch viel S5 am laufen) und viele Mitarbeiter die eher Schlosser als Programmierer sind. Aber die Leute halten das System am laufen!

Naja, auch wenn das Thema etwas abdriftet. jemand, der die Pointer selten oder nie verwendet, wird ein Programm mit vielen Pointern auch nur selten oder nie verstehen, egal ob er Schlosser oder Ingenieur ist... Nur abundzu hat der Kunde halt komplexe Aufgabenstellungen an das Programm, welche vom Programmierer dann nur sinnvoll mit Pointern gelöst wurden. Würde man das ohne Pointer machen, wärs auch nicht übersichtlicher bzw. sonstige Probleme...

Ich mache viel CFC, selbst da hat man beim Kunden oft die Diskussion "ich kann nur FUP", aber trotzdem will der Kunde ne hohe Funktionalität... DAs passt eben nicht immer zusammen...

Gruß.

PS: Es gibt heute faktisch fast kein Programm mehr, was nur mit UND/ODER/NICHT auskommt.
 
Ich finde das verwirrende kommt ja nur wenn man einen Ausgang von Typ ANY eine Variable vom Typ ANY anlegt, da dann ja nicht in die Varaible sondern in die Daten auf die sie zeigt geschrieben wird.

Verwirrend? Hmm...
Es ist ja genau der Sinn eines Pointers, dass er auf einen anderen Speicherbereich zeigt als auf seinen eigenen. Deshalb sollte man sich immer klar machen das mit einem Pointer ein anderer Speicherbereich gelesen /geschrieben wird (werden kann).
Es ist ein generelles "Problem" (oder auch deren Vorteil) von Pointer, dass man rein an der Schnittstelle ohne Kommentare nicht erkennen kann was mit den Daten passiert auf die gezeigt wird.
Selbst in Hochsprachen wie C werden an Funktionen Pointer übergeben (bei einem FC IN-Parameter) um einen Rückgabewert zu erhalten, da die Funktion selbst nur einen Wert zurückgeben kann.
Wenn das ganze jetzt weiter betrachtet wird, dann erkennt man, das selbst bei einem FC der Programmierer gefordert ist, dass er keinen IN-Parameter beschreibt da dieser ebenfalls nur ein Pointer auf den Speicherbereich ist, der aussen angelegt wurde und somit verändert werden kann.

So ist das nun mal mit Programmiersprachen wo man mit Pointer hantieren kann... alles verwirrend!
 
Zurück
Oben