TIA Ausfall PN Teilnehmer mit S7-312C und CP342-1 erkennen

Feuerreiter

Level-2
Beiträge
23
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo, an einer S7-312C mit CP341-1 hängt ein Profinetteilnehmer den ich überwachen muss .
Leider gibt es den OB86 nicht. Ein Watchdog ist ebenfalls nicht vorhanden bzw. ich hab kein Bit das immer True ist um mir einen Watchdog selbst zu bauen. Kann ich den Ausfall des PN Teilnehmers mit dem Diagnose OB82 überwachen bzw. Kommfehler OB 87 ? Es handelt sich bei dem PN Teilnehmer um ein Distanzlaser von SICK DL100.

Gruß Sebastian
 
Zuletzt bearbeitet:
Vermutlich meinst Du nicht CP341-1 und auch nicht CP342-1 sondern CP343-1 ?
Welche Bestellnummer hat der CP genau? 6GK7343-............?

Ich habe noch keinen CP343-1 als Profinet IO Controller verwendet, aber ich vermute, Du kannst von den FC PNIO_RECV und PNIO_SEND die Ausgänge CHECK_IOPS und IOPS auswerten und/oder FB54 PNIO_ALARM verwenden.

Falls ein OB für eine Diagnose/Meldung verwendet werden kann/muss: Welchen OB Du verwenden musst, findest Du im Diagnosepuffer der CPU bei der Diagnosemeldung über den Ausfall/das Problem - falls der Ausfall/das Problem überhaupt von der CPU gemeldet wird. Einfach den Ausfall der Hardware hervorrufen (z.B. Kabel abziehen) und schauen, was in den Diagnosepuffer geschrieben wird.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vermutlich meinst Du nicht CP341-1 und auch nicht CP342-1 sondern CP343-1 ?
Welche Bestellnummer hat der CP genau? 6GK7343-............?

Ich habe noch keinen CP343-1 als Profinet IO Controller verwendet, aber ich vermute, Du kannst von den FC PNIO_RECV und PNIO_SEND die Ausgänge CHECK_IOPS und IOPS auswerten und/oder FB54 PNIO_ALARM verwenden.

Falls ein OB für eine Diagnose/Meldung verwendet werden kann/muss: Welchen OB Du verwenden musst, findest Du im Diagnosepuffer der CPU bei der Diagnosemeldung über den Ausfall/das Problem - falls der Ausfall/das Problem überhaupt von der CPU gemeldet wird. Einfach den Ausfall der Hardware hervorrufen (z.B. Kabel abziehen) und schauen, was in den Diagnosepuffer geschrieben wird.

Harald
Hallo Harald, danke für deine Rückantwort. Ich habe mal als Anhang Screenshots hinterlegt.
 

Anhänge

  • Gerätekonfig_S7_312.jpg
    Gerätekonfig_S7_312.jpg
    285,8 KB · Aufrufe: 44
  • OBs_S7_312.jpg
    OBs_S7_312.jpg
    167,6 KB · Aufrufe: 45
Ich habe mal als Anhang Screenshots hinterlegt.
Die Screenshots zeigen absolut nichts von dem Profinet IO System :confused:
Sie zeigen aber: Deine "S7-312C" ist gar keine 312C sondern eine 312 (ohne C) :rolleyes:
Mann-o-Mann, bitte mehr Sorgfalt! Willst Du genauso schlampige Antworten wie Deine Beiträge?

Bei der 1200/1500er gibt es den Devicestate......bzw. den OB86.....diesen habe ich allerdings nicht zur Verfügung.
OB86 gibt es nur bei CPUs mit DP- oder PN-Schnittstelle. Teilnehmer-Ausfall/Wiederkehr am Profinet IO System eines CP343-1 wird nicht mit OB86 signalisiert (auch dann nicht, wenn die CPU den OB86 hätte bzw. unterstützen würde).

Aktuell hängt an dem CP nur ein HMI 1200 Basic PN dran.
???
Was ist mit dem Profinet IO Device SICK DL100? Das sollte doch am Profinet IO System des CP343-1 dran hängen? Läuft das schon am Profinet IO?

Was ist denn nun Deine Frage? Willst Du nur wissen wie Du einen Teilnehmerausfall erkennen kannst, oder weißt Du nicht, wie Du den CP343-1 und den SICK DL100 projektieren und programmieren sollst?

Teilnehmerausfall:
Kann es im Betrieb vorkommen, daß vom SICK DL100 komplett alle Eingangsbits 0 sind, oder ist immer wenigstens irgendein Eingangsbit 1 ?
Kannst Du notfalls das Modul 30 (Serial No, 8 Bytes) als Eingangsmodul einfügen? Die Serial No wird sicher nicht 0 sein, da könntest Du den Teilnehmerausfall einfach daran erkennen, wenn die 8 Bytes komplett auf 0 gehen.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Screenshots zeigen absolut nichts von dem Profinet IO System :confused:
Sie zeigen aber: Deine "S7-312C" ist gar keine 312C sondern eine 312 (ohne C) :rolleyes:
Mann-o-Mann, bitte mehr Sorgfalt! Willst Du genauso schlampige Antworten wie Deine Beiträge?


OB86 gibt es nur bei CPUs mit DP- oder PN-Schnittstelle. Teilnehmer-Ausfall/Wiederkehr am Profinet IO System eines CP343-1 wird nicht mit OB86 signalisiert (auch dann nicht, wenn die CPU den OB86 hätte bzw. unterstützen würde).


???
Was ist mit dem Profinet IO Device SICK DL100? Das sollte doch am Profinet IO System des CP343-1 dran hängen? Läuft das schon am Profinet IO?

Was ist denn nun Deine Frage? Willst Du nur wissen wie Du einen Teilnehmerausfall erkennen kannst, oder weißt Du nicht, wie Du den CP343-1 und den SICK DL100 projektieren und programmieren sollst?

Teilnehmerausfall:
Kann es im Betrieb vorkommen, daß vom SICK DL100 komplett alle Eingangsbits 0 sind, oder ist immer wenigstens irgendein Eingangsbit 1 ?
Kannst Du notfalls das Modul 30 (Serial No, 8 Bytes) als Eingangsmodul einfügen? Die Serial No wird sicher nicht 0 sein, da könntest Du den Teilnehmerausfall einfach daran erkennen, wenn die 8 Bytes komplett auf 0 gehen.

Harald
Hallo Harald....der Rest läuft....alles eingebunden...kein Problem.


Wenn jeder so schlau wäre wie du, dann bräuchte man dieses Forum auch nicht. 😜

Ich bin nicht mit der 300er Serie aufgewachsen. Auch mit einem CP hatte ich bis dato nicht zu tun. Ich habe mich im Vorfeld schon bei Google ausgetobt. Bin erst seit 2020 auf Siemens umgestiegen. Hatte die letzten Jahre nur mit Mitsubishi zu tun.

Natürlich kann ich das Modul 30 einfügen....

Ja..und meine Frage war in der Überschrift schon gestellt...ich möchte einen Ausfall des PN Teilnehmers der am PN-Netz des CP dranhängt erkennen und auswerten.
 
:unsure: Kein Bit, das immer TRUE ist? Notfalls selber machen.
Aber ein Bit, das immer TRUE ist, macht doch irgendwie auch keinen Sinn für einen WatchDog? Was habe ich denn jetzt falsch verstanden?
Ja....ein Lebensbit welches immer True ist macht auch schon sinn. Denn anders als eine Toggle-Abfrage auf high und low, schiebe ich das Eingangsbit in einem DB rein. Dann setze ich dieses Bit am Ende des Bausteins wieder auf False. Sollte die Verbindung abbrechen, dann bleibt dieses Bit auf "False". Ist die Verbindung o.k., wird dieses Bit am Anfang des Bausteins wieder "True" gesetzt. ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

die S7-300 hatten Systemzustandslisten ("SZL"). Diese wurden in S7-1500 durch DeviceStates/ModuleStates ersetzt.

***edit***: die SZL enthält bei den 300ern wohl nix zu den CPs. Der Hinweis von User "PN/DP" zu FB54 "PNIO_ALARM" führt vermutlich besser zum Ziel als eine Suche in der SZL.


****alt****:
Auf die Schnelle habe ich

"Teillisten für S7-Kommunikation und PROFINET

Baugruppenzustandsinformationen in
PROFINET IO

SZL_ID Teilliste
0591H Baugruppenzustandsinformationen aller Submodule
0A91H Baugruppenzustandsinformationen aller PN IO-Subsysteme
0C91H Baugruppenzustandsinformationen einer Baugruppe"

im Handbuch "Operationsliste S7-300" gefunden.

Ich habe das selbst noch nie probiert, aber die zitierten Angaben deuten darauf hin, dass Zustandsinformation möglicherweise abrufbar sein könnten. Andererseits sagt Beitrag
, dass für CP keine Daten in der SZL stehen.

Die SZL lässt sich mit dem Befehl RDSYSST (SFC51) auslesen.

Gruss
pe
 
Zuletzt bearbeitet:
@poitouesel
Es geht hier um einen CP343-1 als Profinet IO Controller. Da werden für dessen Profinet IO System keine SZL in der CPU geführt.

Ja....ein Lebensbit welches immer True ist macht auch schon sinn. Denn anders als eine Toggle-Abfrage auf high und low, schiebe ich das Eingangsbit in einem DB rein. Dann setze ich dieses Bit am Ende des Bausteins wieder auf False. Sollte die Verbindung abbrechen, dann bleibt dieses Bit auf "False". Ist die Verbindung o.k., wird dieses Bit am Anfang des Bausteins wieder "True" gesetzt. ;)
Das Setzen eines Eingangsbits im DB auf True oder False ist völlig unnötig, weil beim nächsten Aufruf des FC PNIO_RECV werden sämtliche Eingangsbits im DB (der CPU-lokalen Kopie der Zustände des CP) mit dem tatsächlichen Zustand aus dem Prozessabbild des CP überschrieben. Der FC PNIO_RECV wird üblicherweise zyklisch in jedem OB1-Zyklus aufgerufen.
So 'rum wird ein Schuh draus: wenn ein Profinet IO Device ausfällt, dann setzt der Profinet IO Controller (hier der CP343-1) sämtliche Eingangswerte des Device im Prozessabbild auf 0 (genauso wie ein Profibus DP Master die Eingangsdaten vom ausgefallenen DP Slave löscht). Beim nächsten Aufruf des FC PNIO_RECV werden die Eingangsdaten aus dem CP in die CPU in den DB kopiert und sind dann im DB ebenfalls 0. Ist das IO Device wieder erreichbar, dann werden wieder die vom IO Device empfangenen Eingangszustände kopiert. Wenn da Eingangswerte dabei sind, wo immer irgendeines der Bits 1 ist (z.B. die Seriennummer), dann braucht nur der Eingangswert auf gleich/ungleich 0 überwacht werden. Es muß nicht ein bestimmtes Bit immer 1 sein, es reicht wenn z.B. in einem Byte immer mindestens ein Bit 1 ist (das 1-Bit könnte auch im Byte rotieren). Es könnte auch ein sich ändernder Zählerstand oder ein Temperatur-Messwert sein, wenn der im Betrieb niemals 0 wird.

Harald
 
Zuletzt bearbeitet:
Für CP343-1 als PN IO Controller verwendet man PNIO_SEND und PNIO_RECV.
Es gibt auf diese Bausteine die Ausgangparameter IOCS und IOPS. Die sollte ein Status-bit enthalten für jeden IO-Byte.
Und es gibt auch die CHECK_IOCS und CHECK_IOPS damit man erkennen kann ob alles i.O ist oder mindestens 1 Byte schlecht ist.

edit: Dies ist von STEP7 Klassik. Keine Ahnung ob es funktioniert gleich in TIA.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@poitouesel
Es geht hier um einen CP343-1 als Profinet IO Controller. Da werden für dessen Profinet IO System keine SZL in der CPU geführt.


Das Setzen eines Eingangsbits im DB auf True oder False ist völlig unnötig, weil beim nächsten Aufruf des FC PNIO_RECV werden sämtliche Eingangsbits im DB (der CPU-lokalen Kopie der Zustände des CP) mit dem tatsächlichen Zustand aus dem Prozessabbild des CP überschrieben. Der FC PNIO_RECV wird üblicherweise zyklisch in jedem OB1-Zyklus aufgerufen.
So 'rum wird ein Schuh draus: wenn ein Profinet IO Device ausfällt, dann setzt der Profinet IO Controller (hier der CP343-1) sämtliche Eingangswerte des Device im Prozessabbild auf 0 (genauso wie ein Profibus DP Master die Eingangsdaten vom ausgefallenen DP Slave löscht). Beim nächsten Aufruf des FC PNIO_RECV werden die Eingangsdaten aus dem CP in die CPU in den DB kopiert und sind dann im DB ebenfalls 0. Ist das IO Device wieder erreichbar, dann werden wieder die vom IO Device empfangenen Eingangszustände kopiert. Wenn da Eingangswerte dabei sind, wo immer irgendeines der Bits 1 ist (z.B. die Seriennummer), dann braucht nur der Eingangswert auf gleich/ungleich 0 überwacht werden. Es muß nicht ein bestimmtes Bit immer 1 sein, es reicht wenn z.B. in einem Byte immer mindestens ein Bit 1 ist (das 1-Bit könnte auch im Byte rotieren). Es könnte auch ein sich ändernder Zählerstand oder ein Temperatur-Messwert sein, wenn der im Betrieb niemals 0 wird.

Harald

Funktioniert alles...........habe die Überwachung mit der Auswertung der IOPS des FC PNIO_RECV umgesetzt.

Bei uns im Betrieb haben wir unzählige CPU´s (ET200SP) mit denen wir untereinander putten und getten.
Für die Watchdogüberwachung hat jede CPU ein Lifebit......da ist es nämlich so, das das Lifebit beim Verbindungsabbruch high bleibt.
Daher setzen wir dieses Lifebit immer wieder "false" zurück. Das der CP343-1 beim zyklischen Abruf und einem Ausfall des PN den DB in der CPU mit "0" füllt hatte ich bis dato nicht ausprobiert bzw. gewußst......trotzdem danke.....

Schönes Wochenende euch allen
 
Zurück
Oben