<< 点击显示目录 >> 主页  exOS使用助手 > exOS Automation Help > Diagnose > Function blocks > ExLogConfig

功能块

 

参数

 

数据类型

ExLogConfigType - exOS 记录仪配置。

 

使用方法

该功能块只接收 ExLogConfigType 结构的地址  。

ExLogConfig_0(Enable := TRUE, LogConfig := ADR(LogConfig))；

关于 StatusID 输出，请参阅 功能块 StatusID。

 

说明

ExLogConfig 功能块的作用是在运行期间读出或配置 ExData 记录仪的配置。

 

系统背景

数据连接记录器的内置功能是从 AR 和 Linux 上的各种程序中收集日志信息，并将这些信息收集到中央记录器中。由于 exOS 在两个平台上运行，收集日志信息意味着在两个系统之间发送数据。为了避免不必要的流量，日志信息的过滤直接在每个日志 模块 （使用 exos_log 实例的应用程序 ）上进行。 这样， 只要日志级别 设置为 成功等，应用程序就可以 在 代码中 输入各种 调试 或 信息信息， 而不会造成额外的数据流量 。

 

运行时更新

由于应用程序错误往往只在特定情况下出现，而日志信息的正常生产设置很可能比 "成功"还低 ，因此 在运行时激活更高的日志级别可能  非常有用，以便在出现特定情况时进行跟踪，而无需更改系统配置。

因此，ExLogConfig 功能块通过 ExLogConfigType提供了与 exOS 目标配置中相同的设置 。

•更新 输入将更改系统上所有应用程序的当前日志级别和过滤器（又称消息类型）。如果任何其他应用程序更改了该设置， ExLogConfigType也 会相应更新。

此功能也可通过 exos_log API 使用 exos_log_change_config 和 exos_log_config_listener 函数实现。.

 

exOS 目标配置中的设置

 

对应的 ExLogConfigType

 

额外的 ExcludeModule

除 exOS 目标配置中的设置外，该功能块还提供了将某些模块排除在日志记录之外的可能性，例如，一旦日志级别提高，这些模块就会变得过于冗长。

在下面的示例中， gHey_0 日志模块不断在日志记录器中输入值，虽然 gWaterTank_0 消息可以在日志记录器 IDE 中过滤，但将 gHey_0 全部 静默可能仍然有用  。

这可以通过 在ExcludeModule 列表  中 添加 gHey_0， 然后使用 Update将 新设置应用到系统中来实现  。

这样， gHey_0就会 被阻止发送日志信息，直到它从 ExcludeModule 列表 中删除  或系统重新启动。

 

排除 exos-data 模块

如果  设置 了LogConfig.Filter.System（ 相当于 exostarget 日志记录器配置  中 的DMR 消息 ），"exos-data "条目将被添加到日志记录器中。该名称代表 DMR日志 模块 的集合  ，在 AR 日志记录器中显示为 "exos-data"，以便更简单地过滤 "所有 DMR 消息"。不过，为了通过 LogConfig.ExcludeModule 过滤器排除 "exos-data "模块的日志记录，需要使用实际的模块名称。

exos-data 包含以下日志模块：

•exos_msg_server：DMR 消息路由器，用于发送和接收来自 api 和 lxi 的连接和数据集。如果启用了 "详细记录 "功能，lxi 会在这里输出大量附加信息。

•exos_srv_server：DMR 数据模型数据库和执行调度程序

•exos_sync_master：AR 时间同步模块

•exos_sync_slave：Linux 时间同步模块

•exos_log_collector：本地日志收集器，输出新连接和新日志配置

•exos_api_{datamodel_instance_name}：应用程序的 api 后端，输出 exos_api "背后 "的信息。名称基于数据模型实例名称，例如 exos_api_WaterTank_0

---

Function Block

Parameters

Data types

ExLogConfigType - exOS Logger configuration.

Usage

This function block only takes the address of an ExLogConfigType structure.

ExLogConfig_0(Enable := TRUE, LogConfig := ADR(LogConfig));

For the StatusID output, please refer to the Function block StatusIDs.

Description

The ExLogConfig function block has the purpose to read out or configure the ExData Logger configuration during runtime.

Background

The data connection logger has the built-in feature to collect log messages from various programs on AR and Linux and collect those in a central Logger. As exOS operates on two platforms, this colleting of log messages implies sending data between the systems. In order to avoid unnecessary traffic, the filtering of log messages take place directly at every log Module (application using an instance of the exos_log). In this way, applications can enter various Debug or Info messages in the code without causing additional data traffic, as long as the log Level is set to for example Success.

Runtime updates

Because application errors have a tendency to appear only in certain situations, and the normal production setting for log messages is most likely even lower than Success, the possibility to activate higher log Levels during runtime can be useful in order to track a certain situation when it appears, without changing the system configuration.

Therefore the ExLogConfig function block offers the same settings as available in the exOS Target configuration via the ExLogConfigType.

•The Update input will change the current log Level and Filters (aka Message Types) for all applications on the system. If any other application changes this setting, the ExLogConfigType is updated accordingly.

This functionality is also available via the exos_log API, using the exos_log_change_config and exos_log_config_listener functions.

Setting in the exOS Target configuration

Corresponding ExLogConfigType

Additional ExcludeModule

Additional to the settings in the exOS Target configuration, the function block offers the possibility to exclude certain modules from logging, should they become too verbose once the log level is increased, for example.

In the following example, the gHey_0 log module is continuously entering values in the logger, and although the gWaterTank_0 messages can be filtered in the Logger IDE, it might still be useful to silence gHey_0 allogether.

This can be achieved by adding the gHey_0 in the ExcludeModule list, and using Update to apply the new setting to the system.

With this, the gHey_0 is blocked from sending log messages until it is removed from the ExcludeModule list or the system is restarted.

Exclude exos-data modules

If LogConfig.Filter.System has been set (which is equivalent to DMR messages in the exostarget Logger configuration), "exos-data" entries will be added to the logger. This name represents a collection of DMR logging modules, and are presented in the AR Logger as "exos-data" to make it simpler to filter "all DMR messages" there. In order to exclude the "exos-data" modules from logging via the LogConfig.ExcludeModule filter however, the actual module name needs to be used.

exos-data consists of following log modules:

•exos_msg_server: The DMR message router, sending and receiving connections and datasets from api and lxi. If Verbose logging is enabled, lxi outputs a lot of additional information here.

•exos_srv_server: The DMR datamodel database and execution scheduler

•exos_sync_master: The AR time synchronization module

•exos_sync_slave: The Linux time synchronisation module

•exos_log_collector: The local logging collector, outputs new connections and new log configurations

•exos_api_{datamodel_instance_name}: The api backend for an application, outputs information "behind" the exos_api. Name is based on the datamodel instance name, for example exos_api_WaterTank_0