Step 7 Bereichslängenfehler beim Lesen oder Schreiben

rogpomlar

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




Hoffe ihr könnt mir aus meinem Schlamassel helfen.




Zur Hardware:




CPU 315-2 PN/DP
TP1500 Comfort
Windows 7




Ich nutze: TIA V13, Step7 professional V13, und WinCC Professional V13




Zur Problematik:




Ich habe den Fehler "Bereichslängenfehler beim Lesen oder Schreiben" für jeden FU Peripherie Addresse. Es gibt kein FU-Gerät im System (nur die Baugruppen zu simulieren).
Ist die Konfiguration des FU und des CPU richtig oder die Fehler kommen nur, weil kein FU-Gerät gibt (nur die Baugruppen zu simulieren)?
Ich hoffe, die Fotos werden alles besser erklären.


Es gibt auch eine "DEFEKT" Meldung im HMI.


Ich freue mich über jede Idee.




Danke
 

Anhänge

  • Fehler4.jpg
    Fehler4.jpg
    95,5 KB · Aufrufe: 41
  • Fehler3.jpg
    Fehler3.jpg
    74 KB · Aufrufe: 34
  • Fehler.PNG
    Fehler.PNG
    25,8 KB · Aufrufe: 29
  • Fegler2.PNG
    Fegler2.PNG
    81,3 KB · Aufrufe: 37
Zuviel Werbung?
-> Hier kostenlos registrieren
Hmm, liegt das jetzt an TIA oder an der CPU? :confused:
In Step7-Classic programmiert würde es keinen Bereichslängenfehler/Zugriffsfehler geben, wenn auf E-Adressen größer als die eingestellte PAE-Größe (aber kleiner als die maximal mögliche PAE-Größe) zugegriffen wird.

Was für eine CPU hast Du genau (Bestellnummer 6ES7...) und Firmware-Version?
Ist Dein Fehler in einer echten CPU oder simulierst Du die CPU?

Harald
 
Meldung "DEFEKT" im HMI und Peripherie-Zugriffsfehler

Hallo,
ich habe etwas gefunden:
Wenn ":p" am ende der Peripherie-Adresse geschrieben wird (z.B.: %EW300 -> %EW300:p), ändert der Fehler "Bereichslängenfehler beim Lesen" zum "Peripherie-Zugriffsfehler, lesend".
Das ist richtig, da kein FU-Gerät gibt, nur das simuliertes Modul.
Dis Frage ist nun, ist diese Änderung etwas Neues in TIA PORTAL 13? Ist das immer so für die Peripherie-Adressen?


Anderenteils habe ich noch die Meldung "DEFEKT" im HMI. Was kann diese Meldung verursachen?


Vielen Dank.
 
Hallo, ich habe etwas gefunden:
Wenn ":p" am ende der Peripherie-Adresse geschrieben wird (z.B.: %EW300 -> %EW300:p), ändert der Fehler "Bereichslängenfehler beim Lesen" zum "Peripherie-Zugriffsfehler, lesend".
Ist klar.
Dis Frage ist nun, ist diese Änderung etwas Neues in TIA PORTAL 13? Ist das immer so für die Peripherie-Adressen?
Nein, kein unterschied zu Classic.
Ja ist immer so. Die Zauberworte lauten "Größe des Prozessabbildes der Ein/Ausgänge".

Die E/A-Adressen (aus dem Prozessabbild) hättest du auch in Classic nicht so ohne weiteres lesen/schreiben können. Soll heißen, funktioniert hätte es dort auch nicht. Zumindest nicht mit der Standardeinstellung bei der 315.
Das einzige, wie PN/DP schon angemerkt hat, würde Classic normalerweise keinen Bereichslängenfehler werfen wenn man auf einer 315 mit Standard-Prozessabbildgröße von 128Byte ein "L EW300" probiert.
Ist insofern komisch, da TIA oder Classic keinen Einfluss drauf haben sollte, mit welchen Systemfehlern die CPU um sich wirft...

Sie dir hier im Forum mal ein paar Beiträge zum Thema "Prozessabbild der Ein- bzw. Ausgänge an".
Dann wird der der Unterschied zwischen EW/AW <-> PEW/PAW in Classic bzw. EW/AW <-> EW:p/AW:p in TIA klar.
EW liest aus dem Prozessabbild
EW:p liest direkt aus dem Peripheriebereich (daher auch das P)


Das Problem nennt sich "Größe des Prozessabbildes der Ein/Ausgänge". Du solltest dich mal schlau machen was das ist.
Bei der IM158-CPU ist dieser Wert in der Hardware-Konfig auf 128Byte eingestellt.
Das bedeutet dass die CPU zu Zyklusbeginn die Werte vom Peripherie-Eingangsbereich, die Bytes 0 bis 128 in das Prozessabbild kopiert.
Das selbe umgekehrt am Ende das SPS-Zyklus. Da werden die Bytes 0-128 vom Prozessabbild in den Peripherie-Ausgangsbereich kopiert.

Der Peripheriebereich (der Bereich den du in der Hardware-Konfig einstellst) ist der Bereich wo die Hardware die Signale zur Verfügung stellt bzw. entgegen nimmt.
Das Prozessabbild der Eingänge (das du z.B. mit UND E0.0 liest) dient als Momentaufnahme der Eingänge zu Beginn der Zyklus,
damit du während des ganzen Zyklus die gleichen Zustände für den selben Eingang hast.
Das Prozessabbild der Ausgänge (das du z.B. mit SETZE A0.0 schreibst) dient dazu das die von dir manipulierten Ausgänge erst am Ende des Zyklus ausgegeben (in den Peripheriebereich übernommen) werden. Damit werden Zwischenzustände verhindert.

Das Byte 568 auf das du zuzugreifen versuchst ist bei der Standardeinstellung nicht im Prozessabbild dabei.

Lösung 1: Du erhöhst die Einstellung in der Hardwarekonfig. (Ist aber nicht nötig sofern du nur analoge Eingänge in diesem hohen Bereich hast)
Lösung 2: (Gängige Lösung) Man liest/schreibt direkt in den Peripherie-Bereich.
Für dich, bezogen auf deinen jetzigen Programmaufbau, empfiehlt sich Lösung 1. ;)
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich schlage Lösung 3 an:
Mittels SFC14 DPRD_DAT und SFC15 DPWR_DAT lest und schreibt man die Daten konsistent die der FU benötigt.
edit: Ein Vorteil ist wenn dein HMI verbindet mit die FU Daten die in ein DB unterlegt sind (mittels SFC14 und SFC15) anstatt die E/A Adressen, dann bekommst du auch kein "bereichslängenfehler" beim simulieren. Die Aufrufe von SFC14 und SFC15 musst du dann mit ein Simulierungsbit sperren.


Lösung 1 ist auch konsistent.
Lösung 2 ist NICHT konsistent !
Bei FU's ist es oft ein Forderung das die Daten konsistent übertragen werden.
 
Zuletzt bearbeitet:
Zurück
Oben