Step 7 Kommunikationsaufbau zu Janitza UMG 96 PA MID mittels interner Schnittstelle

Hallo zusammen,

ich habe leider ein Problem mit der Einbindung eines Janitza in eine ältere Anlage, möglicherweise hat jemand einen guten Tip.

Folgender Aufbau:
1x Janitza UMG 96 PA MID
1x CPU317-2 PN/DP 317-2EK14-0AB0 V3.2.8

und einmal:

1x Janitza UMG 96 PA MID
1x CPU317-2 PN/DP 317-2EK13-0AB0 V2.6.5

Programmiert sind beide mit Step7 V5.6.

Bei beiden Aufbauten ist das Janitza direkt per Ethernetkabel an die interne Schnittstelle der CPU angesteckt.

Ich möchte mit einem Baustein per TSEND/TREC/TCON/TDISCON die Kommunikation mittels Modbus TCP herstellen, um bestimmte Register für unsere BDE auszuwerten.
Der Baustein an sich funktioniert, da es bei der CPU mit der 2EK14 genau wie gewünscht funktioniert.

Leider bleibt bei der 2EK13 der TCON-Baustein auf Status 7002, ein Blick in die Hardware-Diagnose verrät auch, dass das am Port nichts erkannt wird, siehe Bild:



Ich hatte zuerst das Kabel im Verdacht, allerdings kann ich mit diesem Kabel das Janitza von meinem PG anpingen, sowie auch die SPS auf der internen Schnittstelle. Trotzdem habe ich vorsichtshalber mal das Kabel getauscht, aber leider das gleiche Ergebnis. Bin irgendwie grade ziemlich ratlos, was das Problem sein könnte. Hatte auch noch die interne Schnittstelle im Verdacht, aber ich denke durch den erfolgreichen Ping, sollte diese auch in Ordnung sein. Diagnosepuffer sagt auch nichts negatives, Fehler LEDs leuchten auch nicht.

Bin über jeden Rat dankbar

UDP schrieb:

CPU317-2 PN/DP 317-2EK13-0AB0 V2.6.5

Zum Vergrößern anklicken....

Empfehlung: mache zunächst das Firmware-Update zu V2.6.12 (da werden noch andere schlimme Fehler beseitigt) und schaue danach ob das Problem verschwunden ist
Tausche trotzdem mal das Ethernet-Kabel, auch mal ein gekreuztes Kabel falls Du sowas hast. Und schalte mal testweise einen Switch dazwischen - in der endgültigen Anwendung wird doch bestimmt auch ein Switch dazwischen sein?

Harald

da werden noch andere schlimme Fehler beseitigt

Zum Vergrößern anklicken....

Ja, von der V2.6.5 zur V2.6.12 werden folgende Punkte beseitigt:

V2.6.7

• Das Problem Aktualwertverlust im laufenden Betrieb mit Ereigniskennung 16#6523 und Z2=8020 / Z3=1410 wurde behoben.
• Bei Forcen gehen ab sofort keine Weckalarme mehr verloren.

• Durch schnelles Scrollen beim Beobachten von Bausteinen bzw. Variablentabellen kommt es nicht mehr zum Defekt Z1=6A6F.
• Am FB65 „TCON“ kommt nicht mehr die Fehlerkennung 80B3, wenn mehrere TCP-Verbindungen mit gleicher IP-Adresse und gleichem remoten Port programmiert sind.

• Wenn bei Einstellung "OB85-Aufruf bei Peripheriezugriffsfehler --> Nur bei kommenden und gehenden Fehlern" ein fehlender DP-Slave bzw. ein fehlendes PNIO-Device, dessen Adressen im Prozessabbild liegen, deaktiviert wird, dann erlischt ab sofort neben der BF-LED auch die SF-LED.

• Die Anweisung "RND" liefert bei einem AKKU1-Wert <x.75> ab sofort korrekt den Wert <x+1>.

V2.6.12

