Step 7 ANYBUS Communicator CAN - auslesen (SFC14)

[showmewhatUgot]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich versuche momentan die Werte von einem Anybus Communicator CAN (AB7312) auszulesen bzw. in einen DB zu übertragen. Leider komme ich nicht voran.
Zum Auslesen benutze ich den SFC14. Ich vermute, dass der Fehler mit der Größe zu tun hat. Der Anybus hat Input 32 words (Output 4 words) und so wie es verstehe kann der SFC14 nur 4 Bytes "auf einmal" auslesen. Kann mir da jemand mit einem Denkanstoß weiter helfen? Danke!

 

[PN/DP]

so wie es verstehe kann der SFC14 nur 4 Bytes "auf einmal" auslesen

Im Gegenteil - den SFC14 MUSS man verwenden, wenn 3 oder mehr als 4 Bytes auf einmal gelesen werden müssen.

Ich vermute, dass der Fehler mit der Größe zu tun hat.

Du musst nicht vermuten... Welchen Fehlercode bekommst Du am RET_VAL?
Wie sieht die HW Konfig (Steckplätze, EA-Adressen, Konsistenz der Module) des Profibus-Slaves aus?
Liegen die EA-Adressen im Prozessabbild PAE/PAA?
Welche SPS-CPU verwendest Du? Und welchen Profibus Master?
Wie sieht der Aufruf der SFC14 im Programm aus?

Harald

 

[showmewhatUgot]

Zuviel Werbung?
-> Hier kostenlos registrieren

RET_VAL gibt mir NULL aus.

 

[showmewhatUgot]

Die Verbindung ist da, aber sobald die Brille angezogen wird, sind alle Werte auf 0
Die beiden SFC weden in im OB1 aufgerufen.

 

[PN/DP]

SFC14 DPRD_DAT: Dein RECORD ist ein bisschen sehr kurz um 32 Words zu speichern...
Aus der Hilfe zum SFC14:

RECORD : Zielbereich für die gelesenen Nutzdaten. Er muß genauso lang sein, wie Sie für die selektierte Baugruppe mit STEP 7 projektiert haben. Es ist nur der Datentyp BYTE zulässig.

Das Gleiche gilt auch für SFC15, da ist auch falsche Länge und falscher ANY-Typ.

PS: und MW11 überlappt mit MW10 --> Tip: immer nur MW auf geraden Adressen verwenden

Harald

 

