[all sections except general]

Einstellungen für alle Sektionen außer [general]

[all sections except general] alivePort

Typ
unsigned integer
Default
0
Wertebereich
0..64k
Dieser Eintrag gibt an, auf welchem Port ein Manager Alivetelegramme empfangen soll. Eine Aliveüberwachung findet nur zwischen Managern statt, die einen Aliveport zur Verfügung stellen, also einen Eintrag 'alivePort = ' haben, und die auch ein aliveTimeout != 0 haben. Die Überwachung findet nur beim Ziel von Alivetelegrammen statt, also bei dem Manager, der auch einen Aliveport zur Verfügung stellt. Siehe auch aliveTimeout.

[all sections except general] alivePriorityClass

Typ
bool
Default
1
Wertebereich
0|1
Erhöht die Priorität des Alive-Threads unter Windows auf TIME_CRITICAL und unter Linux auf maximale 'scheduling priority'.

[all sections except general] as_activeAlarmBackCol, as_activeAlarmForeCol, as_activeCurrAlarmBackCol, as_activeCurrAlarmForeCol, as_alarmBackCol, as_alarmForeColI

Typ
string
Wertebereich
WinCC OA-Color
as_activeAlarmBackCol/as_activeAlarmForeCol setzt die Vorder-und Hintergrundfarbe des letzten aktiven Alarmeintrags im offenen und geschlossenem Modus des Melde- und Ereignisschirms. as_activeCurrAlarmBackCol/as_activeCurrAlarmForeCol bedient in gleicher Weise den aktuellen Modus. Zum Beispiel: Text: Rot, Hintergrund: Weiss (blinkend) Als aktiver Alarm wird hier immer die letzte "KAM unquittiert" bzw. "KAM quittiert Meldung" verstanden. Beispiele: 

as_activeAlarmBackCol = "<{255,0,255},4,{255,255,255},>"
as_activeAlarmForeCol = "<{255,255,255},4,{255,0,255},4>"
as_alarmBackCol/as_alarmForeCol setzt die Vorder-und Hintergrundfarbe des letzten nicht-aktiven Alarmeintrags im offenen und geschlossenem Modus des Melde- und Ereignisschirms. Ein nicht-aktiver Alarm entsteht wenn die Melderichtung/der Wert auf GING/False wechselt. Beispiele: 

as_alarmBackCol = "_3DFace"
as_alarmForeCol = "blue"

[all sections except general] as_descriptionMode

Typ
bool
Default
0
Wertebereich
0|1
Mit as_descriptionMode = 1 wird eingestellt, dass im Alarmschirm der Alias angezeigt wird, wenn keine Datenpunktbeschreibung gegeben ist. Ist der Alias ebenso nicht gegeben, so wird der Datenpunktname angezeigt.

[all sections except general] as_ShowMilliseconds

Typ
integer
Default
0
Wertebereich
0|1|2
Anzeige von Millisekunden auf dem Meldeschirm.
  • 0: Millisekunden mit '.' getrennt
  • 1: Millisekunden in ()
  • 2: wie 0

[all sections except general] as_SpecialWentText

Typ
bool
Default
0
Wertebereich
0|1
Auf dem Meldeschirm wird bei gehender Meldung der Text der Meldung in Klammern angezeigt (=1).

[all sections except general] connectDp

Typ
string
Definiert den Datenpunkt, welcher vom Manager zur Bekanntgabe seiner Managerverbindungen verwendet wird.

[all sections except general] connectToRedundantHosts

Typ
unsigned
Default
0
Wertebereich
0,1
Dieser Eintrag gibt an, ob sich in einem redundanten System ein Manager, der sich normalerweise nur zu einem Event verbindet (z.B. Ctrl) sich zu beiden Event verbinden soll. Der Eintrag kann in allen Sektionen, außer [general], verwendet werden, d.h. für alle Manager kann eine Verbindung zu beiden Event-Managern aufgebaut werden. Beispiel: [ctrl] connectToRedundantHosts = 1

