Problem mit sfc20

gustave

Level-1
Beiträge
22
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
hallo,

warum kann ich nur 32 byte mit dem sfc20 kopieren??
ich denk es gibt keine begrenzung? ich will eigentlich 56byte kopieren, aber der schlingel kopiert eben nur 32, obwohl ich auch 56Byte in den zeiger schreib.

liegts vielleicht an der cpu (315 2DP)??

gruss
gustave
 
Hallo gustave,

was sag denn der RET_VAL?

Stell doch auch mal Deinen Aufruf des SFC 20 hier rein.

Grüße
Gebs
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
ich habs auch mal mit dem sfc81 probiert. das gleiche!


CALL "UBLKMOV"
SRCBLK :=P#DB32.DBX62.0 BYTE 56
RET_VAL:="RFID Lesen".RET_VAL1
DSTBLK :=P#DB101.DBX0.0 BYTE 56


steh ich auf dem schlauch?????

ret_val = 0
 
liegts vielleicht an der cpu (315 2DP)??
Hallo gustave.

Nein, an der CPU liegt es nicht.
Kann es sein das nach den 32 Byte die kopiert werden, Zeiten oder Zähler kommen?
Denn die können lauft Hilfe mit dem UBLKMOV nicht kopiert werden.
Probiere doch mal den normalen BLKMOV ( SFC 20 ).

@Edit : Mein Beitrag ist Schwachsinn, in Deinem ersten Post hast Du ja schon den SFC 20 verwendet.
 
Zuletzt bearbeitet:
Hallo gustave,

ist der Any-Pointer an SRCBLK tatsächlich genau so geschrieben: P#DB32.DBX62.0 BYTE 56 oder
steht bei Dir da was symbolisches und Du hast das nur für Deinen Forums-Beitrag so geschrieben?
Ist der Quellbereich DB32.DBB62 eventuell als STRING[54] deklariert?

Zitat aus der SFC20-Hilfe:
Ist die Quelle ein String, werden maximal nur die aktuell im String enthaltenen
Zeichen kopiert. Sind Quelle und Ziel jeweils ein String, wird die aktuelle Länge auf
die Anzahl der kopierten Zeichen gesetzt.

Falls Sie einen String incl. maximaler und tatsächlicher Länge kopieren wollen,
gehen Sie wie folgt vor: Bauen Sie sich die ANY-Pointer, die Sie bei den
Parametern SRCBLK und DSTBLK angeben, selbst auf. Verwenden Sie für den
Datentyp BYTE.

Du kannst ja auch mal probieren: P#DB32.DBX62.0 WORD 28

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
servus harald,

ich hab den pointer genau so geschrieben und die quelle ist kein string.
ich hab auch schon mit word aufgerufen, auch nichts.

auch meine quelle geht bis dw118.
:confused:

gruss
gustave
 
Moin Moin gustave

Ich glaube nicht, daß der SFC20 weniger als die angegebenen 56 Byte kopiert, wenn der RET_VAL = 0 ist.
Möglicherweise wird der SFC20 gar nicht aufgerufen oder DB101.DBB32 bis DBB55 werden noch woanders im Programm oder
von einem vernetzten Teilnehmer (z.B. HMI) überschrieben.

Kopiere mal nach dem SFC20 die letzten 24 Byte mit L/T. Haben dann DB101.DBB32 bis DBB55 den erwarteten Inhalt?
Code:
// für Kontrolle, ob SFC20 überhaupt was tut
L  DW#16#31323334  //'1234'
T  DB101.DBD0
T  DB101.DBD52
T  "RFID Lesen".RET_VAL1

CALL SFC20
 SRCBLK :=P#DB32.DBX62.0 BYTE 56
 RET_VAL:="RFID Lesen".RET_VAL1
 DSTBLK :=P#DB101.DBX0.0 BYTE 56

// für Kontrolle, ob DB101 später von woanders überschrieben wird
L  DB32.DBD94
T  DB101.DBD32

L  DB32.DBD98
T  DB101.DBD36

...

L  DB32.DBD114
T  DB101.DBD52
Ich würde "zur Sicherheit" die DB32 und DB101 einfach nochmal in die CPU übertragen.
Wenn DB32 und/oder DB101 Instanz-DB (!) sind, dann wurden schon unerklärliche Phänomene beobachtet.

Hast Du eventuell Diagnosepuffer-Einträge, die auf Programm-Probleme deuten könnten?

Kannst Du Dein Programm testweise so ändern, daß im OB1 nur der SFC20 aufgerufen wird und dann Schritt für Schritt
die Programm-Calls wieder aktivieren?

Harald
 
ich habs auch mal mit dem sfc81 probiert. das gleiche!


CALL "UBLKMOV"
SRCBLK :=P#DB32.DBX62.0 BYTE 56
RET_VAL:="RFID Lesen".RET_VAL1
DSTBLK :=P#DB101.DBX0.0 BYTE 56


steh ich auf dem schlauch?????

ret_val = 0

1. Dein "RFID Lesen".RET_VAL1 ist ja global. Verwendest du den evtl. öfter im Programm (überbügelst ihn also irgendwo) und beobachtest Du das ganze mit einer Variablentabelle? Dann wäre klar, warum der Wert Null ist.

2. Ohne jetzt nachzugucken, aber ich glaube der UBLKMOV geht sowieso nicht auf einer 300er. Bringt dir also keine neuen Erkenntnisse. Dann hättest du aber auf jeden Fall Diagnosepuffer-Einträge. Was sagt der Puffer? Alle anderen Tests mach mal - wie schon geschrieben - mit dem SFC20.

Gruß,
Flinn
 
Zuletzt bearbeitet:
Nö ... vom Grundsatz her nicht. Es kommt natürlich darauf an, ob die gewünschten Daten zum Startzeitpunkt des SCF20 auch drin stehen.
Hast du den Vorschlag von Harald (Betrag #10) schon ausprobiert ?

Gruß
Larry
 
meine quelle ist ein instanz db. kann das problem davon kommen????
Das dürfte zwar nicht sein, es kommt aber vor.
Du wärst nicht der Erste, der unerklärliche Probleme mit nicht aktuellen IDB hat.
Ich würde "zur Sicherheit" die DB32 und DB101 einfach nochmal in die CPU übertragen.
Wenn DB32 und/oder DB101 Instanz-DB (!) sind, dann wurden schon unerklärliche Phänomene beobachtet.
Ein neu-Erstellen des IDB DB32 und übertragen in die CPU könnte Dein Problem lösen.
Beachte, daß dabei die Werte im DB32 auf die Anfangswerte initialisiert werden.
Mache Dir VORHER Gedanken, wie Du die Aktualwerte sicherst und danach wieder herstellst, falls Du die beibehalten mußt.
Du kannst das Ganze auch noch vorher in PLCSIM testen.

Du kannst Dir auch mal die Baustein-Konsistenzprüfung anschauen.

Ich hoffe, Du weißt, daß solcherart Querzugriffe auf IDB total verpönt sind und hast einen zwingenden Grund dafür.

Gruß
Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
servus,

der instanz db stellt mir die daten zur verfügung und ich will diese in einen
anderen db wegschreiben.

ich hab die beiden db´s weggelöscht und nochmals neu generiert und siehe da, es funzt.

ich bedanke mich nochmal recht herzlich bei allen, die mir geholfen haben!!!
:TOOL:

es ist schön, dass man mit seinen problemen nicht allein ist.


gruss
gustave
 
Zurück
Oben