Spanning Tree Protokoll

[Eleu]

Hallo,

ich hätte mal ein paar Fragen zum Spanning Tree Protokoll.

Ein Spanning-Tree-Frame ist in der Lage eine Reorganisation auszulösen und das gesamte Netzwerk für 30 Sekunden oder mehr lahmzulegen.

Während dieser Zeit dürfen die Spanning Tree fähigen Switches

außer Spanning Tree-Informationen keine Pakete im Netz weiterleiten.

Wenn innerhalb dieser Zeit eine PC - Station Telegramme versendet,

stellt sich mir die Frage was mit diesen Telegrammen passiert ?

Landen die in einer Auslagerungsdatei auf dem PC oder wie wird das dann

abgefangen ?

Kann man mit Wireshark herausfinden ob eine Rekonfiguration

im Netz ausgelöst wurde ?

Ich würde gerne mit einem am Switch angeschlossenen Laptop

versuchen diese mögliche Rekonfiguration mit zu sniffern.

Ich würde folgende Filtereinstellungen in Wireshark vornehmen:

- Ich gebe keine IP - Adresse an

- Im Filter wähle ich UDP und Port 167

Wären diese Einstellungen richtig ?

Wie sähe denn ungefähr das SNMP Frame bei einer Reorganisation aus ??

Ich bin im Bereich der Automatisierungstechnik tätig und

habe deshalb nicht unbedingt weitreichende Informatik - Kenntnisse.

Ich bitte vorab schon mal um Entschuldigung ,

wenn ich nicht sofort alles verstehe und nochmals nachfrage..

Vielen Dank im Voraus

Gruß

Eleu

[Crash2001]

[...]Kann man mit Wireshark herausfinden ob eine Rekonfiguration im Netz ausgelöst wurde ?

Ja kann man. Anhand der configuration BPDU Pakete. Das sind Pakete, die nur die Root Bridge aussenden kann und die afaik nur bei einer Änderung des netzes gesendet werden.

[...]Wie sähe denn ungefähr das SNMP Frame bei einer Reorganisation aus ??[...]

Wieso SNMP-Frame? Das müsste wenn explizit auf dem Switch erst konfiguriert werden, dass der dann ein SNMP-Paket losschickt, dass sich was geändert hat.

Aufbau des Configuration BPDU siehe hier unter dem Punkt BPDU.

Ansonsten schau mal hier.

[Eleu]

Hallo Crash2001,

vielen Dank für die Hinweise...

Das mit dem SNMP, da habe ich wohl selbst was durcheinander gebracht.:confused:

Habe gedacht, dass es das Protokoll ist, was die root bridge

bei einer Rekonfiguration verwendet.

Is ja quatsch.

Es wir ja STP oder RSTP genutzt.

Ich habe jetzt rausgefunden, dass man in wireshark bei Filter

