Step 7 I-Device Kommunikationstrennungfehler ignorieren

W

wbach

Level-1
Beiträge
84
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen,

für mein Projekt werde ich eine mobile SPS einsetzen mit der über die I-Device Option. Dabei habe ich eine übergeordnete SPS (IO-Controller) und mehrere I-Device Teilnehmer die nach Belieben an verschiedenen Orten angeschlossen werden können.
Da die mobilen SPSen mobil sind, werden sie nicht immer am Industrial Ethernet Netz hängen. Demnach werden erhalten die SPSen (IO-Controller und I-Device Teilnehmer) Busfehlermeldungen.
Gibt es eine Möglichkeit diese Fehlermeldungen zu ignorieren?

LG Waldemar
 
wbach schrieb:
Gibt es eine Möglichkeit diese Fehlermeldungen zu ignorieren?
Zum Vergrößern anklicken....
Ja - einfach ignorieren ;) das machen wohl die meisten Programmierer...

Damit die CPU nicht in STOP geht, müssen die relevanten Fehler-OB auf der CPU vorhanden sein: OB122 und OB82/OB85/OB86, evtl. OB5x ...
Man kann zusätzlich die I-Devices im I-Controller mit SFC12 D_ACT_DP deaktivieren, dann kommen auch keine roten Fehler-LEDs mehr.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Harald,
vielen Dank für die schnelle Antwort. Leider bekomme ich das nicht so hin wie gedacht.
Die OBs sind alle hinzugefügt. Bei dem SFC12 habe ich dir Eingänge folgendermaßen Belegt:

REQ := I200.0 (I-Device Eingang / Geforced auf 1)
MODE: B#16#2 (Aktivieren von DP-Slaves/PROFINET IO-Devices)
LADDR: W#16#64 (PROFINET-IO-System (100))

Ausgänge zeigen:
RET_VAL: -32621
BUSY: 1

Beim Trennen des Patchkabels, fällt die Verbindung weg und REQ fällt auf 0.
Könnt Ihr mir sagen was ich hierbei falsch gemacht habe?

LG Waldemar
 
Bei LADDR kommt üblicherweise eine E- oder A-Adresse oder die Diagnoseadresse des Teilnehmers hin, den man aktivieren/deaktivieren will (siehe Bausteinhilfe mit F1). Und an REQ kann man natürlich NICHT eine Adresse des zu aktivierenden Moduls hinschreiben, die ist ja nicht erreichbar wenn deaktiviert oder abgezogen.

Wenn I200.0 auf 1 geforced ist, wie kann dann I200.0 bzw. REQ auf 0 fallen??

weitere Hinweise zu D_ACT_DP

Harald
 
Vielen Dank nochmal für Deine Hilfe. Ich finde es ist etwas ungenau in der Hilfe erwähnt mit dem LADDR.

Im Internet habe ich auch gelesen das man nur 4 SFC12 einsetzen kann und sich viele darüber streiten was damit gemeint ist. Weißt Du, ob damit 4 SFC pro PROFINET Strang oder 4 SFC pro I-Device gemeint ist?

Ich werde ca. 60 mobile SPSen haben. Die werden zwar nie alle auf einmal im Einsatz sein aber ich denke im Hochbetrieb werden bestimmt 10 zum Einsatz kommen.

Danke und LG
Waldemar
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Gemeint ist, wieviele SFC12-Aufträge man gleichzeitig auf der CPU ausführen kann.
Dazu steht im vierten FAQ in meiner oben verlinkten Hinweisliste
Wie oft kann ich die Systemfunktion SFC12 "D_ACT_DP" gleichzeitig aufrufen?
SFC12 kann in den S7-300 CPUs mit interner DP-Schnittstelle bis zu viermal gleichzeitig aufgerufen werden. Bei den S7-400 CPUs kann SFC12 gleichzeitig bis zu viermal pro DP-Strang (interne und externe) aufgerufen werden.
Zum Vergrößern anklicken....
Versucht man zu viele SFC12-Aufträge gleichzeitig auszuführen, dann melden die zu vielen SFC12-Instanzen an RET_VAL den Fehler 80C3 (siehe Bausteinhilfe mit F1)

SFC12-Aktivierungs-/Deaktivierungs-Aufträge müssen nur bei Änderungen ausgeführt werden (REQ = 1) bis der Auftrag erfolgreich abgeschlossen ist (BUSY = 0 und RET_VAL = 0 gemeldet wird). Dein Programm wird sicher irgendwie wissen, welche I-Devices vorhanden sein müssen - die muß es dann "auf Knopfdruck" oder automatisch (nacheinander) (einmalig) aktivieren und aktive aber nicht benötigte I-Devices deaktivieren.

Bei S7-300 kann man Aktivierungsaufträge abbrechen, bei S7-400 können SFC12-Aufträge nicht abgebrochen werden.

Was für eine CPU und eventuell CP hast Du eigentlich?

Harald
 
IO-Controller: CPU319F-3 PN/DP (318-3FL01-0AB0)
I-Device: CPU315F-2 PN/DP (315-2FJ14-0AB0)

Es werden aber sicherlich andere CPU zur verwendung kommen, da das Projekt noch ziemlich frisch ist. Vermutlich werden wir aber eine 300ter als Master und ET200SPs als Slave nutzen. Wie gesagt, es ist noch nicht festgelegt.

Als Alternative kann ich auch die TCON/TDISCON (FB65/FB66) glaube ich nutzen, wo ich gerade dran bin. Weißt Du hierzu auf die schnelle auch was?

Vielen Dank für die Unterstützung und LG Waldemar
 
TCON/TDISCON haben nichts mit Profinet I-Device zu tun. TCON/TSEND/TRECV/TDISCON haben mit sogenannte "offene TCP Kommunikation" zu tun. Das ist eine ganz andere Geschichte.
Wenn es um austausch von zyklische Daten handelt, dann bleib doch bei Profinet I-Device. Es ist einfach, zuverlässig und performant. Das aktivieren und deaktivieren mit SFC12 funktioniert sehr einfach.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn Du die CPUs per PROFINET-IO als IO-Controller+I-Device koppelst, dann nützen Dir TCON/TDISCON nichts, weil die sind für selbst programmierte Verbindungen ("Offene Kommunikation" TCP/UDP/ISO-on-TCP). Verbindungen mit in HW Konfig projektierten I-Devices können nur mit SFC12 D_ACT_DP aktiviert/deaktiviert werden.

Wenn Du noch sehr wenig Ahnung von Ethernet-Kommunkation mit S7 hast, dann empfehle ich mal einen Blick in das Kompendium "CPU-CPU Kommunikation mit SIMATIC Controllern", siehe die FAQ: Linkliste SIMATIC-Kommunikation über Ethernet in meiner Signatur.

Harald
 
Wenn meine mobile SPS (I-Device) nicht verbunden ist, kann ich doch mit dem TCON eine Verbindung simulieren indem ich über den FB_input "CONNECT" meine SPS-Daten (I-Device / Mobile SPS) zusende. Demnach wird der SF auf der SPS nicht mehr angezeigt. Liege ich da mit meiner Annahme richtig?

Sry, für die vielen Fragen und LG
Waldemar
 
wbach schrieb:
Wenn meine mobile SPS (I-Device) nicht verbunden ist, kann ich doch mit dem TCON eine Verbindung simulieren [...] Demnach wird der SF auf der SPS nicht mehr angezeigt. Liege ich da mit meiner Annahme richtig?
Zum Vergrößern anklicken....
Nein.
Die SF-LED leuchtet, weil projektierte IO-Hardware ausgefallen ist und weil drauf zugegriffen wird.

Das Vorhandensein von ausgefallenen PROFINET-IO-Device kann man nicht durch andere Verbindungen "simulieren". Es kommt nicht darauf an, daß Daten ankommen, sondern daß die PROFINET-IO-Devices zyklisch per PROFINET-IO-Protokoll mit dem IO-Controller kommunizieren. Um den ganzen Verbindungsaufbau und zyklischen Datenaustausch kümmert sich das Betriebssystem der CPUs (des IO-Controllers und der I-Devices), das PROFINET-IO-System muß nur projektiert werden (in HW Konfig). Danach greift man einfach auf die projektierten EA-Adressen zu.

Alternativ anstatt der Projektierung als PROFINET-IO kannst Du Deine Daten auch per "offener Kommunikation"-Verbindungen (ISO-on-TCP-/TCP-/UDP-Verbindungen per Send/Receive) oder per S7-Verbindungen (PUT/GET/BSEND/...) mit den I-Devices austauschen. Dann kommen keine roten Fehler-LEDs mehr, Du mußt aber selber jeden Verbindungsaufbau und das Senden/Empfangen auf den CPUs programmieren (TCON/TSEND/TRECV, PUT/GET/BSEND/...).

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Harald, vielen Dank für Lösung.

Ich werde die Alternative wählen und über die "offene Kommunikation" die Daten austauschen.

Ich gehe mal davon aus das bei den TCON/TDISCON... keine FB Begrenzung gibt?
Und sind die FBs mit der ganzen SIMATIC 300 Reihe / SIMATIC 1500 Reihe vorhanden?

Letzte Frage :) und LG

Waldemar
 
Harald,
liege ich mit meiner Annahme richtig das ich die "Fehler" (SPS LED) auch maskieren kann mit den Bausteinen SFC36/SFC37/SFC38?
Der Fehlercode "EreignisID" in der Diagnostik ist 16#39CB.

LG Waldemar
 
Zuviel Werbung?
-> Hier kostenlos registrieren
nein - siehe Referenzhandbuch "System- und Standardfunktionen für S7-300/400" Kapitel 11 und 35.4 oder die Step7-Hilfe zu den Systemfunktionen
Es können nur Programmier- und Zugriffsfehlerereignisse (Synchronfehlerereignisse) maskiert werden, welche OB121 oder OB122 auslösen.

Das Ereignis W#16#39CB "PROFINET IO-Stationsausfall" ist ein Asynchronfehlerereignis und löst OB86 aus.

Harald
 
Danke, Harald.
Ein riesen Programmieraufwand für 60 mobile SPSen, nur damit man das gewollte nicht als Fehler sieht :(
 
Tja, das ist unser Job. :cool: Und jeder kann es so umständlich lösen wie er lustig ist. ;)

Also ich meine, das aktivieren/deaktivieren von 60 IO-Devices mit SFC12 ist einfacher als 60 Verbindungen zu programmieren.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Harald,
ich gebe Dir da völlig Recht das es einfacher ist. Dies habe ich auch schon an SPSen erfolgreich getestet.
ABER :D
Problem 1:
Ich werde keine weitere Hardware erkennung habe, die sagt das die SPS wieder angeschlossen ist und muss eine zyklische Abfrage starten nach XX Zeit. Da es aber 60 SPSen sind, werden die Abfrage eigentlich immer stattfinden und ich denke das ich da Probleme bekommen werden mit den 4 mal BUSY Signal.
Problem 2:
Bei den TCON/TDISCON habe ich die Verbindung zu den SPSen über eine eigene Subnetz-Maske und dann noch über einen Router. Zudem kenne ich den Port nicht für den local_tsap_id im CONNECT DB und bis jetzt immer noch keine Kommunikation geschafft habe.

:(
 
Weiß die Anlage nicht, welche mobile Station jeweils vorhanden sein MUSS? Soll sich die Anlage einfach nur durch plug'n'play konfigurieren? Vielleicht spendierst Du noch einen Taster oder HMI-Button, welcher das aktivieren aller gerade vorhandenen Devices startet/versucht. Oder kann für die verschiedenen Zusammenschaltungsvarianten eine Liste der Muss-vorhanden-sein-Stationen hinterlegt werden?

Woher weiß die Anlage, daß der Ausfall irgendeiner Station OK ist und auf keinen Fall als Fehler dargestellt werden soll, der Ausfall einer anderen Station aber nicht tolerierbar ist?

Bei offener Kommunikation: Was soll passieren, wenn z.B. mehr als 30 Stationen angesteckt sind? Dann wird die CPU 319F vielleicht für wichtige mobile Stationen keine Verbindungsressourcen mehr frei haben, wenn sie Verbindungen zu unnötigen Stationen aufrecht erhält. Bei PROFINET-IO sind 60 gleichzeitig vorhandene Stationen kein Problem, andererseits werden die Stationen bestimmt "wild" sternförmig zusammengestöpselt - eine PROFINET-Topologie kann man da vergessen. Wenn Deine Stationen in verschiedenen IP-Range-Subnetzen mit Routern dazwischen liegen, dann geht PROFINET-IO gar nicht.

Deine Augabe ist schon ganz schön anspruchsvoll. Vermutlich ist die Verwendung der selbstprogrammierten offenen Kommunikation in Deinem Fall tatsächlich besser als PROFINET-IO, aber leider auch aufwendiger zu programmieren. Gefühlsmäßig würde ich ISO-on-TCP-Verbindungen empfehlen. Für eine kontrollierte übersichtliche Planung der vielen Verbindungen und Verbindungsparameter solltest Du Dir mal den "Open Communication Wizard" ansehen (ich hoffe, der kann so viele Verbindungen verwalten).

Harald
 
Harald,
1. Ich werde für alle möglichen Stationen Stecker vorbereiten die eine bestimmte Pinbelegung haben. Dies wird dann über die Übergeordnete SPS kommuniziert und dann in der Leitebene gesendet, was als Standort gilt.
2. HMI-Buttons bringen mir nicht viel, weil die SPS keine Verbindung zur Leitebene hat und somit die Panels nur mit jeder mobilen SPS kommunizieren. (2 Servere :( )
3. Die mobile SPS weiß das sie ok ist, vom Operator. Den sie wird nicht von der Leitebene bedient. Sondern nur von dem Operator vor Ort.
4. Werde wahrscheinlich weitere übergeordnete SPSen vorschlagen die im Notfall die funktionen auch von den anderen SPSen übernehmen.
5. Open Communication Wizard gucke ich mir mal an, was auch immer das ist :D

Und ja, ich bin seit kurzen in der Automatisierungstechnik. :D

Das Thema TON/TDISCON bereitet mir am meisten Sorgen, da es schon anspruchsvoll ist.

LG Waldemar
 

Similar threads

H
TIA I-Device Kommunikation
2
Antworten
22
Aufrufe
3K
ChristophD
ChristophD
H
Netzwerktopologie mit I-Device
Antworten
8
Aufrufe
6K
maxder2te
M
W
TIA Kommunikation zwischen mehreren I-Device partnern
Antworten
18
Aufrufe
7K
ChristophD
ChristophD
PrincipalSkinner
TIA I-Device Kommunikation über verschiedene Netze mit statischem Routing möglich?
Antworten
6
Aufrufe
6K
van
V
J
TIA I-Device über einen Router
Antworten
10
Aufrufe
2K
ChristophD
ChristophD
Zurück
Oben