SFC 14 / 15 aufs neue

matziane

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

entschuldigung, dass ich ein neues Thema dazu eröffne, bin in den bestehenden nicht fündig geworden.
Bzw. wollte ich nicht in einem Thema bei dem das Problem noch nicht gelöst war drin rum wurschteln.
So genug gerchtfertigt, mal langsam aufn Punkt kommen.

Habe vor um Daten konsistent zu einem PB Teilnehmer auszutauschen, die SFC 14 / 15 zu nutzen.

Habe im TEMP Bereich einmal eine 4 Byte lange Struktur SEND_DATA für den zu sendenden Bereich erstellt und eine 14 Byte lange Struktur READ_DATA für den zu empfangenden Bereich.

Das Senden scheint auch zu funktionieren, jedenfalls bekomm ich da am RET_VAL eine 0, heisst für mich erfolgreich ausgeführt.

Beim Empfangen bekomme ich eine w#16#8090.
· Für die angegebene logische Basisadresse haben sie keine Baugruppe projektiert, oder
· Sie haben die Einschränkung über die Länge der konsistenten Daten nicht beachtet, oder
· Sie haben die Anfangsadresse im Parameter LADDR nicht hexadezimal
angegeben.

Zu Punkt 1, kann ja nicht sein, da das Senden funktioniert hat und die Basisadresse die selbe ist.
Zu Punkt 2, kann eigentlich auch nicht sein, da in meiner Struktur die 14 Byte drin stehen, so wie es sein soll.
Bin mir auch sicher das es 14 Byte sind, steht so in der Dokumentation.
Zu Punkt 3, ich wüsst nicht was daran falsch sein soll.
L #GEN_ADDR_P
LAR1
SRW 3
T #ADDR_DP

CALL "DPRD_DAT"
LADDR :=#ADDR_DP
RET_VAL:=#ERROR
RECORD :=#READ_DATA

Was kann das Problem für den Fehler sein, hat jemand von euch eine Idee?
 
Sfc

Hallo,

hast du denn auch in der HW-Konfig 14 Bytes deklariert? Und wofür ist das:

L #GEN_ADDR_P
LAR1
SRW 3
T #ADDR_DP

Enthält GEN_ADDR_P auch die Bitadresse? Für z.B. Adresse 256 müsste dort einfach eine W#16#100 ran.

André
 
Jup so ist es, hatte vorher noch mal geschaut ob das mit dem Peripherieadresse durch das SRW3 richtig funktioniert.
Im Adressregister 1 steht ja die Peripherieadresse, die wird dann zurechtgeschoben und in die Variable geschrieben.

Sieht vielleicht etwas verwirrend aus, wozu die Peripherieadresse in das Adressregister, wenn er mittels SFC 14 kommuniziert.
Steht noch von den Anfängen so da, als ich die Werte direkt an die PAWs geschrieben und von den PEWs gelesen hatte, da brauchte ich sie im Adressregister.

Kann jetzt eigentlich raus, wenn das mit dem SFC funktioniert.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich schliesse mich da Andre an ...
wenn in GEN_ADDR_P z.B. 400 drin steht und das die in der HW-Konfig eingetragene Perepherie-Adresse ist, dann kannst / mußt du die so an den SFC übergeben. Das SRW 3 bewirkt ein multiplizieren mit 8 und ergibt so einen Bereich, den du vermutlich nicht hast.
Der SFC erwartet allerdings die Adresse im WORD-Format - keine Ahnung warum (ist nämlich eigentlich Quatsch). Dehalb mußt du jedenfalls eine als WORD deklarierte Variable oder einen entsprechenden Datentyp da übergeben ...

Gruß
LL
 
Hab grad mal um sicher zu gehen in die Steuerung reingschaut, bei GEN_ADD_P steht die 24064, passig um es ins Adressregister zu laden.
Teile ich das durch 8, bzw. nach dem SRW3 steht da die 3008 was der Peripherieadresse meiner Baugruppe entspricht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Andre:
SRW nicht SLW ... noch besser - aber du hast ja Recht ...

@matziane:
2 Sachen :
Warum teilst du da durch 8 bzw. warum steht da so einer hoher Wert drin ?
Du weißt schon, dass du dann auch schnell an die INT-Grenze kommst (32767) - aber da geht der Schuß (im wahrsten Sinne des Wortes) nach hinten los ...

Gruß
LL
 
Guten Morgen,

habe eben mit dem Siemens Support telefoniert, es liegt an der Hardwarekonfiguration.
Hier mal der Auszug der GSD Datei.

Module= "Output 4 byte-module consistent" 0xA3
EndModule
Module= "Input 14 bytes" 0x1d
EndModule

Das 4 byte Modul ist konsistent projektiert, weshalb das senden auch funktioniert.
Jedoch ist das 14 byte Modul nicht konsistent projektiert, weshalb das empfangen nicht funktioniert.

Liegt nun bei mir, mit dem Hersteller zu sprechen ob eine Änderung der GSD Datei möglich ist um die Daten konsistent senden zu können.
Oder ich mir einen anderen Weg ausdenken muss.

Direkt das Laden von den Peripherieeingangsadressen ist mir persönlich zu unsicher, da mir dann in eventuell Weck OBs reinfunken und die Daten durcheinander ankommen.

Ich danke euch bis hierhin erstmal für eure Hilfe
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Module= "Input 14 bytes" 0x1d
EndModule

Hallo,
je nach verwendeter HW und/oder SW wird dir die Gegenseite möglicherweise keine Konsistenz über den ganzen Bereich herstellen können.
Ich sehe da aber kein Problem die Daten PxD-weise (z.B.) vom Bus abzuholen ... mache ich bei verschiedenen Anwendungen, die ich habe auch so - ohne je Probleme gehabt zu haben ...

Gruß
LL
 
Zurück
Oben