OPC Server mit 'Fetch on event'?

[danube]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo! Derzeit verwende ich den OPC Server von INAT, bei diesem kann man die Option 'Fetch on event' aktivieren, was die Aktualisierung einer Variable bei Statusänderung zur Folge hat.

Gibt es eine solche Funktion auch bei anderen OPC Servern? Wenn ja, bei welchen?

Herzlichen Dank für jede Info!
Tom

 

[Dr. OPC]

die Option 'Fetch on event' aktivieren

Diese Option ist laut OPC Spezifikation NICHT vorhanden. Es handelt sich vermutlich um ein "Feature" des spezielen OPC Servers.

Hintergrund:
Zwischen OPC Client und OPC Server gibt es IMMER (also bei allen OPC Servern) die Funktion: "bei Änderung melden". Die Items werden vom Client in eine Gruppe gesteckt und dann wird dem Server mitgeteilt dass er sich nur dann melden soll (OnDataChange-Event) wenn sich der Wert irgendeines der Items dieser Gruppe geändert hat, die Gruppe wird aktiviert und wie der Server die Werte tatsächlich beschafft ist sein Problem, das geht den Client nichts mehr an.

Jeder Server muss auch (laut OPC Spezifikation) einen OnDataChange-Event schicken wenn sich anstelle des "Wertes" (nur) die "Qualität" eines oder aller Items dieser Gruppe ändert. Wenn das die "Statusänderung" ist von der du sprichst, dann also JA, alle OPC Server müssen das so machen. Aber "Fetch on Event" heisst das nicht sondern ist ganz normal OPC konformes Verhalten.

Typisches Szenario:
Alle OPC Server, die sich an die Spezifikation halten, müssen einen OnDataChange-Event schicken wenn z.B. alle Items einer aktivierten Gruppe anstelle einer "Werte-Änderung" eine "Änderung der Qualität" erfahren (z.B. weil die unterlagerte Verbindung zwischen Server und SPS abgerissen ist, dann werden alle Items auf einen Schlag eine "Statusänderung" haben und zwar: "Quality=Bad"). Nur im gleichen Zug eine "Aktualisierung der Variable" zu erwarten, wäre zu viel. Die Änderung der "OPC-Quality" von "Good" auf "Bad" bekommst du also gemeldet, aber der "Wert" des Items ist damit nicht mehr "vertrauenswürdig" (weil "Bad"), denn genau das sagt die Statusänderung ja aus.

Das "Feature" von INAT:
was das genau bedeutet, kann ich nicht sagen, da musst du INAT fragen.
Vorstellen könnte ich mir dass es etwas mit dem Verhalten der "unterlagerten" Kommunikation (also zwischen OPC Server und Gerät) zu tun hat. Die meisten Hersteller "pollen" die unterlagerten Geräte weil die (proprietären) Protokolle zu diesen Geräten (meist) nichts anderes bieten. Ebenso beherrschen einige Feldbusse keine "Events" (Benachrichtigung aus dem Gerät) und somit bleibt dem OPCServer nichts anderes übrig als zu "pollen". Unter "Fetch on Event" könnte man sich aber vorstellen dass der INAT Server nun (falls sein "unterlagertes" Protokoll oder der Treiber eine Statusänderung meldet) als Reaktion darauf schnell ein "Fetch" aufruft und sich die Werte holt. Wie gesagt nur eine Vermutung.

Wie weiter oben geschildert hat das mit OPC (zwischen Client und Server) erstmal nichts zu tun, sondern wäre eine "interne Implementierung" von INAT (zwischen Server und unterlagertem Gerät)

 

[danube]

Zuviel Werbung?
-> Hier kostenlos registrieren

was das genau bedeutet, kann ich nicht sagen, da musst du INAT fragen.

Ich glaube rausgefunden zu haben, wie INAT zu dieser Option kommt. Anscheinend funktioniert dieses 'Fetch on Event' ausschließlich mit CP's des eigenen Herstellers. Denn INAT verkauft auch Kommunikationsbaugruppen.

Vermutlich wird die OPC Spezifikation mit einem eigenen Protokoll überlagert. So kann ich mir vorstellen, dass INAT mehr Informationen transportieren kann.