einfach nur STP eingeben muss. Dann werden nur BPDU`s

bei einer Rekonfiguration mitgesniffert.

Habe auch herausgefunden wie das BPDU Paket

dann aussehen muss (Siehe Dateianhang)

Vielen Dank nochmal und wenn Du oder sonst jemand

noch ergänzende Infos geben kann, würde ich mich freuen.

Gruß

Eleu

[VaNaTiC]

Wenn Deine Frage soweit geklärt ist, dann würde ich gern eins zwei Sachen wissen, die nicht ganz OnTopic sind.

Ich arbeite auch im Automatisierungsbereich (Gebäude, Tunnel, Verkehr) und durfte selber schon (negative) Erfahrungen mit STP, RSTP und propietären Ring-Protokollen sammeln.

Ist das ein "echtes" Problem, oder ein Testszenario?

Denn STP ist für ein Automatisierungssystem viel zu langsam, selbst RSTP taugt noch nicht wirklich.

Wir haben bis jetzt immer auf die propietären Protokolle gesetzt, wie Hiper-Ring von Hirschmann oder Derivate von EKS (naja) und Phoenix (ok).

Bei EKS hatten wir z.bsp. mal ein Firmware-Problem, dass unsere Leitrechner erst neue ARP-Requests ausführen mussten, wenn sich der Ring reinitialisiert hatte. Lauter so nette Dinge, die man nicht haben will

[DocInfra]

Sofern möglich verzichtet auf ®STP. OSPF hat, bei kleinen Konfigurationen, eine Konvergenzzeit von ca. 3 Sekunden. Evtl. wäre das eine Lösung, also Redundanzen über OSPF zu eliminieren. Allerdings bin ich, was Automatisierungstechnik angeht, nicht wirklich fit. Da gelten ja aufgrund von Echtzeitfunktionen ganz andere Regeln.

[VaNaTiC]

In einem typischen Szenario eines RABT-Tunnels bauen etwa 10-15 LWL-Koppler einen redundanten Ring auf. Und dabei sind Rekonfigurationszeiten von unter 100ms notwendig.

[DocInfra]

Da kannst du alles, was es für "normale" Netzwerke auf dem Markt gibt, vergessen. Da bleiben nur noch proprietäre Lösungen.

[Eleu]

Wie wäre es, wenn man im Switch die STP oder RSTP ausschaltet

und nur mit der sogenannten Loop Detektion arbeitet.

Also der Switch sendet ein Frame und wenn das zurück kommt

gibt es eine Schleife.

Über z.B. das SNMP bekommt der Admin dann eine Meldung....

Dann hätte man zwar eine Schleife, aber zumindest keine Unterbrechung des

Netzwerkes durch eine Rekonfiguration.

Wäre das ein denkbares Szenario ?

Was kann denn eine Schleife so im schlimmsten Fall anrichten ?

Was sind denn proprietäre Lösungen ?:confused:

Bearbeitet 1. März 2009 von Eleu

[VaNaTiC]

Propietäre Lösungen sind inkompatible, nicht dem Standard entsprechende, von einem Hersteller entwickelte Lösungen für dieses Problem:

- Hiper-Ring von Hirschmann,

- Fast-Ring-Detection und erweiterte Switchanzahl von Phoenix Contact,

- Turbo-Ring von Moxa,

- EKS, SIEMENS und andere haben auch alle mehr oder weniger tolle Erweiterungen, Verbesserungen.

Bei einer Schleife laufen sich sämtliche Netzwerkpakete tot und das macht den Ring innerhalb kürzester Zeiten taub und stumm.

[Crash2001]

Sofern möglich verzichtet auf ®STP. OSPF hat, bei kleinen Konfigurationen, eine Konvergenzzeit von ca. 3 Sekunden. Evtl. wäre das eine Lösung, also Redundanzen über OSPF zu eliminieren. [...]

Das geht aber ja nur, wenn man Layer3-Links hat und nicht bei Layer2-Links.

Wie wäre es, wenn man im Switch die STP oder RSTP ausschaltet und nur mit der sogenannten Loop Detektion arbeitet.

Also der Switch sendet ein Frame und wenn das zurück kommt

gibt es eine Schleife.

Über z.B. das SNMP bekommt der Admin dann eine Meldung....

dann müsste der Port automatisch wieder hochgeschaltet werden periodisch oder manuell. Und wenn dann noch eine Loop wäre, würde das doch wieder zu unterbrechungen führen. Ansonsten würde die Verbindung komplett abbrechen. Wäre also mehr Aufwand für den Switch als mit ®STP.

[...]Was kann denn eine Schleife so im schlimmsten Fall anrichten ?[...]

Einen Broadcaststurm auslösen und das gesamte Segment des Netzwerks lahmlegen z.B.? Oder falls der Switch nicht genug Rechenleistung hat auch direkt den gesamten Switch schnell mal lahmlegen, weil Broadcasts bei einer Schleife immer und immer wieder neu verteilt werden.

Solange der Switch die MAC-Adressen kennt, an die er senden soll, sollte ein Loop kein Problem darstellen. Aber sobald er eine MAC-Adresse nicht kennt, schickt er das Paket an allen seinen Switchports, bis auf den, über den er es empfangen hat, raus, und bekommt es dann über den jeweils anderen Port des Loop wieder rein. Wenn zwei Verbindungen existieren, bekommt der Switch das gleiche Paket dann doppelt so oft wieder zurück (Port 1 schickt das Paket an Port 2 und umgekehrt) und verteilt es wieder genauso. er geht ja davon aus, dass das Netz loopfrei ist und somit Pakete die er über einen Port bekommt nicht von ihm selber stammen können. Das steigert sich schön schnell hoch mit der Anzahl der Pakete...

1->2->4->8->16->32->64->128->256->512->1.024-> ...

Und sollte es nicht nur eine doppelte, sondern dreifache Verbindung sein, ist der Faktor dabei nicht 2, sondern direkt 6. (Port 1 sendet an Port 2 und 3, Port 2 an 1 und 3 und Port 3 an 1 und 2)

1->6->36->216->1.296->7.776->46.656->279.936-> ...

man sieht, das kann sich ganz schön schnell hochschaukeln...

Dagegen hilft dann zwar die Storm-Control, aber die muss auch erst mal konfiguriert sein und wo es mit STP doch ein Protokoll gibt, das Links verhindert, sollte man es auch benutzen, wenn man Layer2-Links verwendet.

Ich meine zudem, dass der Loopguard ein Part von ®STP ist und das wenn es abgeschaltet ist gar nicht funktioniert dürfte. Die Loop-Detection funktioniert ja anhand dessen, ob auf einem Port BPDUs empfangen werden oder nicht, wenn ich das richtig im Gedächtnis habe.

Bearbeitet 2. März 2009 von Crash2001

[Eleu]

Erst mal vielen Dank für die umfangreichen Antworten.

Wir haben das Phänomen, dass die Performance einer PC Station

die über Ethernet auf eine SPS zugreift mit der Zeit immer mehr in die Knie geht.

(CPU Auslastung dann bei 100% oder die Auslagerungsdatei voll...)

Nach dem Neustarten des Rechners ist dann erst mal alles wieder in Ordnung.

Wir wissen nicht woran das liegt und meine Vermutung war, ob es hier nicht einen

Zusammenhang mit ®STP geben könnte.

Aber wenn der Switch Telegramme blockt oder nicht weiterleitet

dann werden diese Telegramme doch einfach gelöscht

und nicht etwa ausgelagert ?

Kann es denn da einen Zusammenhang geben oder

bin ich auf dem völlig falschen Dampfer ?

[VaNaTiC]

Hmm, das klingt nach einem anderen Problem. Der IP-Stack heute ist relativ intelligent.

Geprüft werden muss auf alle Fälle, welche Dienste nach einer Zeit die gesamte CPU belasten.

Was ist das genau für ein Ethernet-Protokoll, ich glaube nicht, dass ihr direkt auf OSI 1 geht

Ich hab beispielsweise Ether-S-Bus (UDP über Port 5050) direkt native implementiert, weil alle SAIA-Treiber und OPC, alles zu langsam und nicht flexibel ist.

Wenn dem OSI-7 Protokoll der per Ethernet angebundenen SPS das TCP/IP zu grunde liegt, können diverse Fehlerchen in der Implementierung selber Ursache sein. Auch mit UDP kann man Fehler machen, aber zum Glück nur einen Teil

Schonmal an ein Memory-Leak gedacht? Halb-Offene oder Halb-Geschlossene Verbindungen gecheckt? Zum Beispiel mal ein netstat -a (alles anzeigen) und/oder netstat -s (summary).

Der PC hat aber definitiv garnix mit dem Ring-Protokollen am Hut, außer wie ich erwähnt hatte, bei uns einmal mit EKS-Switchen, dass die Rechner erst neue ARP-Requests ausführen mussten. Aber dann bekommt man garkeine Verbindung nach Rekonfiguration.

Also wie gesagt, meine Vermutung: Speicherüberwachung, CPU-Überwachung und die Wurzel des Übel auf dem PC prüfen.

[Eleu]

Also verwendet wird TCP/IP zu einer SPS aber auch

das ISO Transportprotokoll (Layer 2; Mac - Adressiert)

zu einer weiteren SPS.

OPC läuft da auch, zu einer 3ten SPS.

Ich weis aber nicht, welches Kommunikationsprotokoll

für den OPC-Server da abläuft.

Fakt ist, dass die CPU -Auslastung kurzzeitig immer zyklisch auf 100% springt

wenn gleichzeitig ereignisgesteuert eine erhöhte Kommunikation via OPC erfolgt.

Das Programm "sqlservr.exe" nutzt im Normalbetrieb den meisten

Speicher aus (65.988 KB)

Ansicht über "Task Manager / Prozesse"

Du schreibst:

Schonmal an ein Memory-Leak gedacht? Halb-Offene oder Halb-Geschlossene Verbindungen gecheckt? Zum Beispiel mal ein netstat -a (alles anzeigen) und/oder netstat -s (summary).

Kannst Du mir das näher erklären.

Was muss man da machen ?

Was ist ein Memory Leak ?

[Crash2001]

[...]Was ist ein Memory Leak ?

Ein Speicherleck.

Ich denke mal er meint damit eine Anwendung, die durch einen Fehler in der Programmierung (oder einen sonstigen Bug) immer weiter Speicher anfordert und keinen Speicher mehr wieder freigibt, so dass sie immer mehr und mehr belegt.

[Eleu]

Also man muss "netsat -a" eingeben über Start / Ausführen

dann wird mir was in der MS-Dos Umgebung angezeigt.

Ich weis aber nicht wie ich das deuten soll

oder worauf ich da nun speziell achten soll

(Sieht alles ganz normal aus).

Gibt es denn eine Möglichkeit zumindest die Anwendung heraus-

zufiltern die eventuell diesen Bug hat ?

Zwischenzeitlich habe ich mal mitgesniffert.

Also verwendet wird bei uns das STP.

Es kommen alle 2 Sek. "Hello Pakete"

Für alle die es vielleicht interessiert:

Man muss im Filter von wireshark

"stp.type == 0x80"

eingeben, wenn man nur die eventuelle Reorganisation sniffern will

Genannt: Spanning Tree Topology Change Notifications (TNC)

Mal sehen ob da irgendwann mal was passiert.

[VaNaTiC]

Genau, wie Crash2001 sagte.

1) Fakt ist, Du solltest definitiv als erstes herausfinden, welcher Prozess das System nach einer gewissen Zeit belastet.

Zum Beispiel bevor das System neu gestartet wird mittels Process Explorer von SysInternals prüfen. Wichtig sind, solche Sachen, wie CPU-Zeit, Context-Switches, Handles, Threads, Page-Faults, Virtual-Size, Private Bytes.

Das sind zusätzliche Spalten zum Anzeigen.

2) wie oben beschrieben netstat -a und -s ausführen. Am besten per pipe in eine Datei netstat -a > alles.txt und netstat -s > summary.txt

2) Dann solltest Du konkret analysieren, wie schnell und eventuell wodurch der Wert ansteigt. Bitte vergleichen, ob Netzwerk/Socket-Probleme eventuell im Zusammenhang mit Speicherzuwachs einher gehen.

3) Und wichtig wäre zu wissen, von welchen Fabrikaten und Typen wir hier reden.

4) Du solltest bedenken, dass die meisten OPC-Implementierungen die unterlagerten Steuerungen nur abpollen!!! D.h. alle x-Zeiteinheiten wird der komplette Datenhaushalt abgeholt und im OPC-Server auf Änderungen geprüft und dann die Änderungen als Event getriggert.

Das machen beispielsweise auch alle großen großen SCADA-Lösungen, wie WinCC oder PVSS2 so. Das kann dann schon dauern, je nach Größe des Datenhaushalt und der Verbindung.

Meine persönliche Meinung ist leider, dass OPC nur durch die Qualität der Treiber- bzw. Protokollimplementierungen funktioniert. Und die ist leider nicht immer gut, kompatibel zu verschiedenen OS oder fremder Software.

[Eleu]

Ich habe den Prozess Explorer runtergeladen und ihn so auf der

PC-Station eingerichtet wie Du es beschrieben hast.

Wenn sich die PC - Station weghängt mach ich mal ein Screenshot vom Prozess - Explorer

und stell das Bild dann hier rein.

Ich wäre dir dankbar, dass wenn es dazu kommt, Du vielleicht mal einen Blick drauf werfen könntest..

netstat -s > summary.txt funktioniert (Datei anbei)

netstat -a > alles.txt funktioniert leider nicht (Datei leer)

Als Scada System läuft WinCC V6.0 (Serverapplikation) auf der PC-Station.

WinCC greift als OPC -Client auf einen OPC-Server von ABB zu.

Der OPC - Server liegt auch auf der PC- Station

Die ABB SPS (AC800M), eine CPU 414-3 DP mit CP443-1 und eine CPU 315-2 PN/DP

hängen zusammen mit der PC-Station im gleichen Subnetz.

summary.txt

[VaNaTiC]

OK, also S7 mit Industrial Ethernet CP.

Wie meinst Du das ABB OPC-Server? Direkt von ABB? Hmm, dann schau Dir mal die Verzeichnisse des OPC-Servers an, da wirst 100%ig eine EXE oder DLL finden, die sich in der Prozessliste unter Services wiederfindet. Die solltest Du mal konkret überwachen. Ich vermute hier liegt der Hund begraben.

ABB hmm, ein Kollege hat mal mit denen was in ZPW Lichtenberg zu tun gehabt.

Mal ne ganz dumme Frage: Warum projektiert ihr nicht die S7-Variablen direkt im WinCC? Ob die nun als OPC- oder Ind.Eth.-Variablen drin sind, spielt für die Lizenz keine Rolle. Sind alles externe Variablen. Oder wäre das doppelte Abgreifen der Daten aus den Steuerungen zu heftig?

Doppelt wäre es aber auch nur dann, wenn eine weitere Software als zweiter OPC-Client die Daten auch abgreift und damit was anderes macht. Ansonsten ist der OPC-Server sowieso umsonst da drin und kostet nur Ressourcen und wahrscheinlich Lizenz.

netstat -a da muss man (je nach dem wieviele Sockets offen sind) schon ne Weile warten!

Was mir am summary-File pauschal auffällt ist, dass immens viele Passiv geöffneten Verbindungen gezählt wurden?!

[Eleu]

Mal ne ganz dumme Frage: Warum projektiert ihr nicht die S7-Variablen direkt im WinCC? Ob die nun als OPC- oder Ind.Eth.-Variablen drin sind, spielt für die Lizenz keine Rolle. Sind alles externe Variablen. Oder wäre das doppelte Abgreifen der Daten aus den Steuerungen zu heftig?

Ja o.k. aber selbst wenn das funktionieren würde, kenne ich doch nicht die absolute Adresse im AC800M welche ja jetzt symbolisch als Item definiert ist.

Und für eine S7 Variable brauche ich doch eine absolute Adresse die ich beim Anlegen dann auch angeben muss.

Möglicherweise gibt es einen zweiten Client in Form eines Leitsystems,

denn die Items des AC800M werden darüber ebenfalls mit Daten versorgt.

Aber ob das auch über DCOM läuft weis ich nicht.

Wir haben einen AC800M als Ersatzsystem.

Daran könnte ich es ja mal testen ob es mit einer S7 Variable über WinCC geht.

Ein Test am Produktivsystem trau ich mich nicht.

Aber danke für den Tipp.

2) Dann solltest Du konkret analysieren, wie schnell und eventuell wodurch der Wert ansteigt. Bitte vergleichen, ob Netzwerk/Socket-Probleme eventuell im Zusammenhang mit Speicherzuwachs einher gehen.

Also ich könnte z.B. mit wireshark die Socket Verbindung von der

PC-Station zum AC800M mitsniffern.

Würde dann ein Screenshot machen oder einen Export in eine Datei und das hier reinstellen.

Vielleicht fällt dir ja was auf, oder Du kannst mir sagen worauf ich dann speziell achten muss.

[VaNaTiC]

Nein, wahrscheinlich fällt mir auf einen schnellen Blick mit Wireshark nix auf, sonst wäre irgendwas Grundlegendes falsch.

Ich hoffe wirklich, dass uns der Process Explorer weiter hilft.

Bin nur die nächsten 2 Tage unterwegs, vielleicht kann ich morgen früh nochmal reingucken.

[Eleu]

Anbei zwei Bilder vom Prozess Explorer und die "alles.txt"

von der PC Station, fallst Du noch dazu kommen solltest...

(Du hattest recht, ich war zu ungeduldig)

Wir habe zwar noch keine 100 % CPU Auslastung,

aber um sich mal ein Bild zu machen vielleicht gar nicht schlecht.

An Deinem Verdacht, dass es an der OPC Kommunikation liegen könnte,

ist vielleicht was dran.

Wir bemerken die Performancestörung der PC Station meistens als erstes

dadurch, dass die Kommunikation zum OPC Server gestört ist...

Gute Reise :cool:

Performancestörung.zip

[VaNaTiC]

Hmm, das nützt so leider nix, wenn dann solltest Du den Zustand der Maschine festhalten, wenn die wieder perma 100% hat. Zu diesem Zeitpunkt dann auch netstat -a und -s.

Mal ein paar Dinge am Rande:

- WinCC5 brachte den SQLanywhere Server mit dbsrv7.exe! Wieso läuft der bei Euch noch drauf? Habt ihr von einem WinCC5-Projekt hochmigriert?

- Die Scripts.exe hat 25h Prozessorzeit??? Gesamtlaufzeit prüfen, Idle hat im Vergleich dazu 263h. Da kann was nicht passen. Scripts.exe sind die Global Scripts. Was machen die denn damit alles?

- Ich hab schon in mehreren Projekten wirklich auch intensiv Global Scripts selber genutzt und das brachte nur Probleme! Das liegt am internen Handling des WinCC, dass die sequentiell ausgeführt werden. Dazu aber hier nix weiter, das wäre einfach zuviel.

Der Prozess AC800MC_OpcServ hat nur 4min Prozessorzeit und mit seinen 23 Threads (wozu eigentlich? habt ihr 11 oder 23 SPSen? ) bereits 1.919.511.871 Context-Switches zwischen den Threads! Das ist nie gut.

Ansonsten ist nix zu erkennen, auch im netstat -a nix, das schaut normal aus.

Die vielen PageFaults und ContextSwichtes vom WinCC sind normal, SIEMENS kanns nich besser

[Eleu]

- Die Scripts.exe hat 25h Prozessorzeit??? Gesamtlaufzeit prüfen, Idle hat im Vergleich dazu 263h. Da kann was nicht passen. Scripts.exe sind die Global Scripts. Was machen die denn damit alles?

Der ABB OPC-Server ist für uns gegenwärtig die einzigste Möglichkeit auf die Prozessdaten des unterlagerten Prozessleitsystems (Ebenfalls von ABB) zuzugreifen.

Wie schon gesagt, läuft der OPC-Server für den AC800M auch auf der PC-Station und WinCC greift als OPC-Client darauf zu.

Da ein Teil der Prozessdaten auch zur S7 400 und 300 gehandelt werden muss, ist es so gemacht worden, dass einige verlinkte OPC - Items des OPC - Kanals über Global - Skript

in die Industrial Ethernet Verbindung der S7 - Protokoll Suite hin und her geschaufelt werden.

Dieses erfolgt immer ereignisgetriggert bei Variablenänderung: Immer mit GetTagBit <-> SetTagBit und umgekehrt.

Ich habe beobachten können, dass immer wenn diese Triggerung erfolgt auch die CPU Auslastung auf 100 % springt.

Ich weis das ist großer Käse und es wäre besser wenn die S7 400/300 direkt auf den Adressraum des AC800M zugreifen könnte,

aber wir haben halt von ABB nur diesen OPC-Server bekommen mit der entsprechenden Funktionsgarantie.

Ich versuche zur Zeit mit meinen Field - PG auf den Reserve AC800M zuzugreifen, um deinem Vorschlag mal nachzugehen.

Wenn es gelingt mit WinCC (S7-Prokoll-Suite m. TCP-Verbindung) direkt auf den Adressraum des AC800M zuzugreifen, dann wäre es meines Erachtens vielleicht auch Möglich

eine unspezifizierte S7 Verbindung in der S7-400 und/oder 300 Richtung AC800M zu projektieren.

Aber die IP -Adresse die auf dem AC800M draufsteht stimmt irgendwie nicht (Kann das blöde Ding nicht anpingen)

Weis jemand wie man eine IP Adresse herausbekommen kann, wenn man nur die MAC Adresse des Netzwerkteilnehmers kennt ?

Der Prozess AC800MC_OpcServ hat nur 4min Prozessorzeit und mit seinen 23 Threads (wozu eigentlich? habt ihr 11 oder 23 SPSen? ) bereits 1.919.511.871 Context-Switches zwischen den Threads! Das ist nie gut.

Ich weis nicht was Du damit meinst. Es sind nur 2 SPS`s. Mit dem AC800M sind es 3

[VaNaTiC]

Da ein Teil der Prozessdaten auch zur S7 400 und 300 gehandelt werden muss, ist es so gemacht worden, dass einige verlinkte OPC - Items des OPC - Kanals über Global - Skript

in die Industrial Ethernet Verbindung der S7 - Protokoll Suite hin und her geschaufelt werden.

PFUI. Das hab ich einmal als Software-Redundanz versucht und das taugt nix. Global Script ist absolut nicht belastbar für solche Sachen. Finger Weg!

Ich hab irgendwann mit dem ODK so gut wie alles selber gehandelt.

Nicht umsonst machen alle Steuerungsaufgaben die SPSen und nicht WinCC.

Dieses erfolgt immer ereignisgetriggert bei Variablenänderung: Immer mit GetTagBit <-> SetTagBit und umgekehrt.

Ich habe beobachten können, dass immer wenn diese Triggerung erfolgt auch die CPU Auslastung auf 100 % springt.

DOPPELPFUI!

1. GetTagBit() ist eine asynchrone Methode aus der dmclient.dll, die mit dem halben Intervall der benötigen Zeit die Daten ausm Prozess holt (egal ob nun OPC oder SPS)

2. Schau zu, dass es keine Bit-Variablen gibt, d.h. Du liest 32bit Doppelworte, aber mindestens 16bit Worte, wo sozusagen 16 Meldungen auf einmal bearbeitet/kopiert/verglichen werden.

3. Wenn ich Dich richtig verstanden habe, werden nur die Änderungen bearbeitet?! Ist doch aber quatsch, ich hab doch ohnehin den Orginalwert geholt und nun wird noch der alte Wert geholt und dann nloch verglichen? Dann kann ich doch gleich den Orginalwert in mein Prozessabbild schreiben.

Fakt ist, das sollte doch eine belastbare Anwendung sein. Oder handelt es sich hier um das "Licht im *******haus" (tunneldeutsch für unwichtig )

Ich weis das ist großer Käse und es wäre besser wenn die S7 400/300 direkt auf den Adressraum des AC800M zugreifen könnte,

aber wir haben halt von ABB nur diesen OPC-Server bekommen mit der entsprechenden Funktionsgarantie.

Alles in allem frag ich mich echt, was das für ne Anlage ist, sowas würd ich nicht akzeptieren!

In welchem Auftragsverhältnis steht ihr mit ABB. Ist der Vertrag nach VOB?

Aber die IP -Adresse die auf dem AC800M draufsteht stimmt irgendwie nicht (Kann das blöde Ding nicht anpingen)

Ist ICMP vielleicht deaktiviert? Oder stimmen die Revisionsunterlagen nicht?

Beide ist ******e und kenn ich eigentlich nicht. Schon wieder ein Grund sich mit ABB ins Benehmen zu setzen!

