MW
Level-1
- Beiträge
- 1.186
- Reaktionspunkte
- 272
-> Hier kostenlos registrieren
Jetzt habe ich auch mal wieder ein kleines Problem mit einem für mich(kein SCL-Freak) unerklärlichen Verhalten beim Aufruf des FC50 (AG_LRECV).
Ich rufe in einem FC den FC50 auf und will dort immer nur ein Byte aus dem Empfangspuffer des CP's lesen und in anschliesssend in einen String einfügen.
Jetzt zum Problem:
Die gewünschten Daten(7Bytes) werden vom CP empfangen und der AG_LRECV liest sie auch aus, sichtbar wird dies am hochzählen des "REC_LEN".
Im "PUFFER" kommen dabei nur 7 Fragezeichen(CHAR-Wert = 63) an, also der Wert mit dem "tmp_byte" initialisiert wurde, das wirklich empfangene Zeichen, das nach dem Aufruf des AG_LRECV in "tmp_byte" stehen müsste, wird einfach ignoriert.
Jetzt habe ich mir das mal in AWL angesehen, da kommt auszugsweise folgendes raus:
Wieso arbeitet der SCL-Compiler beim Aufruf des CONCAT da mit den Vorgängerlokaldaten, wenn doch das konvertierte empfangene Byte in den aktuellen Lokaldaten abgelegt wurde?
Da ich mir das jetzt nicht erklären konnte, habe ich das "tmp_byte" aus dem oberen Beispiel mal in den INOUT Bereich verschoben, das Initialisieren mit der Zahl 63 weggelassen und die Variable "tmp_byte" von aussen mit einem Byte aus dem STAT-Bereich des aufrufenden FB's belegt. Jetzt landet im "Puffer" immer der Wert den die STAT-Variable "tmp_byte" besitzt, also auch nur Mist.
Wenn ich jetzt allerdings an diese INOUT-Variable ein Byte im Merkerbereich eingebe, funktioniert die ganze Sache auf einmal.
Ich könnte das ganz ja so lassen, sieht aber doof aus ich will jetzt auch wissen woran das liegt bzw. wie ich den Baustein ändern muss damit es auch mit der temp-Variable funktioniert.
Ich rufe in einem FC den FC50 auf und will dort immer nur ein Byte aus dem Empfangspuffer des CP's lesen und in anschliesssend in einen String einfügen.
Code:
VAR_INPUT
ID : INT; //Verbindungs-ID
LADDR : WORD; // Log. Adresse des CP
END_VAR
VAR_IN_OUT
NEW_DAT : BOOL ; // alte Nachricht löschen
PUFFER : STRING[11] ; // Zwischenspeicher der Nachricht
REC_LEN : INT ; // Länge der Empfangenen Nachricht
END_VAR
VAR_TEMP
[COLOR=#ff0000]tmp_byte[/COLOR]: BYTE;
tmp_ndr: BOOL;
tmp_error: BOOL;
tmp_status: WORD;
tmp_len: INT;
tmp_str : STRING[11];
END_VAR
BEGIN
// Temp Initialisieren
[COLOR=#ff0000]tmp_byte[/COLOR]:= 63;
tmp_ndr := FALSE;
tmp_error := FALSE;
tmp_status := W#16#0;
tmp_len := 0;
tmp_str := PUFFER;
IF NEW_DAT THEN // Alte Daten löschen wenn neues Telegramm erwartet wird
NEW_DAT := FALSE;
tmp_str := '';
REC_LEN := 0;
END_IF;
// Daten empfangen
AG_LRECV (ID:= ID,
LADDR:= LADDR,
RECV:= [COLOR=#ff0000]tmp_byte[/COLOR],
NDR:= tmp_ndr,
ERROR:= tmp_error,
STATUS:= tmp_status,
LEN:= tmp_len);
// Empfangenes Zeichen in String einfügen
IF tmp_ndr AND (REC_LEN < 11) THEN
tmp_str := CONCAT (IN1:= tmp_str,
IN2:= BYTE_TO_CHAR([COLOR=#ff0000]tmp_byte[/COLOR]));
REC_LEN := REC_LEN + 1;
END_IF;
// String sichern
PUFFER:= tmp_str;
Jetzt zum Problem:
Die gewünschten Daten(7Bytes) werden vom CP empfangen und der AG_LRECV liest sie auch aus, sichtbar wird dies am hochzählen des "REC_LEN".
Im "PUFFER" kommen dabei nur 7 Fragezeichen(CHAR-Wert = 63) an, also der Wert mit dem "tmp_byte" initialisiert wurde, das wirklich empfangene Zeichen, das nach dem Aufruf des AG_LRECV in "tmp_byte" stehen müsste, wird einfach ignoriert.
Jetzt habe ich mir das mal in AWL angesehen, da kommt auszugsweise folgendes raus:
Code:
L #ID
T LW 20
L #LADDR
T LW 22
L DW#16#10020001
T LD 24
L W#16#0
T LW 28
L DW#16#87000000 [COLOR=#ff0000]// 87 = Vorgänger Lokaldaten - Adresse 0[/COLOR]
T LD 30
UC "AG_LRECV"
P#L 20.0
P#L 22.0
P#L 24.0
P#L 1.0
P#L 1.1
P#L 2.0
P#L 4.0
L #tmp_byte
UD DW#16#FF
L W#16#100
T LW 20
TAK
SLW 8
L LD 20
UD DW#16#FF0000FF
OD DW#16#10000
OD
T LD 20 [COLOR=#ff0000]// Das müsste jetzt das empfangene Byte sein - landet in den aktuellen Lokaldaten Adresse 20[/COLOR]
L W#16#0
T LW 24
L DW#16#87000030
T LD 26
L W#16#0
T LW 30
L DW#16#870000A0 [COLOR=#ff0000]// 87 = Vorgänger Lokaldaten - Adresse 20[/COLOR]
T LD 32
L W#16#0
T LW 36
L DW#16#87000030
T LD 38
UC "CONCAT"
P#L 24.0
P#L 30.0
P#L 36.0
Wieso arbeitet der SCL-Compiler beim Aufruf des CONCAT da mit den Vorgängerlokaldaten, wenn doch das konvertierte empfangene Byte in den aktuellen Lokaldaten abgelegt wurde?
Da ich mir das jetzt nicht erklären konnte, habe ich das "tmp_byte" aus dem oberen Beispiel mal in den INOUT Bereich verschoben, das Initialisieren mit der Zahl 63 weggelassen und die Variable "tmp_byte" von aussen mit einem Byte aus dem STAT-Bereich des aufrufenden FB's belegt. Jetzt landet im "Puffer" immer der Wert den die STAT-Variable "tmp_byte" besitzt, also auch nur Mist.
Wenn ich jetzt allerdings an diese INOUT-Variable ein Byte im Merkerbereich eingebe, funktioniert die ganze Sache auf einmal.
Ich könnte das ganz ja so lassen, sieht aber doof aus ich will jetzt auch wissen woran das liegt bzw. wie ich den Baustein ändern muss damit es auch mit der temp-Variable funktioniert.
Zuletzt bearbeitet: