VIPA 315SN - Stop: "Fehler beim allokieren von Lokaldaten" und Lokaldaten-Größen

RONIN

Level-3
Beiträge
2.556
Reaktionspunkte
798
Zuviel Werbung?
-> Hier kostenlos registrieren
VIPA 315SN - Stop: "Fehler beim allokieren von Lokaldaten" und Lokaldaten-Größen

Hallo.

Es geht mir um eine Anlage bei einem unserer Kunden bei der sowohl ne 315-2PN/DP als auch eine Vipa 315SN im Einsatz ist.
An dieser Anlage sind wir programmiertechnisch (macht die IH) nicht beteiligt, haben jedoch einen FB zur Auswertung von Profibus-Energiemessgeräten zur Verfügung gestellt.

Der FB sollte eigentlich OK sein (in vielen Anlagen verwendet, auch mit kleineren CPUs) und funktioniert auch in der 315-2PN/DP des Kunden.
Wenn er den FB aber in der VIPA 315-SN verwendet kommt es zum Stop.
Daher wurde ich natürlich gefragt woran das liegen kann...

Der FB an sich ist eigentlich nichts besonderes. Daten werden vom PB gelesen und in eine UDT-Struktur im Temp zusammengesetzt, danach mittels Blockmove in die selbe Struktur in einem DB kopiert.

Hier der zugehörige Diagnosepuffer-Auszug und die Hardware-Konfig
Anhang anzeigen Diagnosepuffer.txt
Die Peripherie-Zugriffsfehler bei den anderen Meldungen (FC51) kommen anscheinend vom fehlerhaften Zugriff auf einen Sanftanlauf, sollte nicht direkt mit dem Problem zusammenhängen.

Mit ein wenig suchen bin ich auf folgenden Beitrag von Ralle gestoßen. Vor allem folgender Satz macht mir ein wenig Sorgen...
Bei den anderen S7-300-CPUs ist jeder Prioritätsklasse eine feste Anzahl von Lokaldaten zugeordnet (256 Bytes), die nicht verändert werden kann.

Heißt das nun das man nur 256Byte Lokaldaten (oder mehr bei größeren CPUs sofern man es anders einstellt), über die ganze Verschachtelungstiefe vom OB1-Weg, zur Verfügung hat.
In der HW-Konfig der VIPA sind nämlich 256Byte parametriert? :confused:
315SN_HW-Konfig.jpg

Wie steht das jetzt im Zusammenhang mit der Angaben aus den Datenblättern?
SIEMENS S7315-2PN/DP Datenblatt schrieb:
Lokaldaten
● je Prioritätsklasse, max. 32 768 byte; max. 2048 byte pro Baustein
VIPA S7315-SN Datenblatt schrieb:
Max. local data size per execution level 3072 Byte
Max. local data size per block 3072 Byte


Die angesprochene Struktur im Temp des FB braucht 200Byte. Insgesamt hat der FB laut Objekteigenschaften eine Lokaldaten-Bedarf von 238Byte.
Aufrufstruktur sieht folgendermaßen aus:
Code:
OB1-Begin
|------- Mehrere Programm FBs und FCs
|------- FB für Messgeräte (1 Bit Temp-Daten)
--------|------- Aufruf des Energiemessgeräte-FB als Multiinstanz
OB1-Ende

Kann mir nicht vorstellen dass dort irgendwie die Max-Temp-Datengröße überschritten wird....
Hab auch schon definitiv Programme mit 350+ Byte im Temp auf 315PN-DP-CPUs am Laufen gehabt...

Könntet ihr mir mal den Zusammenhang zwischen den "Lokaldaten-Größen zu den Prioritätsklassen" und der "Lokaldaten-Gesamtgröße aus den Datenblättern" erhellen.
Bin in dem Punkt echt verwirrt. :confused:

Des weiteren, habt ihr Ideen warum die Vipa auf Stopp geht?

Danke.
 
Zuletzt bearbeitet:
Hallo

Hast Du schon die Fehlernummern der Vipa Hotline genannt ?
Es gibt m. W im Handbuch eine Auflistung der Codes.

Gruß

Lupo
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, vor allem die Einträge aus dem Diagnosepuffer sind interessant.
Diagnosepuffer schrieb:
Kein Eintrag in Textdatenbasis. Hex-Werte werden angezeigt.
Ereignis-ID: 16# E0CC
Hab noch nicht daran gedacht den Vipa-Support heran zu ziehen, obwohl es definitiv eine Idee wäre.

Eine direkte Suche nach dem Fehler "Fehler beim allokieren von Lokaldaten" brachte mich bis jetzt nur auf die Siemens-Seiten für die Firmware-Updates bei den 300/400-CPUs. Den Fehler scheint's also auch auf der Siemens 300er zu geben. Ist sicher nicht VIPA-spezifisch.

