Configuration file schema

Under "Introduction to the configuration file" you can read where to find or create the configuration file. Rules for structuring the configuration file can be read in the Microsoft-Documentation.

iPlus offers you configuration elements that are explained below.

• The Basic structure specifies that the <configSections> section exists in which the declaration must first be made.
• A declaration consists of the sub-elements <sectionGroup> and <section>.
• The iPlus configuration classes are announced to the XML parser in the <section> sub-element.
• The name assign in the "name"-attribute in the <sectionGroup> and <section> must be used as an XML element in the further course of the file.

The following examples show how this is done.

Entity-Framework Options

You can use the configuration class gip.core.datamodel.EFConfiguration to adjust the behavior of the entity framework. The following parameters can be set:

CommandTimeout: Maximum time in seconds for queries and save operations in the entity framework. For more information, see https://msdn.microsoft.com/en-us/library/system.data.objects.objectcontext.commandtimeout(v=vs.110).aspx . The default value is 30 seconds.

 

Core behavior of iPlus-Runtime

You can use the configuration class gip.core.autocomponent.CoreConfiguration to adjust the core behavior of the iPlus framework. The following parameters can be set:

DefaultPrecision: Variable changes are always forwarded on an event-based process. In order to avoid unnecessary broadcast traffic for floating point values, the number of decimal places can be defined if the value changes in the rear decimal places. The default precision does not change the actual value, but only a temporary rounding in the comparison function.

 

UseSimpleMonitor, ValidateLockHierarchies 

iPlus is a highly multithreaded system (read chapter "Multithreading"). This means that many program positions must be secured for simultaneous access ("critical sections"). Deadlocks are always very problematic when a system is in productive operation. Although the system has been tested before delivery to the customer, problems may occur under real conditions. To prevent this, iPlus has implemented the principle of lock hierarchies.

The base for this is gip.core.datamodel.ACMonitor. The ACMonitor-class is an extension of the .NET Monitor-Class and should always be used for all locks. It offers the following advantages over the classic monitor class:

• It monitors whether the deadlock hierarchy is adhered to. As soon as the call sequence can provoke a deadlock, an exception is thrown here. The error message is also stored in the log file. You enable the monitoring of the lock hierarchies with the "ValidateLockHierarchies" switch.
• In the case of a deadlock, the entire call stack of both jammed threads is displayed in the log file and the lock is released. In this way, there can be no shutdown during production operation. However, the program may be in an inconsistent or undesired state (UseSimpleMonitor=false).

Since the ACMonitor class consumes considerably more CPU and RAM resources, the function of the ACMonitor class can be switched off after a certain test phase as soon as the system proves to be stable and no deadlock messages have occurred (e. g. after 1-2 months). To do this, set the property "UseSimpleMonitor" to true. This is also the default value.

 

Core behaviour of process automation

You can use the configuration class gip.mes.processapplication.ProcessConfiguration to influence the behavior of the process automation components:

DeactivateProcessConverter: Process functions such as mixing, tempering, dosing, have a state machine according to the ISA-S88 specification. Since the actual process execution is carried out by PLC controllers, the process functions communicate with the PLC by means of converters. However, it is technically possible for iPlus applications to run on different computers that communicate with the same PLC (e. g. each computer has a copy of the iPlus database with the same applications and PLC connections). This would have the consequence that both computers also react to the status changes in the PLC, which could lead to dangerous side effects. If this configuration property is set to true, the converter logic is disabled and there is no response to state changes. This functionality is particularly important if there are several commissioning engineers who want to run their own iPlus service instance independently of each other.

 

Control the logfile outputs

iPlus offers you three types of logging options for diagnostic and analytical purposes:

1. Logging of errors, exceptions and trace output
2. Long-term storage of process variable/properties
3. Performance measurements

for 1.) logging of errors, exceptions, trace outputs:

For this you need the configuration classes from the namespace "gip.core.autocomponent"

• LoggingConfiguration <LoginConfiguration>
• LogFileElement <addLogfile> + LogFileCollection <LogFiles>
• LoggingTypeElement <addLoggingType>  + LoggingTypeCollection <LoggingTypes>

 Example:

 

The <addLoggingType> element is used to define a file type or filter rules that specifies which message types and from which automation components are to be written to a file. You then refer to this file type in the <addLogFile> element via the attribute "FileType". With <addLogFile> you define the log file to be written.

Attributes/properties of <addLoggingType> :

• FileType: A freely assignable name that is referenced in <addLogFile>.
• MessageType: Specifies the message type to be logged to. The following values are possible which are defined in the Enumerator gip.core.datamodel.eMsgLevel: Default, Debug, Info, Warning, Failure, Error, Exception, Command, Status, Statusdetail, Question. If Default is specified, then all message types are logged.
• Source: Specifies the ACUrl of a component to be logged specifically. If Default is specified, the messages are output from all components.

Attributes/properties of <addLogFile> :

• FileType: Specifies which file type or filter rule to use.
• FileName: Format command for the file name to be created. For the placeholder %Date% the current timestamp is entered, for the placeholder %ProcessId% for the current process ID. Logfiles are written exclusively to the temporary user directory (%userprofile%\AppData\Local\Temp). Another path cannot be specified. 
• MaxSizeMB: Maximum log file size in MB. If the file size is exceeded, a new file is created and the counter is increased. The counter is always set at the end before the file name extension. E.g. ...3.txt.
• ArchiveAfterDays: After this time period, old log files are zipped automatically. If 0 is specified, no archiving takes place.

to 2.) Long-term storage of process variables/properties

The setting which variable is to be logged is made in the property tab in the iPlus development environment. A separate database file is created monthly for each variable (https://en.wikipedia.org/wiki/Extensible_Storage_Engine). Old archives are automatically deleted after three months. If you want to extend this default setting, the DeletePropLogAfterXMonths property must be defined in the LoggingConfiguration class and the value must be specified in months.

Performancelogger settings

Programmers can use the class gip.core.datamodel.PerformanceLogger in source code to perform time measurements for function calls or code sections. To activate the Performance Logger you have to use the configuration class gip.core.datamodel.PerfLogConfiguration: