TIA PN-Signale bei Busausfall nicht Null ???

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Anlage besteht aus einer 1512SP als Controller und mehreren 1214C als IO-Device. Das Netzwerk besteht aufgrund größerer Entfernungen aus einem Glasfasernetz. Die Verbindung zu mindestens einem IO-Device ist z.Z. noch instabil, s.d. es unregelmäßig zu kurzen Kommunikationsabbrüchen kommt. Die Fehlersuche im Netzwerk betrifft mich nicht, ich bin hier nur das Opfer. Ich habe in diesem Zusammenhang jedoch festgestellt, dass gesetzte PN-Eingänge am IO-Device und in Folge diverse Ausgänge bei Verbindungsabbruch gesetzt bleiben! Ich gehe/ging bei Profinet wie auch bei Profibus davon aus, dass bei Verbindungsabbruch alle Signale generell auf FALSE bzw. NULL fallen, zumindest nach Default-Einstellungen. Die 1214C verwende ich nur als einfache dezentrale Peripherie. Im Programm rangiere ich lediglich die lokalen Peripherie-Adressen auf die PN-Adressen bzw. anders herum. Hierfür verwende ich der Einfachheit halber UDTs als ARRAY of Byte direkt in den Variablentabellen. Die eigentliche Symbolik existiert nur im Controller. Das komplette Programm in der 1214C besteht nur aus dem OB1 und einer FC1 und sieht so aus:




Nebenfrage:
Eine S7 als einfache dezentrale Peripherie verwenden, geht das auch irgendwie einfacher? Ich meine, vom Controller direkt auf die dezentralen Adressen zugreifen, ohne dieses Mammutprogramm?

Hauptfragen:
Warum werden die Eingangssignale bei Verbindungsabbruch nicht zu Null?
Eine Classic-S7-CPU als DP-Slave geht ohne div. Fehler-OBs in den STOP-Zustand. Warum macht das die 1214C als IO-Device nicht?
Habe ich irgend welche Einstellungen dezent ignoriert?

Equipment:

• TIA-Portal V15.1
• Controller: CPU 1512SP-1 PN, V2.5
• IO-DeviCe: CPU 1214C DC/DC/DC, V4.2

Nachtrag 1:
Ich habe gerade beim Durchsehen festgestellt, dass der FC1 der betroffenen 1214C versehentlich "optimiert" ist. Bei den anderen gleichartigen 1214C ist das nicht der Fall. Kann das der Grund des ganzen Desasters sein? Kann das vielleicht auch für die Netzwerkprobleme verantwortlich sein? Die Netzwerkprobleme äußern sich wie folgt. Am IO-Device kommen Diagnoseeinträge wie "IO-Device XYZ ist nicht erreichbar" XYZ ist zwar der Controller, aber was soll's. Ein dauerhafter Ping von meinem PG über das Netz zum Controller setzt unregelmäßig für gefühlte 2s bis 4s aus.

 

[ChristophD]

Hi,

bei PN spielen die Nutzdatenbegleiter eine Rolle, die sagen ob die Daten gültig sind oder nicht (BAD oder GOOD), je nach dem werden dann die Daten vom Device verarbeitet oder aber auch nicht.
Denke eher nicht das die DB eine Auswirkung für das PN haben.
Was den Stop betrifft.
Ja hier ist die Philosophie bei S7-1200/S7-1500 genau umgekehrt zur S7-300.
Egal was passiert , ein STOP ist immer zu vermeiden, daherbleiben die CPU auch immer in RUN und du kannst mit den bekannten Fehler OB lediglich in Deinem Program was merken wenn es nicht stimmt.

Gruß
Christoph

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

.. bei PN spielen die Nutzdatenbegleiter eine Rolle, die sagen ob die Daten gültig sind oder nicht (BAD oder GOOD), je nach dem werden dann die Daten vom Device verarbeitet oder aber auch nicht..

Ok, dann muss ich hier wohl irgendwie umdenken. Das ist aber hoffentlich nicht bei gewöhnlichen Devices (ohne CPU) der Fall?

Denke eher nicht das die DB eine Auswirkung für das PN haben...

Das verstehe ich jetzt nicht. Ich habe keinen DB im Programm, nur einen FC, in dem auf Hardware-Adressen zugegriffen wird. Aber der Punkt "optimiert" hat sich wohl erledigt.


​

Was den Stop betrifft.
Ja hier ist die Philosophie bei S7-1200/S7-1500 genau umgekehrt zur S7-300.
Egal was passiert , ein STOP ist immer zu vermeiden, daherbleiben die CPU auch immer in RUN und du kannst mit den bekannten Fehler OB lediglich in Deinem Program was merken wenn es nicht stimmt...

Über das Netzwerkproblem bin jetzt richtig happy ! Und über deine Antwort auch! Über diese PN-Signale werden u.a. Verriegelungen für größere Pumpen übertragen. Es gibt zwar noch weitere Sicherheitsmaßnahmen wie Überdruckschalter, aber das ist dann auch schon die letzte Instanz.

 

[Onkel Dagobert]

Ich war heute wieder an der Anlage und hatte nach einer langen störungsfreien Phase wieder Netzwerkprobleme. PN-Teilnehmer waren sporadisch ausgefallen. Diese Ausfälle haben eindeutig mit meinen Aktivitäten an Netz zu tun. Unter dringendem Tatverdacht steht der fucking SmartClient, den ich zum Zugriff auf ein TP1200 laufen hatte. Kennt jemand derartige Effekte?

 

[Ingmar64]