[all sections except general] distSystemIds

Typ
string
Mit diesem Config-Eintrag kann pro Manager gesteuert werden, von welchem verteilten System er die DP Identification akzeptiert/hält.

Beispiel: 


[ctrl_3]
distSystemIds = "1-28, 46, 280-290, 320"
Es können entweder Bereiche oder einzelne Nummern eingegeben werden. Leerzeichen werden ignoriert. Wird dieser Config-Eintrag nicht definiert, so werden alle DP Identifications akzeptiert. Ist der Wert des Config-Eintrages distributed (siehe Konfigurationsdatei für verteilte Systeme in der Online Hilfe) für einen Manager gleich 0, wird die DP Identification an diesen Manager nicht übermittelt.

Mit dem Debug-Level -dbg 31 kann überprüft werden, welche Identifications akzeptiert oder ignoriert werden.

[all sections except general] requestDejaVu

Typ
bool
Default
0
Wertebereich
0|1
In einem redundanten System verarbeitet der passive Event nur Wertänderungen, die er vom aktiven Eventmanager erhält. Messages, die er von einem Manager erhält, der zu beiden Eventmanagern verbunden ist, z.B. einem UI, hält er in einem Buffer, bis er die gleiche Message (mit gleicher ID) vom aktiven Eventmanager bekommt. Messages dagegen, die er von einem Manager erhält, der nur zu jeweils einem Eventmanager verbunden ist, z.B. einem Treiber, verwirft er, weil er die gleiche Message nicht vom aktiven Eventmanager bekommen kann. Stattdessen wird erwartet, dass eine entsprechende Message den aktiven Eventmanager erreicht und dieser die Message dann zum passiven Eventmanager weiterleitet. Im Fall einer Störung, z.B. Ausfall des aktiven Treibers oder sogar Ausfall des aktiven Eventmanagers, kann es einige Sekunden dauern, bis dieses erkannt wurde. Wertänderungen, die in dieser Zeit angefallen sind, wären damit verloren gegangen, da der passive Eventmanager sie nicht mehr vom aktiven Eventmanager erhalten kann und Werte, die er direkt bekommen hätte, bereits verworfen hat. Um diesen Datenverlust vorzubeugen können Manager so parametriert werden, dass ein passiver Eventmanager dessen Wertänderungen nicht sofort verwirft sondern zunächst für eine begrenzte Zeit in einem Puffer hält. Nach einer Umschaltung beginnt der nun aktive Eventmanager zunächst, diese Messages abzuarbeiten. Dabei verwirft er alle Wertänderungen, die älter als die letzte Wertänderung im Prozessabbild sind, für die er also bereits eine entsprechende Message vom vormals aktiven Event erhalten hat. Per default ist dieses für Treiber aktiviert. Für andere Manager kann dieses Verhalten mit dem Config-Eintrag "requestDejaVu" explizit eingeschalten werden.

[all sections except general] requestedCNSViews

Typ
string
Wertebereich
CNS view names
Gibt an welche CNS-Ansicht ein Manager im Speicher behalt. Verwenden Sie den Eintrag, um Speicher in Prozessen zu sparen, indem Sie nur die CNS-Ansichten angeben, die benötigt werden.

Syntax: Durch Beistriche getrennte Liste der Pfade zu den entsprechenden CNS-Ansichten.

Beispiel: 
requestedCNSViews = "System1.View1, .View2, System2.View3:"

Ansichten, die im lokalen System verwendet werden, können entweder über z.B. System1.View1, oder über .View2. angegeben werden.

Wenn ein Ansichtsname, der nicht im CNS existiert, angegeben wird, werden alle Ansichten ausgefiltert. Wenn der Eintrag für Data- oder Dist-Manager angegeben wurde, wird der Eintrag nicht berücksichtigt.