Probleme mit PN-PN-Koppler

[PeterPan-35]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
wir haben einen PN-PN-Koppler bekommen, welchen wir heute einbauen sollen. Die Kommunikation zwischen den Maschinen funktioniert soweit, doch jetzt geht eine CPU immer auf Störung, wenn man das Profinet-Kabel der anderen CPU abzieht. Das gleiche natürlich auch, wenn man nur mit einer Maschine arbeiten möchte und eine ausgeschaltet ist.

Wenn man das eigene Kabel der CPU vom Koppler trennt geht die CPU zwar auf SF und BF, aber sie arbeitet weiter.
Wir haben einen OB83, 86 & 87 geladen.

In der Diagnose werden auch immer unterschiedlichste Fehler angezeigt, einmal wegen dem FC14 GT_DT, ein andermal wegen dem FC242 von SEW zur Regler Kommunikation.

Beide Maschinen haben 192.168.0.xx und das Subnetz 255.255.255.0.

Kann es evtl. daran liegen, dass beide im gleichen Subnetz sind und ab und an IP-Adresse in beiden Maschinen gleich sind?

 

[PN/DP]

Die Kommunikation zwischen den Maschinen funktioniert soweit, doch jetzt geht eine CPU immer auf Störung, wenn man das Profinet-Kabel der anderen CPU abzieht.

Das ist normal. Weil da ja ein projektiertes Profinet-Device ausfällt bzw. nicht mehr ordnungsgemäß kommuniziert.

Das gleiche natürlich auch, wenn man nur mit einer Maschine arbeiten möchte und eine ausgeschaltet ist.

Man kann den PN/PN-Koppler mit SFC12 deaktivieren. Dann darf man aber auch nicht mehr auf die E/A-Adressen des Kopplers zugreifen.

Wenn man das eigene Kabel der CPU vom Koppler trennt geht die CPU zwar auf SF und BF, aber sie arbeitet weiter.
Wir haben einen OB83, 86 & 87 geladen.

Vermutlich wird auch noch OB85 (Peripheriezugriffsfehler bei Prozessabbild-Aktualisierung) und/oder OB122 (Peripheriezugriffsfehler im Programm) gebraucht.

In der Diagnose werden auch immer unterschiedlichste Fehler angezeigt, einmal wegen dem FC14 GT_DT, ein andermal wegen dem FC242 von SEW zur Regler Kommunikation.

Du meinst die Fehler haben mit der PN/PN-Kopplung zu tun??
Wie lauten die diesbezüglichen Diagnosepuffereinträge genau?
Den Diagnosepuffer kann man als Textdatei speichern. Vorher auf maximale Puffergröße einstellen.

Beide Maschinen haben 192.168.0.xx und das Subnetz 255.255.255.0.

Kann es evtl. daran liegen, dass beide im gleichen Subnetz sind und ab und an IP-Adresse in beiden Maschinen gleich sind?

Wenn es zwischen den beiden Maschinen-Netzen keine anderen Verbindungen als den PN/PN-Koppler gibt, dann stören gleiche IP-Adressen nicht. Es ist ja kein Routing über den PN/PN-Koppler möglich.

Harald

 

[PeterPan-35]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zur Zeit möchten wir nur eine Materialanwahl, welche an der Maschine A gewählt wurde an Maschine B auswerten, sodass wir nur an Maschine A eine Änderung dieser machen müssen.
Wird jedoch nur mit Maschine B gefahren, also Maschine A ist ausgeschaltet, soll die CPU nicht auf Stop gehen. Die Produktion soll ohne eingreifen zu müssen fortgesetzt werden.

Also wollen im Grunde 2 autonome Maschinen, welche getrennt voneinander ausgeschaltet werden können betreiben. Wenn ich ein Bit setze (Kommunikation EIN) sollen beide miteinander sprechen können.

Ist das möglich?
Dafür ist der Koppler unseres Wissens eigentlich von Siemens gedacht?

 

[PeterPan-35]

Könnte man da evtl mit dem SCF12 lösen und den Koppler über das Bit (Kommunikation EIN) ein-/ausschalten.

Programmtechnisch die Verwendung der Koppler Eingänge durch überspringen in AWL bei ausgeschalteter Kommunikation umgehen?

 

[PeterPan-35]