[showmewhatUgot]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich habe es jetzt am SFC14 auf BYTE 64 (Input laut projektierung 32 words E282-345 angepasst. Jetzt gib er 80b1 aus :

Die Länge des angegebenen Zielbereichs ist ungleich der mit STEP 7 projektierten Nutzdatenlänge.

am SFC 15 genau das selbe, allerdings wenn ich BYTE 4 lasse dann gibt er keinen Fehler aus.
Ich habe mich irgendwie verfahren, danke ich mal.

 

[showmewhatUgot]

mir ist auch aufgefallen, dass im DB viele Adressen als Reserve angelegt wurden, kann es sein, dass er deswegen mekert, sprich es muss die Größe angegeben werden die auch tatsächlich beschrieben wird und die reserve darf nicht berücksichtigt werden?

 

[PN/DP]

Ich wiederhole und präzisiere meine Fragen:
Wie ist die Konsistenz der Module in den Steckplätzen 1 und 2 eingestellt?
Liegen die EA-Adressen im Prozessabbild PAE/PAA?

Hintergrund:
Mit SFC14/SFC15 muß man die je Modul eingestellte Länge lesen/schreiben. Wenn die Konsistenz nicht über die "gesamte Länge" eingestellt ist, sondern auf "Einheit" (hier: Word) dann kann man SFC14/15 nicht verwenden, sondern muß mit L/T/MOVE auf die E/A-Adressen zugreifen.
Wenn die EA-Adressen im Prozessabbild liegen, dann braucht man SFC14/SFC15 nicht (und soll sie auch nicht verwenden), weil man dann mit L/T/MOVE auf die EA-Adressen im Prozessabbild zugreifen kann.

Harald

 

[showmewhatUgot]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich wiederhole und präzisiere meine Fragen:
Wie ist die Konsistenz der Module in den Steckplätzen 1 und 2 eingestellt?
Liegen die EA-Adressen im Prozessabbild PAE/PAA?

Hintergrund:
Mit SFC14/SFC15 muß man die je Modul eingestellte Länge lesen/schreiben. Wenn die Konsistenz nicht über die "gesamte Länge" eingestellt ist, sondern auf "Einheit" (hier: Word) dann kann man SFC14/15 nicht verwenden, sondern muß mit L/T/MOVE auf die E/A-Adressen zugreifen.
Wenn die EA-Adressen im Prozessabbild liegen, dann braucht man SFC14/SFC15 nicht (und soll sie auch nicht verwenden), weil man dann mit L/T/MOVE auf die EA-Adressen im Prozessabbild zugreifen kann.

Harald

da war vorher ein anderer Kollege dran und ich bin mit SFC14/15 nicht vertraut bzw. habe damit nichts zu tun gehabt (bin eher für die Visualisierung zuständig) wo/ kann ich die beiden Punkte überprüfen?

 

[showmewhatUgot]

Konsitenz über "Einheit"

 

[showmewhatUgot]

Habe es jetzt hin bekommen. Es funktioniert nur bei Byte 4 am RECORD bei mehr als 4 kriege ich einen Fehler angezeigt. Weißt jemand woran das liegt bzw. gibt es eine Möglichkeit alle 64 Bytes auf einmal auszulesen und in den DB zu schreiben? Ansosten müsste ich 16 x SFC 14 einprogrammieren, aber da gibt es bestimmt eine elegantere Lösung für.

 

[Wincctia]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

du hast ja selbst geschrieben die Konsistenz steht auf Einheit leider wird es für dich nicht viele Möglichkeiten gebe. entweder ein Netzwerk mit einem Schwung L PEW 282
T DB11.DBW0
L PEW 284
T DB11.DBW2
…..


bist du alle Wörter so eingelesen hast.

Alternative Du verpackst das in eine AWL Schleife.

andere Alternativen in der Hardware Config der Cpu kann (ich glaube unter Taktmerker und Zeiten) die größe des Prozessabildes eingestellt werden dies Vergrößern etwas auf 512 Byte.
Achtung beim Laden des Programms in die Cpu werden alle Aktuallwerte der DBs gelösch dies kann grosse Probleme verursachen. Dann kannst du die Daten per Sfc 20 von den Eingängen auf den Db kopiere.


Gruß tia

 

[PN/DP]

Ich frage noch ein drittes (und letztes Mal): Liegen die EA-Adressen E282..345 und A256..263 im Prozessabbild PAE/PAA? Sprich: wie groß sind die Prozessabbilder der Eingänge und Ausgänge in den Eigenschaften der CPU > Zyklus/Taktmerker eingestellt?
Wenn die EA-Adressen außerhalb des Prozessabbildes liegen, dann geht nur wordweise (vermutlich auch doppelwordweise) Kopieren aus/in die Peripherieadressen mit "L PEW... / T PAW..." wie Wincctia bereits angedeutet hat.
Wenn die EA-Adressen vollständig im Prozessabbild liegen, dann kannst Du Deine 64 Byte einfach mit SFC20 BLKMOV in Deinen DB kopieren. Wenn Du das so willst, dann dafür sorgen, daß die Adressen im Prozessabbild liegen: entweder das Prozessabbild entsprechend groß einstellen (z.B. Größe PAE: 346 Byte und Größe PAA: 264 Byte, oder größer), oder einfach die EA-Adressen auf niedrigere Adressen einstellen z.B. E100 und A100.

Das Laden der HW Konfig in die CPU geht nur im STOP der CPU. Aktualwerte der DB werden dabei aber nicht gelöscht - warum auch, wenn gar keine DB geladen werden?

PS: kann bei der Konsistenz "gesamte Länge" eingestellt werden? Dann könntest Du SFC14/SFC15 verwenden.

Harald

 

[Wincctia]

hallo Harald

weil beim verändern der Größe des Prozessabildes die Cpu ihren Arbeitsspeicher reorganisiert. Die Standard Größe des PA bei einer 317 wären 256 icv gehe fast davon aus das dies auch hier so ist.

Gruß Tia

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

weil beim verändern der Größe des Prozessabildes die Cpu ihren Arbeitsspeicher reorganisiert.

Meines Wissens ist das nur bei S7-400 so. Bei S7-300 sind die Speicherbereiche der Eingänge und Ausgänge von vornherein in der maximal einstellbaren Größe der Prozessabbilder vorhanden (und können hinter den PAE/PAA wie Merker verwendet werden). Ein Reorganiseren des Arbeitsspeichers ist nicht nötig (und kann die S7-300 auch nicht wirklich)

Harald

 

[Wincctia]

Hallo Haral,

ob es bei allen S7 300 so ist kann ich dir nicht sagen aber bei einer aktuellen 317-2dp hatte ich es glaub ich erst… bin mir aber gerade nicht 100% sicher.

Gruß Tia

 

[TP-Inc]

Hintergrund:
Mit SFC14/SFC15 muß man die je Modul eingestellte Länge lesen/schreiben. Wenn die Konsistenz nicht über die "gesamte Länge" eingestellt ist, sondern auf "Einheit" (hier: Word) dann kann man SFC14/15 nicht verwenden, sondern muß mit L/T/MOVE auf die E/A-Adressen zugreifen.
Wenn die EA-Adressen im Prozessabbild liegen, dann braucht man SFC14/SFC15 nicht (und soll sie auch nicht verwenden), weil man dann mit L/T/MOVE auf die EA-Adressen im Prozessabbild zugreifen kann.

Harald

Hallo Harald,
Das hab ich schon oft gelesen, hatte aber im Classic nie Probleme obwohl ich immer SFC14/15 für DP/PN Teilnehmer genutzt habe. Ich hatte da nie ein Problem welches nicht falsche LADDR oder Länge von record war. Gabs da wirklich mal Probleme mit der Konsitenz?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

ob es bei allen S7 300 so ist kann ich dir nicht sagen aber bei einer aktuellen 317-2dp hatte ich es glaub ich erst… bin mir aber gerade nicht 100% sicher.

Mit aktuelle 317-2DP meinst Du wohl 317-2AK14 mit Firmware ab V3.3? Im zugehörigen Gerätehandbuch von 2011 steht, daß die Prozessabbilder der Ein- und Ausgänge im Systemspeicher liegen und nicht im Arbeitsspeicher. Eine Änderung der Größen der Prozessabbilder hat demnach keinen Einfluß auf den Arbeitsspeicher und bewirkt auch keine Reorganisation des Arbeitsspeichers. (Ich habe aber nicht getestet, ob diese Angaben von Siemens korrekt sind) Ich finde bei Siemens keinen Hinweis, daß das womöglich mal geändert wurde, oder überhaupt bei S7-300 vorkommen kann.
Oder hast Du den DB-Aktualdatenverlust vielleicht mit TIA erlebt?

Das hab ich schon oft gelesen, hatte aber im Classic nie Probleme obwohl ich immer SFC14/15 für DP/PN Teilnehmer genutzt habe. Ich hatte da nie ein Problem welches nicht falsche LADDR oder Länge von record war. Gabs da wirklich mal Probleme mit der Konsitenz?

Möglicherweise verstehe ich Deine Frage nicht? Meinst Du, Du verwendest SFC14/SFC15 auch problemlos für 4 Byte oder 2 Byte?
Irgendwann in den letzten 20 Jahren habe ich irgendwo gelesen (und ich glaube auch praktisch erlebt) daß SFC14/SFC15 nur mit 3 oder >= 5 Byte Länge verwendet werden können (und eigentlich auch nur dann Sinn machen). Ob das in neueren Firmware-Versionen abgeschafft wurde oder vielleicht doch schon immer auch mit 4 Byte (2 Byte? 1 Byte?) ging, weiß ich nicht. Bei Forums-Themen im Zusammenhang mit TIA scheint es so, daß SFC14/SFC15 anscheinend mit jeder beliebigen Länge (auch 4 Byte) verwendbar sind. Habe ich aber nicht überprüft. S7-300/400 programmiere ich nicht mit TIA.

Harald

 

[PN/DP]

Zu SFC14/SFC15 nicht mit 4 Byte Länge finde ich jetzt nur diese schwammige Beschreibung:
Wo und wann wird die Peripherieadressierung benötigt?

Sollen größere zusammenhängende Eingangsbereiche (> 4Byte) direkt und konsistent gelesen werden, dann kann die SFC 14 (DPRD_DAT) verwendet werden. Sollen größere zusammenhängende Ausgangsbereiche (> 4 Byte) direkt und konsistent geschrieben werden, dann kann die SFC 15 (DPWR_DAT) verwendet werden.

Harald

 

[showmewhatUgot]

Ich frage noch ein drittes (und letztes Mal): Liegen die EA-Adressen E282..345 und A256..263 im Prozessabbild PAE/PAA? Sprich: wie groß sind die Prozessabbilder der Eingänge und Ausgänge in den Eigenschaften der CPU > Zyklus/Taktmerker eingestellt?
Wenn die EA-Adressen außerhalb des Prozessabbildes liegen, dann geht nur wordweise (vermutlich auch doppelwordweise) Kopieren aus/in die Peripherieadressen mit "L PEW... / T PAW..." wie Wincctia bereits angedeutet hat.
Wenn die EA-Adressen vollständig im Prozessabbild liegen, dann kannst Du Deine 64 Byte einfach mit SFC20 BLKMOV in Deinen DB kopieren. Wenn Du das so willst, dann dafür sorgen, daß die Adressen im Prozessabbild liegen: entweder das Prozessabbild entsprechend groß einstellen (z.B. Größe PAE: 346 Byte und Größe PAA: 264 Byte, oder größer), oder einfach die EA-Adressen auf niedrigere Adressen einstellen z.B. E100 und A100.

Das Laden der HW Konfig in die CPU geht nur im STOP der CPU. Aktualwerte der DB werden dabei aber nicht gelöscht - warum auch, wenn gar keine DB geladen werden?

PS: kann bei der Konsistenz "gesamte Länge" eingestellt werden? Dann könntest Du SFC14/SFC15 verwenden.

Harald

Die Größen der EA sind jeweils 160, also sind die nicht hinterlegt. wie kann bzw kann man die ohne weiteres Anpassen? Die Felder sind momentan ausgegraut und mir wird ein Warnfeld angezeigt "... kann nur lesend zugegriefen werden"

Zu PS, es ist eine GSD Datei vom Hersteller und man kann diese Einstellung nicht verstellen.