Alternative zu BLKMOV

/*Matthias*/

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

ich muss Daten zu einem Profibus/RS-232 Interface senden. Damit es möglichst flexibel bleibt, möchte ich auch Adressen oberhalb des Prozessabbildes verwenden. Leider gibt es dann beim BLKMOV (SFC20) einen Bereichslängenfehler. Gibt es Alternativen zu diesem SFC oder muss ich meine Adressen gezwungenermaßen in das PA legen? :confused:

Dank&Gruß
Matthias
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Teilerfolg...ich kann jetzt auch Peripherieadressen verwenden. Ich habe jetzt allerdings ein neues Problem. Ich möchte 10 Byte Nutzdaten pro Block(i.d.R. Strings) versenden, die ersten 3 Byte brauche ich für´s Protokoll. Also in der HW-Konf. 13 Byte Datenlänge projektiert.
Beim SFC15 muss aber der Quellbereich die gleiche Länge aufweisen wie ich´s bei der Baugruppe projektiert habe und ich schreibe mir dann in die ersten drei Protokollbytes. :cry:
 
Dann nimm die 3 Protokollbytes und schreib sie vorher in den Datenbereich. Anschließend den gesamten Datenbereich übertragen.
 
Alles klar, ich hab' es etwas anders gelöst...zwei Datenblöcke projektiert. Einmal der 3 Byte-Protokoll und danach ein zweiter Block mit den 10 Byte-Nutzdaten.

Besten Dank für eure Hilfe! :rolleyes:

Edit:
Vielleicht könnt mir nochmal kurz auf die Sprünge helfen.
Warum bekomme ich beim Aufruf des SFC15 im FB einen "Ausrichtungsfehler beim Lesen eines Parameters"? Mache ich einen Fehler mit dem Pointer?