Hab auch noch einen weiteren Beitrag hier im Forum zu diesem Thema gefunden.
Dies bestärkt meine Vermutung das der Fehler von genannter 256Byte Lokaldaten-Einstellung kommt.
Kann gut sein das, wenn man diesen Wert verstellt, dass dann alles OK ist.
Ich glaube aber beim besten Willen nicht das die VIPA von Haus aus (auch wenn man es umstellen kann) auf besagte 256Byte begrenzt ist.
Wär ja lachhaft, wie groß wär dieser Wert dann bei einer Siemens?

Die Frage ist daher:
Wie groß ist den nun die Grenze für verwendbare Lokaldaten bei einer Siemens-300er oder einer VIPA-300er, bzw. wie hängt das mit dieser 256Byte-Einstellung zusammen?
 
Der OB1 braucht schon 20 Byte Lokaldaten. 256 Byte sind also definitiv zuwenig.

Ich staune, daß die CPU das Problem erst merkt, wenn der FB56 auf den nicht vorhandenen TEMP-Bereich zugreift. Ich hätte gedacht, daß der Simatic Manager das Programm garnicht erst in die CPU lädt.

PS: Bei S7-300 sind jeder Prioritätsklasse 256 Byte Lokaldaten fest zugeordnet, nicht änderbar. Bei S7-400-CPU's und der CPU 318 kann man die Größe einstellen.

PPS: da ist die Step7-Hilfe nicht aktuell :oops: Bei neueren S7-300-CPU ist die Größe der Lokaldaten max 32kB pro Ablaufebene, max 2kB pro Baustein. siehe CPU-Daten

Harald
 
Zuletzt bearbeitet:
Der OB1 braucht schon 20 Byte Lokaldaten. 256 Byte sind also definitiv zuwenig.
Du bist also auch der Meinung.... Hmm... :icon_confused:
Bei welcher der 29 Prioritätsklassen müsste ich denn den Wert erhöhen.

Ich find's aber ehrlich gesagt als Witz von Haus aus nur 256Byte Temp zu haben....

Bei ner Siemens 315 geht auf jeden Fall mehr. Da man es aber nicht einstellen kann ist es nicht direkt ersichtlich...
Zitat von SIEMENS S7315-2PN/DP Datenblatt
Lokaldaten
● je Prioritätsklasse, max. 32 768 byte; max. 2048 byte pro Baustein
Sind es dort die angeführten 2048Byte?

Fragen über Fragen... :confused:
Ich glaub ich schnapp mir am Montag als erstes ne Siemens-CPU und teste es aus... ;-)
 
Aha, danke erst mal.
Hatte deinen Nachtrag zu spät gesehen.
Ich werd den Jungs von der IH raten den Wert für Prioritätsklasse 1 zu erhöhen.

Die Grenze von 2048Byte ist gut zu Wissen, ich hab oftmals ein paar hundert Byte im Temp.
Es handelt sich definitiv teilweise um veraltete Info, auch ich hatte ein paar Einträge mit einer 256Byte Grenze bei der 315PN/PN gelesen.
Es ist auch gut zu Wissen das ich bei älteren CPUs aufpassen muss, die Zeit damals waren ganz schön hart.... :ROFLMAO:

Ich nehme an dass die dort verwendete VIPA ne ältere ist, deswegen wahrscheinlich diese magere Begrenzung.

Nachmals, Danke.
 
Zuletzt bearbeitet:
Besonders schmerzhaft ist das, wenn man mit Strings hantiert, denn dann hat man bei den älteren SPS ganz schnell die Grenzen erreicht.
Verdopple einfach mal die Lokaldaten und dann sollte das schon laufen.
 
@Ronin:
Es ist aber definitiv so, dass es (wie schon geschrieben) NUR an der Festlegung der Lokaldaten für die Prio-Klasse liegt.
Ich bin selber bei den VIPA-CPU's auch schon so 2-20 mal darüber gestoplert.
Das Problem tritt vor Allem beim Bearbeiten von Strings ganz schnell auf ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ein FB kann bei so hohem Lokaldaten-Bedarf seinen STAT benutzen. Einem FC könnte man einen Global-DB mitgeben.
Oder Schmiermerker.... *ROFL*
@Ronin:
Es ist aber definitiv so, dass es (wie schon geschrieben) NUR an der Festlegung der Lokaldaten für die Prio-Klasse liegt.
@Larry: Aha, dann sind also auch die aktuellen Vipa-CPUs von Haus aus so eingestellt?
Wenn man es weiß dann ist es ja OK...
Ach.. Da fällt mir gerade ein dass sich die Sache ja eh noch verschiebt, der Instandhalter der sich um die Sache kümmern wird ist nächste Woche nicht da. Werd aber dann den Erfolg hier noch vermelden.

