BLKMOV bei "nicht-konsistenten" Peripherie-Daten?!

[Hawkster]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo allesamt, hätte da mal ne Frage.

Habe mir gedacht wenn SFC14/15 konsistente Daten als block lesen kann, könnte ich doch mit BLKMOV nicht-konsistente Daten von der Peripherie lesen. Leider bekomm ich aber permanent den fehler "W#16#8124", welcher Dokumentiert ist mit "Bereichsfehler beim Lesen eines Parameters"...

Mein Aufruf sieht derzeit wie folgt aus:

      CALL  SFC   20
       SRCBLK :=P#P  1540.0 BYTE 6
       RET_VAL:=#iDummy
       DSTBLK :=P#DB111.DBX 0.0 BYTE 6

Brauch ich hierfür wieder einen anderen SFC? Aber laut der Beschreibung von BLKMOV sollte er es können:

Beschreibung
Mit der SFC 20 "BLKMOV" (block move) kopieren Sie den Inhalt eines Speicherbereiches (= Quellbereich) in einen anderen Speicherbereich (= Zielbereich).
Zulässige Quellbereiche sind:
· Teile von Datenbausteinen
· Merker
· Prozeßabbild der Eingänge
· Prozeßabbild der Ausgänge
Der Quellparameter kann auch in einem nicht ablaufrelevanten Datenbaustein im Ladespeicher liegen (DB, der mit dem Schlüsselwort UNLINKED compiliert wurde)!

Wäre nett wenn jemand eine Idee hätte.

MFG
Hawkster

 

[Rainer Hönle]

Wenn die Hilfe Peripherie nicht direkt erwähnt, liegt es eventuell da dran. Denn das erlaubte Prozessabbild ist nicht gleich Peripherie.

 

[Hawkster]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja gibt es dann eine alternative zum einlesen als "block"? So wie SFC14 halt auf "nicht-konsitenter"-Basis?!

 

[Ralle]

Was genau stört dich am SFC14/15?

 

[Hawkster]

Das ich damit z.b. nur konsistente Einträge einlesen kann. Möchte auch "nicht-konsistente" Daten über einen Block laden.

Hintergrund ist die Symbolische Programmierung. Mit Blockmove kann ich es Symbolisch machen. Wenn ich L-> T L-> T L-> T kann ich nur selten die Symbolik halten.

 

[BHeiser71]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,
habe das selbe Problem!
Hat Step7 in den vergangenen Jahren was dazu gelernt?
Ist es jetzt möglich einen Peripheriebereich "nicht-konsistenter" Daten eines Profibus-DP-Slaves mit einer SFC in einen Datenbaustein zu kopieren?

Bin für jede Hilfe dankbar!

Gruß Burkhard

 

[Larry Laffer]

... die Frage war m.E. beantwortet ...
Du nimmst entweder den SFC14/15 oder du machst es mit L/T entweder Einzeln oder in einer Schleife.

Gruß
Larry

 

[bike]

Was spricht gegen konsistente Datenübertragung?
Die SFC sind doch inzwischen so schnell, dass es keinen Sinn macht über mehrere Zyklen die Daten einzulesen.

Oder ist mir jetzt wieder etwas ausgekommen?


bike

 

[BHeiser71]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich gebe ja zu, dass ich blutiger Anfänger bin, was das Step7 programmieren betrifft, aber etwas habe ich verstanden.

SFC14/15 funktionieren nur, wenn die Daten konsistent über die gesamte Länge vorliegen.
L/T in einem universell verwendbaren FB zu programmieren, ist nicht ganz trivial.

Leider überträgt unser Profibus-DP Slave die Daten laut GSD aber nur kosistent über die Einheit (also pro Byte).
Wenn man die GSD "verbiegt" (um SFC14/15 wieder nutzen zu können) geht der DP-Slave nicht mehr in Betrieb.

Und SFC20 bzw SFC81 arbeiten nicht mit dem Peripheriebereich zusammen.

Was soll ich also tun?

In unserem Fall ist es leider so, dass eine "kleine" SPS schon viele lokale Baugruppen hat und somit die EA-Daten der DP-Slaves im Peripheriebereich "aufschlagen".

Bin auf Eure Vorschläge gespannt.

Gruß Burkhard

 

[volker]

guck mal hier
http://www.sps-forum.de/showpost.php?p=334959&postcount=8

 

[Verpolt]

Hallo,

Wenn man die GSD "verbiegt" (um SFC14/15 wieder nutzen zu können) geht der DP-Slave nicht mehr in Betrieb.

Die GSD-Datei hat ja vorerst nichts damit zu tun, wie du auf den Adressbereich zugreifst.

Zweck der SFC 14

Sie benötigen die SFC 14 "DPRD_DAT", weil Sie mit den Ladebefehlen, die auf die Peripherie bzw. auf das Prozeßabbild der Eingänge zugreifen, maximal vier Bytes zusammenhängend auslesen können.

Selbstverständlich kannst du die Daten mit L/T abholen oder (wenn konsistenz erforderlich) mit SFC14/15. die SFC's holen dir in einem Rutsch die PEW Daten ab (konsistenz). Ob die Daten über den Bus konsistent hin und her huschen steht in der GSD

 

[MSB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die GSD-Datei hat ja vorerst nichts damit zu tun, wie du auf den Adressbereich zugreifst.

Das kannst du dir aber eben nur aussuchen, wenn der Hersteller des Slave, und somit auch der Ersteller der GSD-Datei,
die Konsistenz über die ganz Länge vorgesehen hat.

Sehr schön kannst du das ganze mit einem DP/DP Koppler probieren, der kann nämlich beides,
also Konsistenz über Einheit und über Länge.
Bei der "über Einheit" Variante, kannst du SFC14/15 vergessen, und musst L/T verwenden,
egal ob per Schleife, einzeln oder sonstwie.

Mfg
Manuel

 

[Larry Laffer]

Bei der "über Einheit" Variante, kannst du SFC14/15 vergessen, und musst L/T verwenden, egal ob per Schleife, einzeln oder sonstwie.

@Manuel:
Bist da dir da wirklich sicher ?
Ich habe da jetzt kein definitives Beispiel und muß auch gestehen, dass ich die beiden SFC's eher selten verwende - dennoch habe ich es so in Erinnerung, dass der SFC14 (z.B.) die Daten in einem Rutsch einliest - die Konsistenz spielt hierbei m.E. gar keine Rolle, da das (wie schon gesagt wurde) ja von dem Slave festgelegt wird. Es ist aber nach meiner Meinung nicht so, dass bei bei einem Datenblock von z.B. 20 Byte, der Byte-konsistent ist, den SFC14 nicht verwenden kann - der funktioniert dann trotzdem ...

Gruß
Larry

 

[LargoD]

Bin zwar nicht Manuel, kann das aber bestätigen, weil ich vor ein paar Wochen selbst drüber gestolpert bin.
Du kannst mit SFC14/15 nur in sich konsistente Bereiche einlesen/ausgeben.

Gruß
Erich

 

[HaDi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich kann das auch bestätigen, für Siemens-CPUs !
VIPA-CPUs (jedenfalls die 315SN) sind da weniger päpstlich, da darf die Konsistenz auch "über Einheit" stehen ...

Grüße von HaDi