2016-08-23 1 views
0

Ich lerne OPC-UA mit OPC-UA .Net Stack. Die Beispiele mit subskribierenden und sendenden Daten werden explizit serverseitig mit 1-Sekunden-Zyklen der Aktualisierung gemacht - d. H. Jede Sekunde werden die Werte der Variablen aktualisiert, und der Rest (benachrichtigende Clients) wird durch den OPC-UA-Stapel behandelt. Da die Schleife von Hand erstellt wird, bedeutet dies, dass es funktioniert, auch wenn es überhaupt keine Abonnements gibt.Wie kann ich Werte für den Abonnementbedarf lesen?

Ok. Aber ich möchte es ein wenig umkehren - setzen Sie keinen statischen Wert auf die Variable, verlassen Sie sich nicht auf diesen manuellen Aktualisierungszyklus, aber wann immer die Variable gelesen werden soll (Abonnementbedarf), berechnen Sie dynamisch den Wert und geben ihn zurück an den Client.

Ich hinzugefügt OnReadValue Handler für die Variable und wenn der Client für diesen Wert subskribieren, es ausgelöst wird, wird der Wert berechnet und zurückgegeben. Fast genau das, was ich mir gewünscht habe - das Problem ist nur einmal.

Ich denke, seit Client angefordert Updates in einem Intervall, auf dem Server gibt es einige Schleife mit einem solchen Intervall. Wie kann ich dem Server mitteilen, die Variable erneut zu lesen (um den Handler auszulösen)?

+0

Können Sie nicht einfach den Wert manuell aktualisieren, indem Sie ihn über seine Knoten-ID lesen? Die generische Client-Beispielimplementierung sollte den Code dafür enthalten. –

+0

@ManfredRadlwimmer, dies ist über Interna des Servers (nicht Client). Hier, wie ich es gerne machen würde - Client abonniert eine Variable mit Intervall 5 Sekunden. Also versucht der Server es alle 5 Sekunden zu lesen (schätze ich). In diesem Fall würde ich gerne den Wert (auf dem Server) von der tatsächlichen Hardware genau dann lesen, wenn der Server versucht, die Variable zu aktualisieren. – astrowalker

Antwort

0

Nach dem Lesen der Quelle des mitgelieferten OPC UA- .Net-Stacks kann ich jetzt sehen, wie ich verpasst habe, wie die Datenübertragung organisiert ist. Das Berichtsintervall ist nicht für "gib mir so viele Daten wie möglich", sondern ganz im Gegenteil "gebe mir so wenig Daten wie möglich". Das liegt daran, dass der Server change-event-gesteuert ist, nicht zeitgesteuert (oder anforderungsgesteuert) - dh jede Änderung des Werts einer Variablen wird bemerkt und könnte problemlos für die Berichterstellung in die Warteschlange gestellt werden, aber das Intervall spielt eine Rolle eine Bremse - wenn die Zeit der Änderung kleiner als das Intervall ist, wird nichts zur Warteschlange hinzugefügt (und wird daher nicht gemeldet).

Der Client kann jedoch eine kontinuierliche Berichterstellung anfordern - Intervall = 0 und einige erhebliche Größen für die Warteschlange.

Verwandte Themen