Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 18

Thema: UDT Array Input an einem FC

  1. #1
    Registriert seit
    18.06.2007
    Ort
    im Loch
    Beiträge
    56
    Danke
    6
    Erhielt 6 Danke für 6 Beiträge

    Daumen runter


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Leute!

    Ich hätte da folgendes Problem:

    Ein UDT1 mit einer Struktur (Dauer,Min,Max,etc..).
    Ein UDT2 das aus einem array [1..10] of UDT1 besteht.
    Einen DB mit 3 UDT2 (Var1,Var2,Var3).

    Einen FC mit einem Formalparameter Input vom Typ UDT2.

    Die Beschaltung erfolgt in der Form DB_NAME.Var2

    Wie kann ich jetzt innerhalb der FC z.B. auf "DB_NAME.Var2[X].Dauer" zugreifen?

    Wobei das Arrayfeld natürlich variabel (X) adressiert werden muss.

    SCL IST VERBOTEN!

    Gehe ich richtig in der Annahme das mir nur registerindirekte Adressierung übrig bleibt?

    Aber wie behandele ich den Inputparameter UDT? So wie Any, oder eher wie Pointer, oder gibts da ein eigenes Format?
    Wenn ja, wäre Toll wenn mir das jemand erklären könnte. Bin sozusagen UDT Greenhorn.
    Step7 Doku hab ich zuhause nicht, und Internet nich am PG.
    Grüße TC
    Die dümmsten Programmierer haben die dicksten Programme.
    Zitieren Zitieren UDT Array Input an einem FC  

  2. #2
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.788
    Danke
    398
    Erhielt 2.414 Danke für 2.010 Beiträge

    Standard

    Hallo,
    der UDT wird dem FC wie ein ANY-Pointer übergeben.
    Du könntest nun innerhalb des FC im TEMP-Bereich den UDT nachbilden und den Übergabe-UDT (z.B. via Blockmove) auf den TEMP-UDT kopieren und dann absolut auf die Einzel-Bestandteile zugreifen.
    Wenn du inhaltlich etwas änderst, dann bleibt dir allerdings im Anschluß nur die Möglichkeit, die Daten wieder auf den externen Bereich zurück zu kopieren.

    Für die ARRAY-Adressierung bleibt die (außer du arbeitest mit festen Indexen) dann nur die Möglichkeit, die über indirekte Adressierung zu lösen.

    SCL wäre hier also schon eine feine Sache ... aber das hast du im Vorfeld ja ausgeschlossen ...

    Gruß
    LL

  3. Folgender Benutzer sagt Danke zu Larry Laffer für den nützlichen Beitrag:

    TagebauCoder (24.09.2009)

  4. #3
    Registriert seit
    18.06.2007
    Ort
    im Loch
    Beiträge
    56
    Danke
    6
    Erhielt 6 Danke für 6 Beiträge

    Standard

    Danke für die Antwort.

    Absolut auf den Temp bereich zuzugreifen halte ich für ganz furchtbar. Wenns irgendwie geht vermeide ich das.
    Im Aspekt der Wiederverwendbarkeit werde ich den Any zerpflücken, und dann mit AR' arbeiten.
    War da nich irgendwas mit AR1 in FC's? Wird irgendwie für Input-Parameter verwendet oder so. Oder beim zugriff auf zusammengesetzte Datentypen zerschossen?
    Weiss nur noch das AR2 Problem bei FB's die als Multiinstanz laufen.
    Muss ich mit AR1 irgendwas beachten?

    mfg TC
    Die dümmsten Programmierer haben die dicksten Programme.

  5. #4
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.260
    Danke
    537
    Erhielt 2.707 Danke für 1.956 Beiträge

    Standard

    Zitat Zitat von TagebauCoder Beitrag anzeigen
    Danke für die Antwort.

    Absolut auf den Temp bereich zuzugreifen halte ich für ganz furchtbar. Wenns irgendwie geht vermeide ich das.
    Da hast du Larry falsch verstanden, er wollte die Daten per Blockmove (Anyzeiger) in den Temp-Bereich kopieren, auf eine dort vorher erstellte Stucktur/UDT. Auf diese hätte man dann schön bequem über die Temp-Variablennamen zugreifen können. Aber auch da kann auf Arrays nicht per variablem Index zugreifen, das hat er ja auch geschrieben. Bleibt dir wirklich nur der weg über indir. Adressierung. Also mit dem AR1 wäre mir gerade nichts bedeutendes bekannt. Das AR2 enthält bei Multiinstanzen tatsächlich den Offset zu den Daten der Instanz. Wenn du mit ind. Adressierung arbeitest und einen Multiinstanzfähigen Baustein programmieren willst, brauchst du das zwingend! Sieh dich hier im Forum um, da gibt etliches zu dem Thema. Stichwort "Multiinstanz" würde ich zuerst mal probieren. Oder du sagst von vornherein, der Baustein wird nie als Instanz in einem anderen FB deklariert, dann geht es ohne den Offset im AR1, der ist dann eh Null.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  6. Folgender Benutzer sagt Danke zu Ralle für den nützlichen Beitrag:

    TagebauCoder (24.09.2009)

  7. #5
    Registriert seit
    15.01.2005
    Ort
    In der Mitte zwischen Bayreuth/Weiden
    Beiträge
    6.752
    Danke
    323
    Erhielt 1.526 Danke für 1.286 Beiträge

    Standard

    Nicht das ich jetzt eine bessere Lösung hätte,
    aber welcher Volltrottel verbietet für sowas SCL?

    In SCL hat man bei sowas wenigstens die Aussicht das was halbwegs nachvollziehbares rauskommt,
    in AWL ist das ein Zeiger-Pointer gewurschtel bei dem keine Sau jemals wieder so wirklich durchblickt.

    Mfg
    Manuel
    Warum denn einfach, wenn man auch Siemens einsetzen kann!

    Wer die grundlegenden Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu bekommen, verdient weder Freiheit noch Sicherheit (B. Franklin).

  8. #6
    Registriert seit
    18.06.2007
    Ort
    im Loch
    Beiträge
    56
    Danke
    6
    Erhielt 6 Danke für 6 Beiträge

    Standard

    Der Volltrottel der das verbietet ist Siemens. Details per PN.
    Aber SCL habe ich wg. solchen Antworten von vornherein ausgeschlossen.

    Gerade das AR1 Prob bei FC's in den S7-Pro3 unterlagen (K4,S13) gefunden:

    "Bei Zugrffen auf Parameter in FC's wird das AR1 und das DB-Register überschrieben, wenn die Parameter vom zusammengesetzten Datentyp sind."
    FETT MARKIERT IN DEN UNTERLAGEN

    Und das ist verdammt bedeutend. Jetzt weiß ich warum sich ein Wert in einem völlig anderem DB änderte, der mit der Sache so gut wie nix zu Tun hatte, aber an einem Input Parameter verwendet wurde.


    Also in ner FC nach möglichkeit AR2 verwenden.

    Bei nem FB ist es umgekehrt, da ist Vorsicht mit AR2 und DI geboten. Außer bei INOUT Parametern, da is AR1 auch gefärdet, bzw. der INOUT Parameter, wenn er von z.g. Datentyp ist.

    @Ralle Das AR2 Prob in FB's kenne ich genauestens. (TAR2 , L DINO blablabla). Danke für den Hinweis.

    Danke

    mfg TC
    Geändert von TagebauCoder (23.09.2009 um 21:56 Uhr)
    Die dümmsten Programmierer haben die dicksten Programme.

  9. #7
    Registriert seit
    29.03.2004
    Beiträge
    5.793
    Danke
    144
    Erhielt 1.706 Danke für 1.238 Beiträge

    Standard

    Zitat Zitat von TagebauCoder Beitrag anzeigen
    Gerade das AR1 Prob bei FC's in den S7-Pro3 unterlagen (K4,S13) gefunden:

    "Bei Zugrffen auf Parameter in FC's wird das AR1 und das DB-Register überschrieben, wenn die Parameter vom zusammengesetzten Datentyp sind."
    FETT MARKIERT IN DEN UNTERLAGEN

    Und das ist verdammt bedeutend. Jetzt weiß ich warum sich ein Wert in einem völlig anderem DB änderte, der mit der Sache so gut wie nix zu Tun hatte, aber an einem Input Parameter verwendet wurde.
    Könntest du das mal näher erläutern wann da was passieren soll?
    Gibt es diese Unterlagen irgendwo bei Siemens zum Download?

  10. #8
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.260
    Danke
    537
    Erhielt 2.707 Danke für 1.956 Beiträge

    Standard

    Zitat Zitat von TagebauCoder Beitrag anzeigen
    "Bei Zugrffen auf Parameter in FC's wird das AR1 und das DB-Register überschrieben, wenn die Parameter vom zusammengesetzten Datentyp sind."
    FETT MARKIERT IN DEN UNTERLAGEN

    Und das ist verdammt bedeutend. Jetzt weiß ich warum sich ein Wert in einem völlig anderem DB änderte, der mit der Sache so gut wie nix zu Tun hatte, aber an einem Input Parameter verwendet wurde.
    Ah, ich erinnere mich, danke für den Hinweis. Ich hatte das auch schon mehrfach und hab mir daher angwöhnt, vor Aufrufen von Variablen direkt aus einem DB diesen erstmal wieder zu öffnen. Das AR1 beschreibe ich vor Verwendung mit einem gespeicherten Wert, falls nötig. Aber ich finde das eigentlich erschreckend, ich mache das schon aus Routine und weiß schon gar nicht mehr warum.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  11. #9
    Registriert seit
    18.06.2007
    Ort
    im Loch
    Beiträge
    56
    Danke
    6
    Erhielt 6 Danke für 6 Beiträge

    Standard



    • Zu AR1: Der STEP 7-Editor verwendet das Adressregister AR1, um auf zusammen*gesetzte Bausteinparameter zuzugreifen. Innerhalb von Funktionen werden bei allen symbolischen Zugriffen auf alle Bausteinparameter vom Typ ARRAY oder STRUCT die Register AR1 und DB überschrieben.Ebenso werden bei Zugriffen auf Durchgangsparameter vom Typ ARRAY oder STRUCT innerhalb eines FBs die Register AR1 und DB überschrieben.Symbolische Zugriffe auf temporäre Variable eines FBs oder einer FC über*schreiben weder das AR1 noch das DB-Register.


    • Zu AR2: Der STEP 7-Editor verwendet für den symbolischen Zugriff auf Instanzdaten, d.h. auf alle Parameter und auf die statischen Variablen eines FBs, die bereichsinterne, registerindirekte Adressierung. Das DI-Register enthält dabei die Nummer des Instanz-DBs und das Adressregister AR2 den Adressversatz des Instanz-Datenbereichs innerhalb des Multiinstanz-DBs.

    Nach einem Überschreiben dieser Register DI und AR2 darf kein Zugriff auf die Instanzdaten erfolgen, wenn nicht die Inhalte dieser beiden Register wiederher*gestellt werden. Wenn Sie innerhalb eines FBs das Register AR2 oder DI für eigene Zwecke nutzen wollen, dann empfiehlt sich folgende Vorgehensweise:
    1.Sichern Sie die Inhalte von D1 und AR2 in Variablen vom Typ DWORD:
    TAR2 #AR2_REG // Speichern von AR2 in temp. Variable #AR2_REG
    L DINO // Lade Inhalt von DI in AKKU1
    T #DI_REG // Speichere in temp. Variable #DI_REG
    2.Verwenden Sie das DI- und das AR2-Registers für eigene Zwecke. Während dieses Abschnitts darf kein Zugriff auf die Parameter oder die statischen Variablen des FBs erfolgen.
    3.Stellen Sie den ursprünglichen Inhalt des DI- und des AR2-Registers her:
    LAR2 #AR2_REG // Laden des AR2 mit Inhalt von #AR2_REG AUF DeDI_REG] // Wiederherstellen des 01-Registers
    Jetzt kann wieder symbolisch auf die Parameter und stat. Variablen des FBs zugegriffen werden.



    Gibts natürlich nicht zum Download, ist auch als gebundene Ausgabe, Scannen is also eher schlecht.

    mfg TC
    Die dümmsten Programmierer haben die dicksten Programme.

  12. #10
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.788
    Danke
    398
    Erhielt 2.414 Danke für 2.010 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    ... um wieder zum eigentlichen Thema zurück zu kommen ...
    Wenn die SCL-Variante gar nicht in Frage kommt und das Kopieren in den TEMP-Bereich des FC (wie schon von Ralle und mir ausgeführt) auch nicht die Lösung ist, das wirst du nicht um das AR-gewurschtel (wie von MSB so schön ausgeführt) herumkommen. Ob dabei dann aber ein handelbares Programm herauskommt (das man auch noch durchblicken kann) möchte ich dann dochh mal dahingestellt sein lassen ...

    Aber ... mich würde auch interessieren, warum SCL tabu ist - ich verspreche auch, dass ich dann nicht mehr weiter darauf herum reite ...

    Gruß
    LL

Ähnliche Themen

  1. Antworten: 18
    Letzter Beitrag: 21.12.2016, 17:03
  2. Einem INPUT in SCL etwas zuweisen
    Von Bensen83 im Forum Simatic
    Antworten: 8
    Letzter Beitrag: 06.03.2011, 09:34
  3. Probleme mit einem Array
    Von Hitschkock im Forum CODESYS und IEC61131
    Antworten: 7
    Letzter Beitrag: 30.03.2009, 11:42
  4. Antworten: 4
    Letzter Beitrag: 18.03.2009, 16:12
  5. LOGO! CPU Analog Input / Digital Input
    Von Anonymous im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 24.11.2005, 05:55

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •