Fehlersuche bei M340 ModbusTCP-Kommunikation

[shevek]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich versuche gerade, irgendwie dahinter zu kommen, warum die Kommunikation zwischen zwei M340-Steuerungen über ModbusTCP nicht mehr funktioniert - und wo und wie ich an Fehlercodes o.ä. herankomme. Das Netzwerk zwischen den beiden Steuerungen scheint mir als Fehlerursache ebenso auszufallen wie die Ethernet-Schnittstelle selbst, denn über dieselbe Hardware läuft die Kommunikation mit der Visualisierung, und auch die Kommunikation mit Unity. Und das funktioniert alles. Nur weigern sich die beiden Steuerungen neuerdings - ohne (bewusste) Software-Änderung - die Daten, die sie schon mal miteinander ausgetauscht haben, weiterhin auszutauschen.
Ich habe das über den READ_VAR-Baustein realisiert, der die Adresse als ADDM mitgeteilt bekommt. Wie gesagt: es hat schon mal funktioniert, zuckt aber neuerdings nicht mehr: sämtliche Bits, ob nun Aktivität, Austausch, Kommunikation oder auch Betrieb, bleiben konsequent 0. Und was die Fehleranzeige angeht, hab ich wohl Tomaten auf den Augen, denn ich finde keine Hat mir hier wer 'nen Tipp?

Viele Grüße

Michael

 

[winnman]

geh mal mit der unity online auf die Steuerung und dann auf die Baugruppe mit der du die TCP Kommunikation am laufen hast (NORE oder direkt aus der CPU?) dann solltest du auch jeweils den Status sehen (da ist irgendwo so ein Feld mit vielen Kästchen).

Bist du sicher dass da nichts geändert wurde, ev. auch ein Port auf einem Router / Switch gesperrt von der IT oder . . .

 

[holgermaik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo
Dein Aufbau sollte ungefähr so aussehen:



Die Parameterbeschreibung findest du hier

Holger

 

[shevek]

Vielen Dank für Eure Hinweise.

Der Aufbau sieht ungefähr so aus wie von Holger gezeigt Nur dass ich den EN-Eingang mitbenutze, weil ich mal irgendwo gelesen habe, dass man diesen Baustein nicht im Dauerbetrieb nutzen soll. Deshalb immer nur, wenn das Aktivitätsbit 0 ist, eine neue Anfrage starten.
- Bei einer funktionierenden Abfrage sieht das dann so aus, dass die Managementparameter mehrere Infos - wie auch z.T. in dem pdf von Holger enthalten - liefern. Da gibt's ein Aktivitäts-Byte, das immer schön von null nach eins und wieder zurück wechselt. Ein "Austausch"-Byte, das die Aktivitäten, sprich: Austauschvorgänge hochzählt. Und ein Kommunikations- sowie ein Betriebsbyte, die jeweils null sind, solange alles tut, wie es soll.
Bei mir ist es jetzt so, dass bei dieser einen SPS sozusagen "ums Verrecken" keine Aktivität mehr auftreten will. Das Bit ist null, und es bleibt null. Kommunikation und Betrieb sind ebenfalls konstant null, aber das ist ja nicht mal weiter verwunderlich
Was die Sache mit den Ports betrifft: da die zentrale Leittechnik ebenfalls über ModbusTCP mit der SPS kommuniziert, und brav alle Daten bekommt, die sie bekommen soll, sollte der Port ja eigentlich noch funktionieren, oder??? (Läuft alles über die Schnittstelle der CPU. Eine NOE ist nicht verbaut.)
Mit anderen Worten: die SPS spricht nach wie vor über die Ethernet-Verbindung sowohl mit Unity als auch mit der zentralen Leittechnik und dem Panel vor Ort. Nur an die andere SPS gibt sie keine Daten her. - Ich hab extra noch mal geschaut, ob ich vielleicht versehentlich selbst bei der Nachrichtenübertragung eine Zugriffskontrolle aktiviert habe. Aber dem ist nicht so.
Nun gibt es tatsächlich was, das sich geändert hat: seit einiger Zeit werden über den Switch mehr Geräte angebunden. Da sind noch ein paar Siemens-CPUs dazu gekommen, die über die gleiche Verbindung mit der zentralen Leittechnik reden. Haben aber einen komplett anderen Adressbereich, an doppelten IP-Adressen dürfte es also nicht liegen. Außerdem denke ich halt, dass, wenn es an so was liegt, gar keine Kommunikation mehr geht.
Ein online-Blick auf die Ethernet-Schnittstelle mit Unity zeigt übrigens nur, dass jede Menge Nachrichten gesendet und empfangen werden, aber keine Hinweise auf irgendwas ungewöhnliches.
Im Debug-Fenster von Unity kann auch ein Kommunikationstest via ping gemacht werden - auch der wird erfolgreich bestanden. Bei wiederholten Versuchen mit Zeiten zwischen 18 und 26 ms, was für meine Anforderungen reichen sollte. Bin gerade etwas ratlos

 

[holgermaik]

Kannst / darfst du einen Port Scan durchführen. Ist der Port 502 auf allen Geräten die die Kommunikation weiterleiten frei?
Unity arbeitet auf einem anderen Port als die Kommunikation zwischen den 340. Welche Visu benutzt du.
Holger

Nachtrag:

Mit den CPUs des Typs BMX P34 20x0 können Sie folgende Aufgaben ausführen:
Verwalten der TCP-Verbindungen mithilfe von Port 502-Messaging:
Server (32 Verbindungen)
Clients (16 Verbindungen)
Transparent Device Access (2 Verbindungen)

Hast du die Verbindungsanzahl überschritten?

 

[shevek]

Zuviel Werbung?
-> Hier kostenlos registrieren

Einen Portscan durchführen darf ich. Ob ich kann, ist noch mal 'ne andere Frage Wie auch immer: die Visu vor Ort ist ein Magelis-Touchpanel von Schneider, die zentrale Leittechnik ist zenon. Beide sind über ModbusTCP auf Port 502 angebunden und beklagen sich derzeit nicht über Kommunikationsprobleme. Anbei ein aktueller screenshot der Ethernet-Verbindung der SPS. Es sind 3 "offene Verbindungen", aber da hab ich bei anderen M340ern mehr...

 

[shevek]

Portscan hat ergeben: bei allen M340-Steuerungen sind jeweils drei Ports offen: 21 (ftp), 80 (http) und 502 (Modbus). - Es ist also bei allen, die den READ_REG-Baustein nutzen, gleich. Nur dass sich nicht alle damit abfragen lassen :-( Ich habe inzwischen offen gestanden Zweifel, dass die Kommunikation schon mal irgendwann funktioniert hat - nur wenn sie das nicht haben sollte: wieso stehen in den Steuerungen, die Abfragen durchführen sollen, Werte in den abzufragenden Variablen drin? Müssten doch sonst lauter nullen sein, oder? - Ich blick's grad echt nicht!

 

[shevek]

Habe jetzt mal spaßeshalber den nicht funktionierenden Programmteil 1:1 in eine andere M340 kopiert. Und siehe da: dort funktioniert die Abfrage! Sprich: die lesende SPS hat das Problem, nicht die abgefragte! Jetzt stellt sich also nur noch die Frage: wie bekommt man eine "gestorbene" READ_VAR-Funktion wieder zum Leben erweckt???

 

[shevek]

Zuviel Werbung?
-> Hier kostenlos registrieren

Okay, Problem gelöst! - Gestehe: ich komme mir ein bisschen verarscht vor. Aber solange es funktioniert...
Des Rätsels Lösung bestand darin, das Array, das am GEST-Eingang und -Ausgang des Bausteins angeschlossen wird, durch ein neues Array zu ersetzen!
Nun denn... ein schönes Wochenende allerseits!

 

[Noobi30]

Ja es ist schonmal interessant, woran es liegt.
Hatte auch mal probleme beim Konvertieren von Concept nach Unity. Der hat mir immer einen fehler mit einem Read_Reg Baustein gemacht. Letztendlich den Baustein gelöscht und nochmal neu eingesetzt. Und auf einmal war alles fehlerfrei

 

[shevek]

Hm. Dass beim Konvertieren solche Fehler auftreten, erscheint mir ja noch zumindest möglich. Aber bei einer "frisch" programmierten Steuerung und mitten aus dem laufenden Betrieb heraus...??? Die Fragen, die sich mir im Moment stellen, sind: taucht dieses Phänomen irgendwann wieder auf? Und was war letztlich die Ursache dafür? Lässt sich das dauerhaft abstellen? ...? - So ganz glücklich bin ich nicht damit, wie es im Moment läuft.

 

[holgermaik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also ich kenne ähnliches Verhalten wenn recht häufig Online Änderungen durchgeführt werden. Dabei scheint es irgendwann Probleme mit dem fragmentierten Speicher zu geben.

Wenn du möchtest, lade dein Projekt doch mal hoch.

Holger

 

[shevek]

Das Phänomen von Problemen mit fragmentiertem Speicher kenne ich bis jetzt nur von mit Concept programmierten CPUs. Dass die M340 mit Unity das gleiche Problem haben könnten, wäre mir neu - ist aber natürlich nicht ausgeschlossen :-( Wobei es, wenn ich mir das recht überlege, nicht infrage kommt. Denn zumindest die eine der beiden betroffenen CPUs hat bisher herzlich wenig Programmänderungen erfahren, und auch kein allzu großes Programm drin.
Bei der zweiten CPU trat das Problem gestern schon wieder auf. Mir fiel dann allerdings auf, dass es evtl. ungünstig ist, wenn man gleichzeitig eine Schreib- und eine Leseanforderung an die gleiche Zieladresse startet (einmal READ_VAR und einmal WRITE_VAR, gestartet mit der steigenden Flanke eines Blinktakts). Nimmt man stattdessen für den einen die steigende und für den anderen die fallende Flanke, läuft die Kommunikation deutlich besser. Vielleicht lag's ja auch daran?