Das soll SFC12 heißen.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Den CPU-Stop verhindern ist einfach, dazu muß man nur im Diagnosepuffer schauen, welcher OB angefordert wird und diesen OB in die CPU laden. Daß an der CPU SF rot leuchtet kann man ja ignorieren - man kann aber auch das verhindern, indem man mit dem SFC12 den PN/PN-Koppler deaktiviert.

Programmtechnisch reicht es aber tatsächlich schon, wenn man nicht mehr auf den PN/PN-Koppler zugreift, also die Abfrage der Eingänge und Zuweisung der Ausgänge überspringt und ggf. mit Ersatzwerten belegt. Wenn die E/A im Prozessabbild liegen dann braucht man nichts überspringen, man muß nur beachten daß die Eingangssignale ungültig sind.

Wieviele Signale sind es denn, die zwischen den Maschinen ausgetauscht werden sollen?
Wenn es nur ein paar Bit sind, dann ist es programmtechnisch viel einfacher und auch viel billiger, einfach ein paar Koppelrelais zwischen die Steuerungen zu schalten.

Harald

 

[PeterPan-35]

Zur Zeit sind es nur ein paar Bits. Aber später soll es um eine Produktverfolgung erweitert werden. Momentan sind es nur Vorbereitungsarbeiten um das ganze Fehlerfrei ans laufen zu bekommen.

 

[PeterPan-35]

Die Fehler OBs die gefordert wurden, habe ich schon geladen. Doch der meckert jetzt am Programm rum. Da werde ich wohl die nicht mehr verfügbaren Eingänge für diesen Fall ausblenden müssen.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Man kann auch ohne PN/PN-Koppler Daten zwischen den Maschinen austauschen, z.B. über eine S7-Verbindung oder eine ISO-on-TCP- oder TCP-Verbindung, und hat dann die Reaktion auf Verbindungsausfall voll selber in der Hand, ohne rote SF und BF und Fehler-OB. Weil dazu die Steuerungen direkt über Ethernet gekoppelt werden, dürfen dann aber nicht mehr doppelte IP-Adressen vorkommen.

Außer über Ethernet/Profinet kann man auch über Profibus oder MPI oder eine serielle Verbindung Daten austauschen.

Was für CPUs hast Du denn?

Harald

 

[PeterPan-35]

Ja das weiß ich [emoji6]

Aber was will man machen, wenn der Vorgesetzte sowas haben will. [emoji1]

 

[140434_Tom]

Hallo ich würde die Eingang komplett in einem Aufruf in einen DB kopieren. Wenn ich dann die Kommunikation nicht benötige den Aufruf vom Kommunikation FB verhindern und eventuell die Werte mit Ersatz werten belegen
Dann kann das übrige Programm so bleiben

Gesendet von meinem HUAWEI NXT-L29 mit Tapatalk

 

[PeterPan-35]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo, ich werde am Montag einige Varianten ausprobieren.

Heute und morgen mache ich mir noch einige Gedanken und stelle diese dann einmal hier vor, obs so machbar wäre.

Aber schonmal danke an alle für die Antworten

 

[PeterPan-35]

Falls es jedoch immer noch zu Sammelfehlern kommt, die ich nicht nachvollziehen kann, stelle ich Montag einmal einen Auszug des Diagnosepuffers ein.

Gegen Ende kam es wie weiter oben schon geschrieben zu merkwürdigen Fehlern in Bausteinen, die nichts mit E/As des Kopplers zutun haben.

 

[RONIN]

Gegen Ende kam es wie weiter oben schon geschrieben zu merkwürdigen Fehlern in Bausteinen, die nichts mit E/As des Kopplers zutun haben.

Bei sowas zeigst du am besten den Diagnosepuffereintrag und den zuehörigen Code-Teil. Dann wird man eher sehen woher es kommen könnte.
Viellicht auf die HW-Konfig des Kopplers.

 

[PeterPan-35]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo, hier bin ich noch einmal.

Die Maschinen laufen jetzt wie sie sollen, die meisten OBs, welche die CPU letzte Woche vergeblich gesucht hat und wir eingefügt haben, konnte man wieder entfernen.

Der Übeltäter war der OB 82.

Also sind nun nur noch OB82 und OB83 im Programm. Die Anlagen laufen komplett unabhängig von einander. Ohne einen Fehler in irgendeinen FC/FB anzuzeigen. Ein SF wird dennoch angezeigt, hat aber keine Auswirkungen auf den Ablauf der Prozesse.

Aber Danke an alle Antworter für eure Hilfe