Warum hat der Driss ein paar Jahre lang funktioniert ???

Question_mark

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

ich habe ein recht merkwürdiges Problem. Die von mir nachfolgend beschriebene Anlagenkonfiguration ist in Wirklichkeit etwas komplexer, ich versuche aber nachstehend alles auf das wesentliche zu beschränken. Also die Anlage läuft schon seit ca. 8 Jahren ohne Probleme, soll aber in der Ethernet Konfiguration geändert werden.

Es gibt eine S7 CPU 416, nennen wir das mal Anlage1. Dann gibt es eine Anlage mit einer S7 CPU 412, nennen wir das mal Anlage2.

Anlage1 baut zwei Verbindungen (Iso-on-TCP) über einen CP443-1 zur Anlage2 auf. Im Projekt der Anlage1 ist diese als spezifizierte Verbindung projektiert. Im S7-Programm der Anlage1 werden diese Verbindungen über FC5/FC6 (mit den IDs 1 und 2, da es ja zwei Verbindungen gibt) bearbeitet und das funktioniert auch schon seit Jahren.

Nun kommen wir zur Anlage2. Diese hat zwei Stück CP443-1. Einer, nennen wir den mal Anlage2/CP1, ist in einem Netzwerk mit dem CP der Anlage1 verbunden. Der andere, nennen wir den mal Anlage2/CP2 ist in einem anderen physikalischem Netzwerk mit einem VAX-Rechner verbunden.
Eine Verbindung zur Anlage1 ist hier nicht projektiert. Empfang und Senden zur Anlage1 wird im S7-Programm ebenfalls über FC5/FC6 mit den IDs 3 und 4 abgewickelt. Und das funktioniert sogar seit Jahren, ich weiss aber nicht wirklich warum ?

Dann kam der Wunsch des Kunden, auf der Anlage2 den CP2 nicht mehr auf den VAX-Rechner (das war vorher eine S7-Verbindung)zu leiten, sondern auf ein neues System. Dieses System ist ziemlich blöde, das kann nämlich nur Fetch/Write Verbindungen. Und davon brauche ich vier Verbindungen, damit dieses blöde System richtig funktioniert...

Also dann mal ganz schnell in die Netz-Konfiguration des CP2 der Anlage2 diese 4 Fetch/Write Verbindungen eingefügt, die Fetch/Write Verbindungen zum neuen System funktionieren perfekt.

