Step 7 S7-300 Reservieren von Verbindungsressourcen

Ludewig

Level-2
Beiträge
998
Reaktionspunkte
203
Zuviel Werbung?
-> Hier kostenlos registrieren
Gegeben ist eine Anlage mit
- 1St. S7-300 CPU 313C-2DP 6ES7 313-6CF03-0AB0 V2.6
- Alarmmodem (enthält einen Deltalogic-TS-Adapter am MPI-Bus)
- unbekanntem Profibus-Teilnehmer im Leitsystem am Profibus

In Net-Pro ist gar nichts definiert.
Es sind keine besonderen Ressourcen in der CPU reserviert, also steht dort 1 PG, 1 OP (ist aber nicht vorhanden), 0 S7-Basis-Kommunikation.

Problem: Der TS-Adapter am MPI-Bus verliert gelegentlich unwiederbringlich seine Verbindung zur CPU. Nach meinem bisherigen Wissen hilft nur der Kaltstart beider Geräte.

Frage: Ist es besser, sinnvoll, notwendig, in Net-Pro irgendwelche Ersatzgeräte einzutragen, damit die Verbindungsresourcen der CPU gesichert bleibn?
Es kann ja nicht gerade von Überlastung ausgegangen werden.

Nachtrag für Sven R, falls er mitliest:
Der SupportLog bricht wegen "Skriptfehler ab, enthält aber mit aufsteigender Nummer immer die gleiche Zeile:
- <ReadLog>
- <ID_218 _="2019/07/14,03:41:30">
- <MPI>
<Protocol _="V00.84" />
</MPI>
</ID_218>
- <ID_219 _="2019/07/18,03:41:23">
- <MPI>
<Protocol _="V00.84" />
</MPI>
</ID_219>
etc., bei ca. 387 bricht das mit Fehlermeldung ab.
 
Zuletzt bearbeitet:
Wenn das Anlage läuft ohne Probleme, was steht unter die online Verbindungsressourcen ?
Wenn es passiert dass das Anzahl von belegte Verbindungen langsahm aufsteigt, dann ist das Problem vielleicht bei das Leitsystem der Verbindungen reserviert aber nicht wieder freigibt.
 
Was passiert denn eigentlich, wenn die Ressourcen erschöpft sind? Beziehungsweise, was müsste geschehen, damit die CPU erkennt, dass die reservierten Ressourcen gar nicht mehr benötigt werden. Spielt da Zeit eine Rolle?
 
Wenn die Verbindungsressourcen erschöpft sind, dann kann sich ein weiterer Teilnehmer nicht mehr mit der SPS verbinden.

Wenn sich jemand mit der SPS verbinden will, dann wird dazu ein TSAP verwendet mit Rack/Slot und dem Verbindungstyp. Im Prinzip besteht zwischen PG und OP Verbindung kein Unterschied, es dient einzig dazu, dass du entsprechende Verbindungen reservieren kannst. Eben für den 1 PG Zugriff, damit du auch wenn alle Verbindungen belegt sind, immer noch dein PG Zugriff möglich ist. Leider habe ich es auch schon in Anleitungen von diversen Geräten von Drittanbietern gelesen, für ein HMI oder OPC Server PG als Verbindungsressource zu verwenden. Das macht man natürlich nicht.

Ich vermute mal, der TS-Adapter verbindet sich nur bei Bedarf und verwendet dann die PG Ressource. Eigentlich sollten die Ressourcen von der SPS wieder freigegeben werden wenn sich jemand trennt. Schau doch mal nach der Firmwareversion deiner CPU, ob es da eine Aktuellere gibt und ob in den Änderungsvermerken etwas darauf hinweist, dass dahingehend etwas korrigiert bzw. im Siemens-Sprech "optimiert" wurde.
 
Erst einmal Danke für Eure Hinweise. Ich komme leider coronabedingt kurzfristig an die Steuerung nicht heran, da sie im Ausland (1000km+) montiert ist.
Das von Deltalogic vertriebene Alarmmodem liest meines Wissens normalerweise Daten über ISOonTCP (RFC 1006) aus, kann aber bei Bedarf auch einen seriellen TS-Adapter abbilden, der dann mit einem Port-Emulator angesprochen werden kann.
Kurz vor dem aktuellen Verbindungsausfall hat vermutlich ein ehemaliger Kollege versucht, auf die Steuerung zu kommen, denn im SupportLog lassen sich innerhalb einer Stunde mehrere Einträge finden, was sonst nur bei einem Reboot des Modems geschieht.
Nach der in meinem ersten Beitrag aufgeführten Abfolge von Einträgen ist das "Prorocol" dann plötzlich leer:
- <MPI>
<Protocol _="" />
</MPI>
Im Grunde ist jetzt meine Frage, was ich von hier aus überhaupt unternehmen kann.
Liegt das Problem auf der Seite des Modems? Gibt es eine undokumentierte Funktion, die den TS-Adapter rebootet, resettet?
Oder liegt es auf der SPS-Seite? Dann müsste jemand vor Ort die Steueurng neu booten und es stellt sich die Frage, wie man dieses Problem zukünftig verhindern kann.
 
Hallo Ludewig,

um welche Firmwareversion handelt es sich genau?
Ich habe die Historie seit 2.6 einmal durchgelesen und da gibt es viele Behebungen zum Kommunikationsabbruch. Es ist ja unklar, wie die anderen Busteilnehmer mit der SPS kommunizieren.
Es gab auch schon früher Siemenssteuerungen, die beim Beenden einer Verbindung die Resourcen nicht ordentlich freigegeben haben. Dann half nur Neustart der SPS. Allerdings weiß ich nicht mehr, in welcher Firmwareversion dies genau vorkam.
Ich würde auf jeden Fall einmal ein Update auf 2.6.11 machen und dann schauen, ob das Problem noch auftritt. Denn ein solches (Fehl-)Verhalten ist mir bei dem Alarmmodem nicht bekannt.

Viele Grüße
 
Zurück
Oben