Übergabe von Datenbereichen in einen Funktionsblocl

Grisu88

Level-1
Beiträge
61
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich hab mal wieder eine Frage :p

und zwar möchte ich einen Funktionsbaustein erzeugen, welcher als Input Variable einen ANY Zeiger für Datentypen und UDTs verarbeiten kann. Irgendwie bekomme ich nur Pointer die ich dann zwar zu Any Zeigern umbauen kann nur fehlt mir dann halt der Wiederholungsfaktor. Ich habe die Input Variable zwar als ANY Datentyp angegeben bekomme aber trotzdem einen Pointer. Mit den UDTs komme ich im moment gar nicht weiter.

Gruß Tim
 
Hallo,
es werden dir für diese Variablentypen (ARRAY, STRUCT, UDT, ANY etc.) generell Pointer erzeugt, die auf die Speicherstelle zeigen an der der Quell-Datentyp (also in deinem Fall der ANY) definiert ist - aslo der daten-Inhalt davon steht.

Gruß
Larry
 
Es wird ja ein Datenbereich vom Typ ANY (z.B.) erzeugt - nur nicht in der Schnittstelle ... dort steht nur wo die Daten (also die Inhalte) des ANY stehen. Du mußt also die 10 Byte des Any (oder die 100 Byte des UDT z.B.) an/ab der Speicherstelle laden, auf die der Pointer zeigt - nicht aber aus dem Pointer einen ANY machen - das wäre falsch ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ich hab mir jedes Byte von den Input Zeigern angeguckt, diese Bytes haben genau die Anordnung die ich versucht hatte nach zubauen :p. Das Problem was aber noch besteht ist das ich die Daten auf die dieser Zeiger zeigt mit BLOCLMOVE (SFC20) in einen Array in der Instanzdatenbaustein laden will. Jedoch bekomme ich da einen Fehler : "Konstantenformat zu datentyp Pointer paßt nicht zu formalen Datentyp Any des Formalparameters SRCBLK". Warum erkennt die Funktion SFC20 nicht das der Eingang ein ANY zeiger ist? Oder hab ich da was falsch verstanden?
 
Ich muß mich erstmal korrigieren ...!!!

Die Aussage, die ich gemacht habe, bezog sich auf die Verwendung dieser Variablen im Bereich IN_OUT eines FB !!!
Auf der IN-Schnittstelle werden die direkt abgebildet. Du kannst da also auch direkt drauf zugreifen.

Jetzt stellt sich mir allerdings die Frage, was du da machst und vor Allem wie du es machst ...
Du hast eine IN-Variable vom Typ UDT1 (z.B.) - was willst du damit denn jetzt machen ? Auf die Einzelelemente zugreifen ? Das ginge dann mit z.B. "U #mein_IN_UDT.dessen_UntervariablenName"

Poste doch bitte mal deinen Code ...

Gruß
Larry
 
okay das mit den Daten lesen hab ich nun so gelöst:

Code:
//**************
//* Zeiger erstellen für die OID ("Z_OID")
//**************

      L     P##OID
      LAR1  
      L     D [AR1,P#0.0]
      T     LD    10
      L     D [AR1,P#4.0]
      T     LD    14
      L     W [AR1,P#8.0]
      T     LW    18

//**************
//* OID im Array "A_OID" speichern
//**************

      CALL  "BLKMOV"                    //Mit dieser Funktion wird der durch den Zeiger markierte Array Bereich
       SRCBLK :=#Z_OID                  //in den Array "A_OID" kopiert
       RET_VAL:=#S_BLKM_COM
       DSTBLK :=DB501.A_OID

mit den UDTs hab ich noch nicht wirklich eine Idee :p. In meinem Funktionsblock ist unteranderem der Funktionsblock FB 65 (erstellt eine Kommunikationsschicht zum Senden von bspielsweise UDP Nachrichten). Dieser Funktionsblock braucht eine UDT mit den Verbindungsparametern (Welche mit Hilfe von OCWizrad erstellt wurde) jetzt ist es möglich in den Instanzdatenbaustein diese UDT zu laden und dierekt auf den FB 65 zu geben. Mein Ziel ist es nun diese UDT in meinen Funktionsblock zuübergeben (welcher zum Beispiel den FB 65 enthält) und den von mir erstellten Funktionsblock diese UDT an den Funktionsblock 65 zuübergeben. Ich hoffe man konnte es nachvollziehen :p
 
Zuviel Werbung?
-> Hier kostenlos registrieren
OK ... jetzt verstehe ich etwas besser ...
Der UDT65, der von dem OC-Wizzard erzeugt wird, ist (wie jeder andere UDT auch) nur eine Vorschrift, die den Aufbau und die Vorbelegung eines noch zu definierenden Speicherbereichs beschreibt. Er ist keine Datenblock sondern wird erst zu einem wenn du ihn irgendwo als Datentyp für eine Variable anlegst. In deinem Fall kannst du also z.B. in deinem DB501 eine Variable anlegen, die vielleicht Connection_Par heißt und vom Typ UDT65 ist. Damit wird die dann korrekt eingestellt und du kannst sie in der Folge verwenden ...
War es das ?
 
Nicht ganz^^ ich möchte wenn das fertig ist diesen Funktionsblock mehrmals mit unterschiedlichen Verbindungspartnern benutzen, d.h. es wird für jeden Verbindungspartner eine andere UDT geben. Mache ich das für eine UDT fest in dem ich im Instanzdatenbaustein, beispielsweise UDT 65, würde die Funktion nur mit dem verbindungspartner von UDT 65 kommunizieren oder? Das wollte ich ja gerade variable machen :p quasi so wie bei dem Funktionsblock 65 selbst, da wird die UDT ja auch als Eingang eingegeben
 
Jetzt verstehe ich dich ...
Das ist aber so eine Sache. Deine unterschiedlichen Connection-Parameter sind ja nicht alle vom Typ UDT65. Der nächste UDT des Wizzard würde jetzt ja ggf. UDT66 heißen - ist zwar gleich aufgebaut, seine Inhalte sind aber anders.
Vielleicht solltest du dir eher einen eigenen UDT bauen, der den Aufbau (aber nicht die Inhalte) beschreibt und den übergeben und die Inhalte entsprechend in den Variablen des Global-DB (in dem du ggf. 5 mal myUDT als Connection_Par1 bis Connection_Par5 deklariert hast) fest zuweisen (entsprechend dem, was der Wizzard erstellt hat).

Konnte ich mich verständlich machen - ich bin da gerade nicht so sicher ... 8)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ähm :p also einen UDT erstellen der genauso aufgebaut ist wie der von OC Wizard aber ohne Werte. Den dann als festen UDT einbauen in den Funktionsblock. Dann verschiedene UDTs (durch OC Wizard erstellt) in einem Datenbaustein legen und diese dann in den FUnktionsblock jeweils überführen??
 
Nicht so ganz ... aber die Richtungs stimmt schon.
Du kannst natürlich nicht einem Baustein, der auf der Schnittstelle einen UDT70 erwartet einen UDT65 übergeben - auch dann nicht, wenn er genau identisch aufgebaut ist.
Aber was ändert sich denn in deinen unterschiedlichen UDT's ? Z.B. die ID, oder die Rem_StAddr ... Diese speicherst du entsprechend ihrer Abweichung in den globalen DB und weißt sie passend zu. Du kannst dann halt nur nicht mehr direkt mit dem von Wizzard erstellten UDT arbeiten sondern "nur noch" mit den jeweiligen Inhalten. Deshalb das Beispiel. Der oben genannte UDT70 entspricht im Aufbau dem UDT65. In deinem Global-DB legst du den so oft an, wie du ihn brauchst und schreibst für jede neue Connection die jweiligen Werte in die Deklaration im DB und läßt den vom Wizzard erstellten UDT sein, wie er will ...
 
hmm wäre es vielleicht auch möglich mit indirekter Adressierung den UDT in der Deklaration zu varrieren? So dass man nur die Nummer des UDTs als Eingang eingibt und diese Nummer dann als UDT nummer setzt? Quasi in der Deklaration UDTx und dann das x aus dem Input holen? Oder ist das jetzt völlig dämlich? xD
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nein ... nicht dämlich ... nur ist ein UDT ja kein Speicherbereich sondern nur eine Vorschrift wie ein Speicherbereich zu verwenden ist ...
Du mußt den UDT erst in (z.B.) einen DB packen um daraus einen Speicherbereich zu erhalten ... (wie schon geschrieben)
 
Ich meinte das die UDT im Instanzdatenbaustein liegt jedoch nicht als UDT65 oder UDT 70 oder was auch immer sondern vllt UDT [AR1.p#0.0] oder so ähnlich oder UDT [MW 10] und diese indirekte Adressierung also den Wert dann als Eingang des Funktionsblocks
 
Ein indirektes Adressieren eines UDT's geht nicht. Das eines verwendeten Speicherbereichs (wo auch immer der sich gerade befindet) natürlich schon ... aber immer nach den schon genannten Regeln ...
 
Dem FB65 (z.B.) übergibst du (im Prinzip als ANY-Pointer) den Speicherbereich in dem der UDT65 als Variable deklariert ist ...
 
ich habe es jetzt so gemacht:

ich übergebe meinem Funktionsbaustein einen ANY Pointer, der auf die UDT zeigt

in meinem Funktionsbaustein bau ich aus dem Pointer (der auf das erste Bit des übergebenen ANY Pointers von der UDT zeigt) einen ANY zeiger und übergebe den dann dem FB 65 :p

klappt eigentlich ganz gut :)
 
Zurück
Oben