Code:
      TAR1  LD   100
      LAR1  P##quell_pointer            // Pointer Quell-Daten
      L     B#16#10                     // Syntax-ID
      T     LB [AR1,P#0.0]
      L     B#16#2                      // Datentyp Byte
      T     LB [AR1,P#1.0]
      L     10                          // Anzahl Byte
      T     LW [AR1,P#2.0]
      L     22                          // Quell-DB
      T     LW [AR1,P#4.0]
      L     2
      SLW   3                           // Byte-Adresse
      T     LD [AR1,P#6.0]
      L     B#16#84                     // Speicherbereich DB
      T     LB [AR1,P#6.0]
      LAR1  LD   100
 
 
      CALL  "DPWR_DAT"
       LADDR  :=W#16#103
       RECORD :=#quell_pointer
       RET_VAL:=#RET_VALUE
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
... das kann ich jetzt auf die Schnelle auch nicht sehen ...
Aber ...
warum schreibst du nicht
Code:
      CALL  "DPWR_DAT"
       LADDR  :=W#16#103
       RECORD :=p##DB22.DBX2.0 Byte 10
       RET_VAL:=#RET_VALUE
...?

Edit: eventuell habe ich beim Pointer ein "#" zuviel drin ...
 
Mit dem Pointer funktioniert es, allerdings muss ich das auch variabel gestalten, da ich den Pointer nach den ersten 10 Byte versetzen muss. Im OB1 zB funktioniert der gleiche Pointer einwandfrei...:confused:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
versuch doch bitte mal folgende Änderung :
Code:
      LAR1  P##quell_pointer            // Pointer Quell-Daten
      L     B#16#10                     // Syntax-ID
      T     LB [AR1,P#0.0]
      L     B#16#2                      // Datentyp Byte
      T     LB [AR1,P#1.0]
      L     10                          // Anzahl Byte
      T     LW [AR1,P#2.0]
      L     22                          // Quell-DB
      T     LW [AR1,P#4.0]
[COLOR=red][B]     L     L#2[/B][/COLOR]
[B][COLOR=red]     SLD   3                           // Byte-Adresse[/COLOR][/B]
[B][COLOR=red]     T     LD [AR1,P#6.0][/COLOR][/B]
      L     B#16#84                     // Speicherbereich DB
      T     LB [AR1,P#6.0]
Gruß
LL
 
Hallo,

die Variable Record ist vom Typ "any" nicht "pointer". Das ist ein kleiner aber feiner Unterschied. Deshalb fehlt noch etwas in deiner Deklaration.

Gruß Hagen
 
Hallo,

die Variable Record ist vom Typ "any" nicht "pointer". Das ist ein kleiner aber feiner Unterschied. Deshalb fehlt noch etwas in deiner Deklaration.

Gruß Hagen

Was fehlt denn? Er nennt ihn zwar "quell_pointer", aber er wird doch als Any mit Daten beschickt. Ich geh mal davon aus, er ist auch als Any definiert, sonst sollte der SFC15 doch meckern.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
versuch doch bitte mal folgende Änderung :
Code:
      LAR1  P##quell_pointer            // Pointer Quell-Daten
      L     B#16#10                     // Syntax-ID
      T     LB [AR1,P#0.0]
      L     B#16#2                      // Datentyp Byte
      T     LB [AR1,P#1.0]
      L     10                          // Anzahl Byte
      T     LW [AR1,P#2.0]
      L     22                          // Quell-DB
      T     LW [AR1,P#4.0]
[COLOR=red][B]     L     L#2[/B][/COLOR]
[B][COLOR=red]     SLD   3                           // Byte-Adresse[/COLOR][/B]
[B][COLOR=red]     T     LD [AR1,P#6.0][/COLOR][/B]
      L     B#16#84                     // Speicherbereich DB
      T     LB [AR1,P#6.0]
Gruß
LL

Glaub nicht das wirklich die Ursache ist, hatte früher auch immer SLW 3 genutzt und erst bei größeren Adressen machte sich der Fehler (richtig ist SLD 3) bemerkbar. Aber der Hinweis ist korrekt und sollte unbedingt beherzigt werden.
 
@Ralle:
Ansonsten konnte ich keinen Fehler erkennen ... Somit konnte ich mir vorstellen, das er als High-Word noch den Rest der letzten Operation hatte. Das würde durch "L L#2" ausgemerzt werden ...
 
Code:
[B][COLOR=#ff0000]L     L#2[/COLOR][/B]
[B][COLOR=#ff0000]SLD   3[/COLOR][/B]
[B][COLOR=red]T     LD [AR1,P#6.0][/COLOR][/B]
L     B#16#84
T     LB [AR1,P#6.0]
Hallo,

falls das nicht zu unflexible ist könntest du auch direkt schreiben:
Code:
L P#DBX2.0
T LD [AR1,P 6.0]

Grüße...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Ralle

Was fehlt denn? Er nennt ihn zwar "quell_pointer", aber er wird doch als Any mit Daten beschickt. Ich geh mal davon aus, er ist auch als Any definiert, sonst sollte der SFC15 doch meckern.

Du hast natürlich recht. Ich habe nicht richtig hingeschaut. Sorry! Kann jetzt erstmal auch keinen Fehler entdecken außer den mit SLD statt SLW.

Eine gute Referenz stellt wie immer der Link auf Volkers Erklärung dar:

http://sps-forum.de/showthread.php?t=12923

Gruß Hagen
 
Erstmal danke...wie schon gesagt ist der pointer natürlich vom typ any.
Die Änderung von SLW in SLD brachte keinen Erfolg. Der Pointer funktioniert im OB auch einwandfrei, aber der gleiche Aufruf in einem FB führt zu diesem Bereichslängenfehler.

Edit:
Ich habe mir jetzt einen eigenen FC zur Übertragung geschrieben, der meine Anforderungen erfüllen kann. Trotzdem müsste es doch möglich sein den any-pointer in einem FB an den SFC zu übergeben...muss man vllt AR2 ins Spiel bringen?
Edit²:
Mein Baustein macht beim Aufruf im FB den gleichen Mist. Er holt sich aus dem übergebene pointer völlig falsche Werte...zB anstatt DB20, DB0...
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Matthias,

wenn du den Any-Pointer im FB über AR1 zusammenstellst, wird das ohne weiteres nicht funktionieren, mit AR2 schon garnicht. Ich vermeide so etwas generell in einem FB.
Siehe auch: Berger-Bibel, Psalm 25.4

Das Einfachste wird sein, du legst dir einen ANY in den temp. Lokaldaten des FB an, schreibst die entsprechenden Daten direkt dort hin und übergibst diesen Any an die SFC bzw. FC.

Oder du übergibst alle Parameter an die FC und bastelst dort daraus einen Any. In der FC muss dann AR1 am Anfang gesichert, und am Ende wieder hergestellt werden, falls es verwendet wird.


Gruß, Onkel
 
mea culpa, mea culpa, mea maxima culpa.
es funktioniert jetzt mit dem pointer...ich hatte durch meine ständigen Änderungen(löschen von variablen usw.) den Datentyp von dem quell_pointer wohl versehentlich in Bool geändert. tut mir echt leid. aber merkwürdigerweise hat der sfc nicht darüber gemeckert.
@Onkel
Ja ich hatte da etwas im Kopf mit any-pointern und multiinstanzen...da wird ja auf den pointer der offset aus dem ar2 addiert.
 
Zurück
Oben