Also wir verwenden bei Inbetriebnahmen und bei Fernwartung ständig Smart@Server auf den Panels, mal mit Original Smart@Client, mal mit VNC-Client. Bisher ohne Probleme.
Zu ähnlichen Problemen (willkürlich gesetzte Ausgänge an IO-Devices) führte bei uns aber mal eine routinemäßige Switch-Wartung (Konfigurationsänderung, evtl. auch Firmwareupdate) der Halleninstallation.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

[FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]Bei dem Sm@rtClient habe ich in letzter Zeit so meine Zweifel. Bei meinem aktuellen Problem spielt er aus heutiger Sicht aber wohl doch nur eine kleine Nebenrolle. Meine Ermittlungen, welche nur nebenbei erfolgen, brachten einen weiteren Tatverdächtigen zum Vorschein. Es handelt sich um einen PC, welcher an dem Switch angestöpselt wurde, an dem meine LWL-Verbindungen zusammen laufen. Dieser PC überträgt angeblich zeitweise größere Datenmengen nach irgend wo hin. Mit etwas materialtechnischem Glück wird morgen mein Profinet vom Rest getrennt. Ich hoffe, das war's dann.[/FONT]

 

[Blockmove]

Meine Ermittlungen, welche nur nebenbei erfolgen, brachten einen weiteren Tatverdächtigen zum Vorschein. Es handelt sich um einen PC, welcher an dem Switch angestöpselt wurde, an dem meine LWL-Verbindungen zusammen laufen. Dieser PC überträgt angeblich zeitweise größere Datenmengen nach irgend wo hin. Mit etwas materialtechnischem Glück wird morgen mein Profinet vom Rest getrennt. Ich hoffe, das war's dann.[/COLOR][/FONT]

Bei uns gibt es eine klare Regelung:
Kein Profinet auf einem "normalen" IT-Netz.
Eigentlich ist, wenn genügend Sachverstand vorhanden ist, der Mischbetrieb kein Problem.
Vernünftige Netzwerkkomponenten haben genügend Konfigurationsmöglichkeiten (QoS, VLAN, ...).
Aber eine Fehlkonfiguration und du bekommst die richtig ekelhaften sporadischen Fehler.
Wenn irgendjemand meint, dass er Daten aus der Anlage braucht, dann gibt's ein Gateway zur Kopplung.

Gruß
Blockmove

 

[vollmi]

Ich war heute wieder an der Anlage und hatte nach einer langen störungsfreien Phase wieder Netzwerkprobleme. PN-Teilnehmer waren sporadisch ausgefallen. Diese Ausfälle haben eindeutig mit meinen Aktivitäten an Netz zu tun. Unter dringendem Tatverdacht steht der fucking SmartClient, den ich zum Zugriff auf ein TP1200 laufen hatte. Kennt jemand derartige Effekte?

Was hast du denn für Aktualisierungs und Ueberwachungszeiten bei deinen Teilnehmern eingestellt?
Standard sind die recht scharf finde ich

Gerade wenn du Switches oder gar Medienwandler mit Ring und dergleichen hast und die sich rekonfigurieren kann es gut sein das die überwachungszeit anspricht.
Und IMHO macht es meistens keinen Sinn das die Geräte innert 300ms abhängen wenn da nur n paar sensoren dran hängen.

mfG René

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Netze sind heute getrennt worden. Es lief dann auch den ganzen Tag stabil.

Was hast du denn für Aktualisierungs und Ueberwachungszeiten bei deinen Teilnehmern eingestellt?..

Ich hatte gestern den Wert "Akzeptierte Aktualisierungszyklen ohne IO-Daten" von 3 auf 10 geändert. Gebracht hatte es aber nichts. Alles andere steht noch auf den Standardeinstellungen. Ich hatte schon viel umfangreichere Anlagen, die mit den Standardeinstellungen problemlos liefen. Es wäre nicht aus zu denken, wenn ich dort derartige Probleme gehabt hätte. Schätze, ich wäre mit Betonschuhen auf dem Grund der Weißen Elster gelandet.


​

Gerade wenn du Switches oder gar Medienwandler mit Ring und dergleichen hast und die sich rekonfigurieren ..

Kann ich so etwas irgend wie erkennen bzw. nachweisen?

Bei uns gibt es eine klare Regelung:
Kein Profinet auf einem "normalen" IT-Netz...

So kannte ich das von bisherigen Anlagen auch. Von den Konfigurationsmöglichkeiten der Switche habe ich überhaupt keine Ahnung, der Errichter des Netzwerks vermutlich auch nicht. Der hat die Teile auch nur in sein Rack geschraubt und angeschlossen. Ich werde mich wohl mal mit solchen Dingen beschäftigen müssen.


​

 

[acid]

Kann ich so etwas irgend wie erkennen bzw. nachweisen?

Schwierig, eigentlich ist das für dich transparent, auch wenn STP/RSTP (Redundante Links) im Spiel sind.

So kannte ich das von bisherigen Anlagen auch. Von den Konfigurationsmöglichkeiten der Switche habe ich überhaupt keine Ahnung, der Errichter des Netzwerks vermutlich auch nicht. Der hat die Teile auch nur in sein Rack geschraubt und angeschlossen. Ich werde mich wohl mal mit solchen Dingen beschäftigen müssen.
​

​

Profinet kann man durchaus an die normale Infrastruktur hängen, aber man muss hier eben einige Dinge beachten. Getrenntes VLAN und scharfe Firewallregeln sind eine Grundvoraussetzung, damit der normale LAN-Traffic das Profinet nicht stören kann und keine unberechtigten Teilnehmer dazwischenfunken können.
Soll PN-IO über die Infrastruktur laufen, kann es zusätzlich erforderlich sein, QoS bzw. Trafficpriorisierung zu nutzen, aber davon würde ich eher absehen. Bei Problemen mit dezentraler Peripherie hängt wieder alles an der IT, und die sind ja bekanntlich nie schuld.