SFC14 Fehler bei unterschiedlicher Länge von E/A Daten

[ChrissT]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich verstehe es einfach nicht. Mache jetzt seit 2 Stunden an diesem SFC 14 rum.
Ich benutzte den Baustein mehrfach in einem FB in SCL geschrieben. Ich hatte noch nie Probleme irgendwelche Daten in den E oder A Bereich zu kopieren. Ich weiss also wie ich mit dem Baustein umgehen muss und wie er eigentlich funktioniert.

Das ist meine Hardwarekonfig (siehe Bild)


und das mein Aufruf:

VAR
safety_test: ARRAY[0..31] OF BYTE;
END_VAR

error := DPRD_DAT(LADDR:=INT_TO_WORD(32), RECORD=>safety_test);

Das hat bis jetzt immer funktioniert!
Als error bekomme ich immer 16#80B1. Also das etwas mit der Länge nicht stimmt?
Bei allen anderen Aufrufen sind die E/A Adressbereiche gleich lang! Kann es daran liegen?

Für Tipps wie ich das debuggen kann oder gelöst bekomme wäre ich sehr dankbar.

Grüße
Chris

 

[RONIN]

Die ungleichen EA-Längen sind egal. Die parametrierten Längen schauen OK aus.
Was aber ein Problem sein kann (bringt glaub ich auf Fehler 80B1) ist wenn das von dir in der Hardware-Konfig verwendete Modul Daten-Konsistenz unterstützt.
Die SFC14/15 erlauben nur Module mit Datenkonsistenz.

 

[ChrissT]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

Danke für die Antwort. Habs nur nicht ganz verstanden
Will der SFC14 Datenkonsistenz oder nicht?
Kannst du mir vielleicht sagen wie ich herausfinden kann ob die Daten konsistent sind?

Gibt es dazu eine Alternative? Kann man sonst noch in SCL irgendwie die Daten aus dem Eingangsdatenbereich kopieren bei der die Datenkonsistenz keine Rolle spielt?

 

[MSB]

Also der SFC14 will Datenkonsistenz über die ganze Länge (nicht nur über die Einheit) ... das ist unumgänglicher Fakt, das steht bei Step7 überlicherweise in den Moduleinstellungen (wo du auch die E/A Adresse vorgibst). Was hast du da für ein Modul vor dir? Hersteller/Typ/GSD?
Bei manchen Sachen wie DP/DP Koppler ist das einstellbar, bei anderen Sachen ist das vom Gerätehersteller vorgegeben.

2.te Möglichkeit (notfalls mit Prozessabbild vergrößern):
Einfach SFC20/BLKMOV verwenden.

Mfg
Manuel

 

[ChrissT]

Hallo!

Jap, das wars. Ist nur Byte-Konsistent! Hast du eben ein Beispiel für BLKMOV?
Danke!

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast du eben ein Beispiel für BLKMOV?

Einfach BLKMOV mit "P#E 32.0 BYTE 32" am SRC Eingang.
Dafür muss der Eingangsbereich aber innerhalb des Prozessabbildes sein (Zugriff auf EW und nicht PEW) sein.
Das ist aber mit 32 eh gegeben.

 

[ChrissT]

Hallo,

vielen Dank nochmal! Meinst du so?

TYPE AnyPointer
    STRUCT
        ID      : BYTE;
        TYPE    : BYTE;
        Count   : INT;
        DB      : WORD;
        Pointer : DWORD;
    END_STRUCT
END_TYPE

VAR_INPUT
    DB_Num : INT;
END_VAR

VAR
    dest: AnyPointer;
    dest_any AT dest: ANY;
    error : INT;
END_VAR

dest.ID      := 16#10;
dest.TYPE    := 16#02; // Byte
dest.COUNT   := 16#20; // 32
dest.DB      := INT_TO_WORD(DB_Num);
dest.Pointer := DW#16#84000000;

    error := SFC20(srcblk:=P#E 32.0 BYTE 32, dstblk:=dest_any);

Funktioniert so oder?
Zum testen könnte ich doch auch ersteinmal so schreiben:

Für DB10 und Offset 64

   error := SFC20(srcblk:=P#E 32.0 BYTE 32, dstblk:=P#DB10.DBX64.0 BYTE 32);

 

[Onkel Dagobert]

.. Dafür muss der Eingangsbereich aber innerhalb des Prozessabbildes sein (Zugriff auf EW und nicht PEW) sein.
Das ist aber mit 32 eh gegeben.

Zumindest kann man das vermuten. Das ist übrigens ein weiterer Grund, weshalb es mit der SFC14/15 nicht funktioniert. Die SFC14/15 verlangen nach konfigurierten Peripherieadressen mit Datenkonsistenz über den gesamten Bereich.