• Beim Hochlauf eines über PN/PN-Koppler verbundenen Mehr-CPU-Systems mit projektierten Mischsubmodulen, kommt es nicht mehr zur sporadischen Störung der Mischmodule "Modul nicht verfügbar".
• Verbindungen der CPU zu einem AG-Link-Gerät werden nun bei Verbindungsabbrüchen vollständig abgebaut.
• Bei schnellem Wechsel zwischen "Fortsetzen" und "Single Step" geht die CPU nicht mehr in Defekt mit Z1=F402 (sporadisch auch mit Z1=64D9).
• Der SFC1 "READ_CLK" wandelt ab sofort die Jahreszahl immer korrekt in eine BCD-Zahl. Nachfolgende auf das BCD-Format aufsetzende Anweisungen (z.B. BTI „BCD-To-Integer“) führen somit nicht mehr zu Wandlungsfehlern (z.B. Ereignis-ID 16# 2521 „BCD-Wandlungsfehler).
• Nach NETZ-EIN kommt es nicht mehr sporadisch zum Aktualwertverlust nach Urlöschen mit Event-ID 16#6522 bzw. 16#4580 ( Backup-Pufferinhalt inkonsistent ).
• Beim Beobachten von Bausteinen bzw. Variablen und gleichzeitig angeschlossen B&B-Bediengeräten kommt es nicht mehr sporadisch zum Defekt Z1=97EA bzw. 6E22.
• Bei Kommunikationsproblemen mit externen HMI-Systemen z.B. ProSCADA bzw. bei Verwendung des CP343-1EX11 kommt es nicht mehr zum Defekt Z1=98C6.
• Der SFC 24 "TEST_DB" liefert nun bei vorhandenem DB, immer die korrekte Länge des DB, unabhängig von dessen Speicherattribut oder wenn parallel der SFC83 aufgerufen wurde.
• Beim Vorstellen der Uhrzeit wird nun in den Lokaldaten des OB10 der Wochentag ( Variable "OB10_DATE_TIME" ) sofort aktualisiert.
• Fehlerhafte Längenangaben bei ANY-Pointern der SFC’s 20 und 21 führen nun zu BLF (Bereichslängenfehler: 8x22 oder 8x23), dadurch werden Folgeprobleme wie Zykluszeitüberschreitung und Watchdog verhindert.

Zum Vergrößern anklicken....

Ein TCON Fehler wurde auch beseitigt, ob der hier mitverantwortlich ist. Ich denke nicht. Aber ich würde auch wie Harald schon schrieb, ein FW-Update unbedingt durchführen.

Danke euch beiden erstmal, FW-Update werde ich dann Donnerstag durchführen und in dem Zusammenhang gleich mal schauen, ob es mit einem Switch funktioniert.

Eigentlich ist der Aufbau bei der Anlage so gedacht, die CPUs haben noch einen CP dran für die restlichen Teilnehmer und die MES Anbindung. Der Port war frei für ein lokales Netz, dass war mit dem wenigsten Aufwand verbunden im Vergleich zum "offiziellen" IP-Adressen beantragen bei der IT.

UDP schrieb:

Ich hatte zuerst das Kabel im Verdacht, allerdings kann ich mit diesem Kabel das Janitza von meinem PG anpingen, sowie auch die SPS auf der internen Schnittstelle.

Zum Vergrößern anklicken....

Leuchten die Link-LEDs an den Ethernet-Ports der 317 und des UMG96, wenn das Kabel an beiden Geräten gesteckt ist?
Probiere mal ein Überkreuzkabel/Crossover-Kabel zwischen 317 und UMG96. Ich weiß nicht, ob die 317 oder das UMG96 Auto-crossover können. Wenn es beide nicht können, dann wird ein Überkreuzkabel/Crossover-Kabel benötigt. Zwischen PG/Notebook und anderen Geräten kann man normale Patchkabel oder Crossover-Kabel verwenden, weil der Port im PG/Notebook das Auto-crossover beherrscht - daher funktioniert der Ping/das Kabel zwischen PG und 317 bzw. PG und UMG.

Harald

Ne Link LEDs leuchten nicht. Dann schaue ich mal, ob ich noch irgendwo ein Crossover-Kabel aufgetrieben kriege. Erstmal schauen, ob hier vielleicht schon die Lösung dabei war.

Kurze Rückmeldung: Es funktioniert jetzt, das Crossoverkabel war die zündende Idee. Vielen Dank euch beiden

UDP schrieb:

Kurze Rückmeldung: Es funktioniert jetzt, das Crossoverkabel war die zündende Idee.

Zum Vergrößern anklicken....

Vielen Dank für die Rückmeldung.
Wenn man immer über Switche vernetzt, dann braucht man das nicht beachten, die Switche machen das Crossover. Wenn man aber in seltenen Fällen mal direkt verbindet, dann muß man an Crossover denken.

Harald