Weis jemand wie man eine IP Adresse herausbekommen kann, wenn man nur die MAC Adresse des Netzwerkteilnehmers kennt ?

ARP ? Wikipedia

Ich weis nicht was Du damit meinst. Es sind nur 2 SPS`s. Mit dem AC800M sind es 3

Context switch - Wikipedia, the free encyclopedia

Ich meinte damit, dass das komisch ist, weil bei 3 Steuerungen nach 4 Minuten prozessorzeit keine 1.9 Milliarden Context-Switches ausgeführt werden söllten.

Aber ich kann Eure Anlagenprobleme nicht ohne genaue Kontrolle lösen.

Langsam muss ich auch Geld verlangen

Ihr müsst Euch definitiv mit ABB zusammensetzen.

Meine Anmerkungen sollten Euch allerdings enorm viel Futter für die 120mm Kanone geben

Auf den Process Explorer Screen, wenn System tot ist, bin ich gespannt, aber dann wirds Zeit dass ihr das Problem mit ABB angeht.

Bearbeitet 3. März 2009 von VaNaTiC

[Eleu]

Einiges von dem was Du sagst mag richtig sein, aber grundsätzlich sollte es doch so sein,

das WinCC das können muss, was im Funktionsumfang auch enthalten / verkauft worden ist,

und zwar ohne das man sich eine extra ODK dazu kaufen muss.

Das heißt wenn es GetTagBit <-> SetTagBit gibt muss es damit auch funktionieren

(Finde ich zumindest)

Der Zugriff auf eine SPS über OPC-Server geht erst mal nur mit einer PC-Station und es ist eine technisch anerkannte Verfahrensweise.

Im Prozessleitsystem werden Variable aufgrund von Normen so angelegt,

dass sie unter Umständen nur ein Bit an Informationen enthalten

WinCC kann als OPC -Client nur die OPC-Variablen verlinken die vom ABB-PLS

vorher auch so angelegt wurden.

Ich will damit sagen, in WinCC kann man die Items nur so verlinken wie sie eben da sind.

Das ABB -PLS ist ein proprietäres System (Und zwar ein super propritäres System)

und der OPC-Server war wie gesagt die einzigste Möglichkeit eine Schnittstelle zu schaffen.

Die Alternative wäre gewesen, das PLT zu erweitern.

(Preislich gesehen nicht unbedingt eine Alternative, ohne das System als solches

damit schlecht machen zu wollen. Ganz im Gegenteil)