API-Messages

Solange die beschriebenen API-Funktionen verwendet werden, ist ein genaues Wissen über Messages nicht nötig: Messages werden durch die API-Funktionen erzeugt und verschickt, der Anwender kommt damit nicht in Berührung.

Viele Messages werden auch automatisch von jedem Manager empfangen und entsprechend bearbeitet, wie etwa die Message, dass ein neuer Datenpunkt angelegt wurde. Falls ein Manager aber gezielt Attribute abfragt (dpGet(), dpGetPeriod(), ...) oder sich für Attributänderungen anmeldet (dpConnect(), dpConnectNoSource()), muss er die ankommenden Messages selbst bearbeiten. Tut er das nicht, werden sie automatisch verworfen.

Anmerkung: Bei Abfrage eines "root"-Elements sollte unbedingt ein Punkt verwendet werden z.B. "struct1.", Wird es ohne Punkt geschrieben wird stattdessen der Datenpunkt selbst verwendet (Datenpunkt = ".. El: 0 ..", root-element = ".. El: 1 .."). Das gilt nur für das "root"-Element nicht für die anderen Elemente des Datenpunktes.

WaitForAnswer Objekte

Bei den meisten Funktionen, die den Zugriff auf Datenpunkte betreffen, werden Messages mit Hilfe von WaitForAnswer-Objekten abgehandelt. So wird z.B. beim dpConnect ein HotlinkWaitForAnswer-Objekt angegeben.

static PVSSboolean dpConnect(const DpIdentifier &dpId,
WaitForAnswer *wait, PVSSboolean del = PVSS_TRUE);

Der Benutzer muss das HotlinkWaitForAnswer-Objekt entsprechend überladen und in der überladenen Funktion die Antwort bearbeiten. Näheres dazu ist aus dem DemoManager-Beispiel ersichtlich.

Alle sechs Varianten von dpConnect() gibt es auch als dpConnectNoSource(). Prinzipiell macht die Funktion das gleiche wie ein dpConnect() mit dem Unterschied, dass hier eine DP_MSG_CONNECT_NOSOURCE Message statt einer DP_MSG_CONNECT Message verschickt wird.

Die Message DP_MSG_CONNECT_NOSOURCE wird dazu verwendet, um das im Kreis schicken von Werten zwischen Treiber und dem Event zu verhindern.

Wenn ein Datenpunkt als I/O parametriert ist, dann meldet sich der Treiber dafür an. Schickt der Treiber eine Wertänderung zum Event-Manager, dann würde er durch ein normales dpConnect() erneut einen Wert bekommen und den erneut an die Hardware schicken.

Mit dpConnectNoSource() prüft der Event-Manager vor dem Verschicken des Hotlinks, ob der Wert vom Treiber oder von woanders bereits gekommen ist und schickt ihn nur dann, wenn der Treiber nicht der Auslöser war.

doReceive()

Ankommende Messages werden vom Manager in der Funktion doReceive() bearbeitet. doReceive() wird von der Funktion dispatch() automatisch für jede eingetroffene Message aufgerufen. Es gibt zwei Varianten, um eine Message zu empfangen:

void doReceive(DpMsg *msg)
void doReceive(DpMsg &msg)

Intern wird zuerst doReceive(DpMsg *msg) aufgerufen. In der Standardimplementierung wird dann doReceive(DpMsg &msg) aufgerufen und danach die Message gelöscht.

In der ersten Variante, doReceive(DpMsg *msg), wird ein Zeiger auf eine DpMsg an doReceive übergeben. Die Message wird dabei dynamisch alloziert und der Manager ist dafür verantwortlich, dass der Speicher freigegeben wird, sobald die Message nicht mehr benötigt wird.

Diese Variante ist dann sinnvoll, wenn etwa die Message in eine Schlange (Queue) gestellt wird, um sie später zu bearbeiten. In diesem Fall kann der Zeiger direkt verwendet werden, und es ist nicht nötig, die Message vorher zu kopieren.

In der zweiten Variante wird eine Referenz auf eine DpMsg übergeben. Sobald die Funktion doReceive verlässt, wird die Message automatisch gelöscht. Diese Variante ist also nicht geeignet, wenn die Lebensdauer der Message über die der Funktion doReceive hinausgehen soll. Das behandeln von Messages im doReceive ist in der Regel nicht nötig, da ein Großteil der Funktionen einfacher mit WaitForAnswer-Objekte abzuhandeln ist.

Msg

Die Klasse Msg ist die abstrakte Basisklasse aller in WinCC OA verwendeten Messages. Sie enthält die Basisfunktionalität einer Message.

Die wichtigste Funktion von Msg ist isA(). Diese Funktion gibt den Typ der Message zurück, der es ermöglicht, innerhalb von doReceive() jene Messages zu filtern, die im eigenen Manager bearbeitet werden sollen.

Alle anderen Messages müssen an die Funktion doReceive() der Manager-Basisklasse, Manager::doReceive(), übergeben werden, damit die Standardbehandlung aktiv werden kann.

Die wichtigsten Message-Typen werden weiter unten bei den entsprechenden Messages beschrieben.

SysMsg

Abgeleitet von der Klasse Msg, ist die Klasse SysMsg die abstrakte Basisklasse aller systembezogenen Messages. Diese werden in erster Linie beim Hochlauf von WinCC OA verwendet. Da systembezogene Messages im normalen Betrieb von WinCC OA keine Bedeutung haben, werden sie hier nicht beschrieben.

DpMsg

Abgeleitet von der Klasse Msg, ist die Klasse DpMsg die abstrakte Basisklasse aller auf Datenpunkte bezogenen Messages. Sobald der Hochlauf abgeschlossen ist, findet die gesamte Kommunikation fast ausschließlich mit Hilfe dieser Messages statt.