Ja über 256Byte kommt man schnell, sei es mit Strings, oder eben wie hier mit dem Lesen der PB-Schnittstelle vom Peripherieabbild mit DPRD_DAT in den TEMP-Bereich und das anschließende zusammenbasteln der Datenstruktur die natürlich auch dort liegt.
 
Ich kann jetzt gerade nicht in ein Projekt hineinschauen, habe es aber so in Erinnerung, dass 256 Byte die Default-Einstellung für alle Prioritätsklassen ist/war.
Hatte das dann nicht gereicht dann habe ich es oft auf 512 oder sogar noch höher raufgeschraubt (manchmal war sogar bei Strings 2048 noch notwendig).

Gruß
Larry
 
Bin, aus Interesse, nochmal die VIPA-Datenblätter aller 315-CPUs durchgegangen und habe festgestellt das sich diese untereinander auch sehr unterschiedlich sind...

TYPEmax. Lokaldatengröße je Baustein [BYTE]max. Lokaldatengröße je Ablaufebene [BYTE]
CPU 315SB/DPM (315-2AG12)510510
CPU 315SN/EC (315-4EC12)30723072
CPU 315SN/EC ECO (315-4EC32)10241024
CPU 315SN/NET (315-4NE12)510510
CPU 315SN/NET (315-4NE13)10241024
CPU 315SN/PN (315-4PN12)30723072
CPU 315SN/PN ECO (315-4PN33)10241024

Die 1024Byte sind ja noch OK, aber mit den 510Byte-Modellen möchte ich nicht ernsthaft arbeiten müssen.
Schon komisch dass die CPUs sich (hab jetzt die restlichen Werte nicht verglichen), innerhalb der selben Baureihe, so stark unterscheiden.

[EDIT] Wie von Larry schon erahnt konnte das Problem durch erhöhen des Lokaldatenbereichs gelöst werden.

Thema erledigt. Danke. :D
[/EDIT]
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, vor allem die Einträge aus dem Diagnosepuffer sind interessant. (Ereignis-ID 16# E0CC)
Hab noch nicht daran gedacht den Vipa-Support heran zu ziehen, obwohl es definitiv eine Idee wäre.

Laut Handbuch ein VIPA spezifischer Fehler (S. 78). Da findet sich auch die Zusatzinfo 1 (16# 0009) als falscher SAP :confused:.
Hab mir mal den Kopf deines Diagnosepuffers angesehen, die CPU hat FW 3.5.3. Wenn du bei VIPA auf die Homepage gehst und dort im Service / Support - Download die Firmware zu der CPU nachschaust könnte ich mir vorstellen dass Du nicht mehr ganz auf dem letzten Stand bist (derzeit V 3.6.1). Würde da mal ein Update machen und so schon zumindest einen potentiellen Fehler durch einen eventuell vorhanden reduzieren usw. Nur ein Vorschlag. Falls danach der Fehler trotzdem weiterhin auftritt, kannst Du ja immer noch an Vipa schreiben...
 
@DieBoese0815: Vielen Dank für die Info. Ich kanns ja bei Gelegenheit mal weiterleiten.

Wie gesagt, die Anlage ist nicht die "meinige". Ist eine Bestandsanlage für die ich den Instandhaltern einen Baustein zur Verfügung gestellt habe.
Daher auch die ältere Firmware, etc.
Wenn an der Anlage sonst noch Fehler sind (den aktuellen Zustand kenne ich nicht) (wir haben auch sonst nichts von VIPA im Einsatz) ist das nicht sooo ganz mein Problem. ;)
 
Moin Ronin,

also dein Diagnosepuffer zeigt ja neben dem E0CC Eintrag auch an dass deine CPU wohl schon älteren Baujahrs ist und von der Firmware sich im Mittelalter befindet. Ich würde deshalb dringend einen Update vorschlagen, denn der E0CC Fehler soll bei vielen CPU's durch eine Update beseitigt worden sein. Die passende Version bekommst du hier...

Nachdem du das Update ausgeführt hast, die CPU auf Werkseinstellungen zurücksetzen (einfaches Urlöschen reicht nicht), und dann sollte es klappen...
Falls trotzdem dein Problem besteht, dann schick dein Projekt und aktuellen Diagnosepuffer mal an support@vipa.de wie oben schon angeraten damit die Jungs dort sich die Sache mal ansehen.
 
Zuletzt bearbeitet:
Zurück
Oben