Client-Funktionen

Direktes Lesen

Um den Mehraufwand für das Senden von Antworten der Datenbank an den Client (über das NGA-Backend -> NGA-Frontend und den Data-Manager an den Client) zu minimieren, erlaubt das "Direct Read"-Feature das Lesen von historischen Daten direkt aus der Datenbank. Dadurch kann der nachrichtenbasierte Mehraufwand verhindert werden. Die Funktion ist vergleichbar mit dem "Direct Read"-Features des RDB-Managers.

Ob "Direct Read" schneller ist als der nicht direkte Zugriff, hängt von mehreren Faktoren ab, z.B. der Größe, der zu sendenden Antwort und auch dem Standort des lesenden Clients (lokal oder abgesetzt).

Um in NGA mittels "Direct Read" auf Daten zuzugreifen, muss die Control-Extension "CtrlNgaFrontend" innerhalb des CONTROL-Skriptes geladen werden: #uses "CrtlNgaFrontend".

Diese Control-Extension bietet folgende Funktionen:

• alertGetPeriodNGA
• alertGetNGA()
• dpGetAsynchNGA
• dpGetPeriodNGA
• dpQueryNGA
  Anmerkung:

  Gelöschte Datenpunkte können nicht mehr abgefragt werden und sind nicht in einem Abfrageergebnis enthalten.

  Datenpunkte, deren Archivkonfiguration gelöscht wurde, bleiben in der Datenbank und können abgefragt werden.

Mittels des Config-Eintrags "useNGADirectRead" (kann in den Sektionen [general], [ui] oder [ctrl] gesetzt werden) kann das Standardverhalten dahingehend angepasst werden, dass die herkömmlichen WinCC OA-Funktionen für das Lesen von historischen Werten die NGA-Funktionen verwenden. Das heißt z.B., dass beim Aufruf von dpGetPeriod() innerhalb des Clients automatisch die "Direct Read"-Variante dpGetPeriodNGA() aufgerufen wird.

Durch Verwendung der CONTROL-Funktion:

bool setNGADirectRead(bool newState);

kann die aktuelle Einstellung für queryNGAdirect zur Laufzeit in einem Control-Skript geändert werden.

Die Funktion ist identisch zu setQueryRDBdirect() für den RDB-Manager.

Durch Verwendung der CONTROL-Funktion:

bool useNGADirectRead();

kann die momentane Einstellung von queryNGAdirect abgefragt werden.

Beispiele

Die Offlinewerte können wie folgt abgefragt werden:

main()
{
  dyn_float val; //Contains the values
  dyn_time t;//Contains the source times of the values
  int ant;//The function returns -1 in case of errors
  //from the 07.03.2021 to 08.03.2021, at least 1 value before 07.03.2021 and after 08.03.2021
  ant = dpGetPeriodNGA(makeTime(2021,3,7),makeTime(2021,3,8), 1,"System1:ExampleDP_Arg1.:", val, t);
  if ((ant== -1) || (dynlen(val) == 0)) // Is executed if a query error occurs or no values exist
  {
    DebugN("dpGetPeriod caused an error or no values exist");
  }
  else
  {
    int i;//loop variable
    DebugN("Result values:");
    for(i=1;i<=dynlen(val);i++)
    DebugN(val[i],t[i]);
  }
}

main()
{
  float val;
  int ant;
  ant = dpGetAsynchNGA(makeTime(2021, 3, 8, 11, 27), "System1:ExampleDP_Arg1.:", val);
  DebugN("Value of the ExampleDPArg1 on the eighth of March 11.27 am:", val);
}

Um den Benutzer, der den Wert gesetzt hat, abzufragen, verwenden Sie den Offline-Benutzer ":_offline.._user" wie folgt:

main()
{
  dyn_int val2; //Contains the users
  dyn_time t;//Contains the source times of the values
  int ant;//The function returns -1 in case of errors
  //from the 07.03.2021 to 08.03.2021, at least 1 value before 07.03.2021 and after 08.03.2021
  ant = dpGetPeriodNGA(makeTime(2021,3,7),makeTime(2021,3,8), 1,"System1:ExampleDP_Arg1.:_offline.._user", val2, t);
  if ((ant== -1) || (dynlen(val2) == 0)) // Is executed if a query error occurs or no values exist
  {
    DebugN("dpGetPeriodNGA caused an error or no values exist");
  }
  else
  {
    int i;//loop variable
    DebugN("Result values and user IDs:");
    for(i=1;i<dynlen(val2);i++)
    DebugN(val2[i],t[i]);
  }
}

Message splitting

In WinCC OA stehen mehrere Funktionen zur Verfügung, die es erlauben für spezifische Lesebefehle das Message Split-Feature zu verwenden, Mit dpQuerySplit und dpGetPeriodSplit kann das Message Splitting verwendet werden. Anstelle einer einzigen großen Antwort, werden mehrere kleinere Antworten im aufrufenden Code erhalten. Dies hat einen positiven Einfluss auf die Performanz da sich die erforderliche Arbeit in jeder Komponente zeitlich überlappen kann. Mit anderen Worten: Währenddessen der CTRL- oder UI-Manager die erste Antwort erhält, arbeitet der NGA-Manager an der zweiten Antwort und die Datenbank bereits an der dritten Antwort. Aufgrund dieser Überschneidung, wird die totale Abfragezeit reduziert.

Die maximale Größe eines "Blocks" kann über die Option "Aufspaltungsgröße" des NGA Backend-Konfigurationspanel festgelegt werden.

Diese unterhalb angeführten Funktionen sind identisch zu den bereits existierenden Split-Funktionen der HDB (Wertarchive). Weitere Erklärungen diesbezüglich finden Sie auf den Beschreibungsseiten der jeweiligen Funktion.

dpGetPeriodSplit()

dpQuerySplit()

dpCancelSplitRequest()

NGA-specific Split Functions

Diese Funktionen stehen auch in einer NGA-spezifischen "Direct Read"-Variante zur Verfügung (siehe Direct Read oberhalb ):

Wenn ein Frontend mit dpQuerySplitNGA() oder dpQuerySplitNGA() abgefragt wird, fragt das Backend die InfluxDB stückweise ab. Wie groß die Scheibchen sind, stellen Sie mit der Splitgröße auf der Datenbank -Konfiguration -> Backend -> Registerkarte ein. Der empfohlene Bereich ist 200-10.000. 1 bedeutet, dass das Backend nicht blockweise abgefragt und geliefert wird, sondern als ein Ganzes. Vermeiden Sie Werte außerhalb des empfohlenen Bereiches, da dies einen großen Einfluss auf die Performanz haben kann.

dpGetPeriodSplitNGA()

Für eine Beschreibung, siehe dpGetPeriodSplit()

dpQuerySplitNGA()

Für eine Beschreibung, siehe dpQuerySplit()

dpCancelSplitRequestNGA()

Für eine Beschreibung, siehe dpCancelSplitRequest()

useNGA()

Verwenden Sie die useNGA()-Funktion, um herauszufinden ob der NGA im aktuellen Projekt verwendet wird.