Allerdings gibt es nun keine Verbindungen zur Anlage1 mehr, die sind einfach tot (also in der Netzwerkdiagnose der Anlage2 nicht mehr vorhanden. Obwohl die ja auf einem anderen CP (also Anlage2/CP1 ) und in einem anderen Netzwerk stattfinden (aber dort in der Anlage2 nicht projektiert sind).

Fazit nach einigen Tests also : Sobald ich in der Anlage2 auf dem CP2 eine Fetch/Write Verbindung einfüge, funktionieren in der Anlage2 auf dem CP1 die bisherigen Verbindungen nicht mehr (sind in der CP-Diagnose einfach nicht mehr vorhanden).

Mein Verdacht : Ich muss in der NetPro Projektierung der Anlage2/CP1 ebenfalls eine unspezifizierte Verbindung zur Anlage1 projektieren, das das ganze Konstrukt bisher einige Jahre funktioniert ist wohl eher ein Zufallsprodukt.

Wenn in der S7-Software die Bausteine FC5/FC6 verwendet werden, dann muss eben auch die Verbindung auf beiden Seiten projektiert (meinetwegen auch unspezifiziert) sein, damit das ganze über IDs funktioniert. Das ist meine Meinung, kann das jemand bestätigen ?

Die vorherige Anlagenkonfiguration hat bisher etliche Jahre funktioniert, aber wie kann das mit einseitiger, unspezifizierter Projektierung funktionieren wenn IDs über FC5/FC6 benutzt werden ?

Also mal die Kernaussage : Ich füge in Anlage2/CP2 in einem anderen IE-Netzwerk (also Anlage2/CP1 und Anlage2/CP2 sind physikalisch ein anderes IE-Netzwerk) eine Fetch/Write Verbindung ein. Und zwei Iso-on-TCP Verbindungen auf Anlage2/CP1 zur Anlage1/CP1 bleiben auf der Strecke und funktionieren nicht mehr?

Ich bin im Moment ein riesiges Fragezeichen (Nomen est omen), hat irgendjemand eine Idee? Nach meiner Meinung muss die Verbindung zwischen Anlage1/CP1 und Anlage2/CP1 auf beiden Seiten projektiert sein (wegen FC5/FC6) und das ganze hat bisher nur nach einem Zufallsprinzip funktioniert.

Gruß

Question_mark
 
Moin,

ich kann es mir nur dadurch erklären, dass die zwei Iso-on-TCP Verbindungen auf Anlage2/CP1 früher irgendwann mal geladen wurden, danach aber fälschlicherweise im Netpro von Anlage 2 gelöscht wurden.

Diese Theorie ist aber widerlegt, falls diese Verbindungen allein durch Löschen von den Fetch/Write Verbindungen wieder funktionieren...
Das konnte ich bei deiner Beschreibung nicht exakt rauslesen.

Ist dein Projektierungsstand sicher aktuell???
Wie lädst du die Verbindungen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich versuch mal ne Theorie aufzustellen:

</einfach nur gedankenmach-Modus ON>
Wenn ich das damals alles richtig kapiert hab dann..
müssen CP's ja zu der CPU Synchronisiert sein. (Wenigstens bei der S5, bei S7 keine Ahnung.) Das heißt CP's und CPU dürfen nicht gleichzeitig auf den Speicher zugreifen. Da du Fetch/Write verbindungen auf dem zweiten CP anfügst die auf den Speicher zugreifen könnte es sein das der CP 1 deshalb nichts mehr lesen kann.

</einfach nur gedankenmach-Modus OFF>

Das mit den Verbindungen von Anlage 1 zu Ablage 2 - CP1 müsste schon stimmen wie du das sagst. An beiden muss eine Verbindung vorhanden sein, müssen zwar nicht unbedingt 2 sein, aber das ist irrelevant (Send_Recieve Aufträge haben nur eine ID).

Am Send Baustein sowie am Recieve Bautein müssten die Parameter [LADDR:] diese geben an auf welchen CP es sich bezieht. Das könntest du nachsehen. Bezieht sich auf die Interne-Adressierung. Verändert sich die Hardware, verändert sich auch der Parameter LADDR

Desweiteren müsste sich der Send und auch der Recieve Baustein ja auf irgendeine ID bezogen haben.

Aber das ist nur das was mir grad spontan einfällt. Steinigt mich net wenn was falsch ist.

MFG Befree
 
...

Hallo,

SPSKILLER schrieb:
ich kann es mir nur dadurch erklären, dass die zwei Iso-on-TCP Verbindungen auf Anlage2/CP1 früher irgendwann mal geladen wurden, danach aber fälschlicherweise im Netpro von Anlage 2 gelöscht wurden.
Die Vermutung habe ich auch.

SPSKILLER schrieb:
Wie lädst du die Verbindungen?

AG urlöschen und das ganze Projekt in die Anlage laden.

Wenn ich das AG der Anlage2 (und damit auch die CPs) nicht urlösche, funktionieren die Verbindungen zur Anlage1 nicht mehr, auch wenn ich den alten Projektierungsstand lade.

Ich denke mal, ich muss die Verbindungen in Anlage2/CP1 als einseitige Iso-on-TCP Verbindungen nachprojektieren. Warum das so bisher gelaufen hat, war wohl eher ein Zufallsprodukt.

Gruß

Question_mark
 
Zurück
Oben