Was jetzt grundsätzlich schade ist, da ich nach einer Lösung suche, ein Zeitbalkendiagramm in Excel gezeichnet zu bekommen, und zwar in Echtzeit.

Mit einer Zeitpollung von ~500ms (bzw. alles mit größer CPU Zykluszeit) scheint OPC hierfür nicht der richtige Ansatz zu sein, oder?

 

[Gerhard Bäurle]

Was jetzt grundsätzlich schade ist, da ich nach einer Lösung suche, ein Zeitbalkendiagramm in Excel gezeichnet zu bekommen, und zwar in Echtzeit.

Wie definierst Du hier Echtzeit?

Wenn Du die Daten zyklusgenau haben möchtest, musst Du sie in
der Steuerung sammeln und paketweise an Excel übergeben.

Offen ist auch noch:
Welcher Kommunikationsweg: seriell? MPI? Profibus? Ethernet?
Welche Steuerungs- und Kommunikationshardware?

 

[Dr. OPC]

Vermutlich wird die OPC Spezifikation mit einem eigenen Protokoll überlagert. So kann ich mir vorstellen, dass INAT mehr Informationen transportieren kann.

Das glaube ich zwar nicht, aber sagen wir es mal so: WIE der OPC Server an die Daten von seinen unterlagerten Geräten kommt ist sein privates Vergnügen. Fakt ist, der Server MUSS Werteänderungen an den Client senden, das ist laut OPC so vorgesehen. Der Server muss typischerweise also um überhaupt zu erkennen ob sich ein Wert geändert hat, sich zunnächst mal den letzten Wert merken (cachen), dann das unterlagerte Gerät "pollen" und jedes mal vergleichen ob sich der Wert geändert hat oder nicht. Wenn JA, muss der Server den neuen Wert nehmen und ihn an den OPC Client schicken (OnDataChanged-Event).

Anscheinend funktioniert dieses 'Fetch on Event' ausschließlich mit CP's des eigenen Herstellers.

wenn nun der OPC Server mit einem speziellen CP kommuniziert, an dem die unterlagerten Geräte hängen, gibt es hier vielleicht eine Möglichkeit das dieser CP ein spezielles Feature hat, um zu erkennen ob sich irgendwo irgendwas geändert hat. Wie in meinem vorangegangenen Post zu sehen ist das aber ein "internes Details" des jeweiligen OPC Servers und hat mit OPC an sich erstmal nichts zu tun.

Beispiel Profibus: ein Profibus CP (der ein Master ist) kommuniziert ja zyklisch mit seinen Slaves (der CP "pollt" also die Slaves). Im CP besitzt er ein "Speicherabbild" aller I/O Daten aller angeschlossenen Slaves. Man könnte also schon direkt in diesem CP prüfen ob sich an den I/O Daten der Slaves irgendetwas geändert hat und ein Signal senden (interrupt) falls dies der Fall sein sollte. Der OPC Server sitzt nun "oberhalb" dieses CP und schaut "von der anderen Seite" auf dieses Speicherabbild. Anstelle sich das ganze I/O Speicherabbild nochmals zu cachen und permanent zu prüfen, könnte er einfach auf den Interrupt reagieren und sich das Abbild erst dann neu holen wenn es sich auch wirklich geändert hat. Wie gesagt nur ein Beispiel, wird bei Profibus oft gemacht (z.B. Siemens CP5613)

Was jetzt grundsätzlich schade ist, da ich nach einer Lösung suche, ein Zeitbalkendiagramm in Excel gezeichnet zu bekommen

Die Frage ist hier eher ob der "OnDataChange" Mechanismus der geeignete Weg ist. Ursprünglich ist er dazu gedacht die Kommunikation zwischen Client und Server auf ein Minimum zu beschränken, denn es wird nur dann kommuniziert wenn sich auch wirklich Daten geändert haben. In deinem Fall hört sich das eher so an als ob du (dein Excel-Client) zyklisch LESEN willst und dann mit den (immer gleichen) Zeitabständen ein Balkendiagramm zeichnen willst. Das geht natürlich auch mit OPC aber mit der Funktion "Lesen" nicht mit der Funktion "Änderungen-Melden".

Zeitpollung von ~500ms (bzw. alles mit größer CPU Zykluszeit) scheint OPC hierfür nicht der richtige Ansatz zu sein

je nachdem um welchen OPC Server es sich handelt sind Abtastraten bis 10ms (oder weniger) möglich, das hängt von der gesamten Datenmenge und vor allem vom Mechanismus der Datenbeschaffung des Servers (der unterlagerten Anbindung der Geräte) ab. Wenn ein Protokoll wie Profibus ohnehin "vollgas" am pollen ist (da es in der Natur eines Master-Slave Protokolls liegt), kann ein spezieller OPC Server das natürlich auch ausnutzen.

 

[danube]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie definierst Du hier Echtzeit?

Auf die Frage hab ich gewartet, hab vergessen darauf näher einzugehen. "Zyklusgenau" trifft es am ehesten. Es soll jede Zustandsänderung von ausgewählten Signalen mit einem Zeitstempel versehen dargestellt werden.

Welcher Kommunikationsweg: seriell? MPI? Profibus? Ethernet?
Welche Steuerungs- und Kommunikationshardware?

Schnell beantwortet: Es besteht eine Ethernet Kommunikation mit einer S7 414-2DP über einen CP 443-1. Das Ganze ist ein Testaufbau, es sind also alle Schweinereien erlaubt.

In deinem Fall hört sich das eher so an als ob du (dein Excel-Client) zyklisch LESEN willst und dann mit den (immer gleichen) Zeitabständen ein Balkendiagramm zeichnen willst.

Es reicht auch ein neuer Eintrag, wenn sich ein Zustand ändert. Dies ist dann kein kontinuierliches Zeitdiagramm mehr, sondern gleicht eher einem Geschichtsbuch, also nur dann ein Eintrag, wenn auch etwas passiert ist.

je nachdem um welchen OPC Server es sich handelt sind Abtastraten bis 10ms (oder weniger) möglich

Hast Du hier Erfahrungswerte bei der zeitlichen Performance, welche Server hier eine Tastrate im unteren Segment schaffen? Klar ist, dass die CPU Zykluszeit dadurch vernachlässigbar bis grob beeinflusst wird, das müssen wir uns dann natürlich in jedem Einzelfall genauer ansehen. Mit INAT und Matrikon komme ich idR nicht viel unter 400ms.

 

[Dr. OPC]

Es besteht eine Ethernet Kommunikation mit einer S7 414-2DP über einen CP 443-1

Aha Ethernet, vermutlich S7-Protokoll, dann macht auch "Fetch" wieder Sinn. Aber was genau der Event ist bei "Fetch on Event" auf den dann anscheind ein Fetch aufgerufen wird, das würde mich ja mal interessieren? Und wieso geht das nur mit einem speziellen CP? Naja, egal, alles nur Spekulation, wie gesagt bei einem Profibus macht so ein Feature Sinn, denn da wird SOWIESO schon gepollt, das liegt in der Natur der Sache bei Profibus. (zumindest bei zyklischem DP)

INAT und Matrikon komme ich idR nicht viel unter 400ms

es hängt sehr stark vom Protokoll und natürlich von der Nutzdatenmenge ab. Weiterhin wichtig ist wo die Daten liegen (zusammenhängend in einem DB oder verteilt über Merker, DBs, kreuz und quer). Weiterhin hängt die maximale Geschwindigkeit vom Typ den CP443-1 ab und von der CPU natürlich. 400ms zu einer 400ter erscheint mir extrem wenig. Wieviele Datenpunkte hast du denn angemeldet? Hängen noch weitere Verbindungen auf dem CP?

Es reicht auch ein neuer Eintrag, wenn sich ein Zustand ändert.

OK, dann ist natürlich ein OnDataChange-Event eine gute Sache, es kommt immer nur dann ein neuer Eintrag in die Excel-Tabelle wenn sich auch wirklich der Wert geändert hat (dann ist die auch nicht so schnell voll )