• Skip to main content
  • Skip to header right navigation
  • Skip to site footer
CDP Studio logo

CDP Studio

The no-code and full-code software development tool for distributed control systems and HMI

  • Doc
  • Why CDP
    • Software developers
    • Automation engineers
    • Managers
  • Products
    • Automation Designer
    • HMI Designer
    • Maritime HMIs
  • Services
  • Use cases
  • Pricing
  • Try CDP

CDP Studio Documentation

  • Framework - Data Logging
  • CDP Logger Configuration Manual
  • 5.0.2

How to Setup Logging in Automation System EventLogReader

CDP Logger Configuration Manual

Introduction

This manual describes the CDP Logger component in CDP Studio, the independent automation software for open PC-based real-time distributed control systems.

The CDP Logger is a component for logging values and events. It is designed for long-term storage of high-frequency numeric data. Depending on the selected datastore, data is either stored to a local file or a remote server, see the Choosing a Datastore page for more information. CDP Logger also contains a server for remote access to logged data, see Viewing Data.

Note: The CDP Logger is a licensed feature. See the CDP Runtime License manual for more information.

Usage

To set up a CDP Logger for an application, simply add it as a subcomponent. Next, add a Datastore to the CDP Logger component (e.g. CDPCompactDatastore). To actually log something, add LoggedValue nodes and set the Routing attribute to any signal or property in the system. Alternatively, you may right-click on any signal or property and select Add to Logger...

Example

See the How to Setup Logging in Automation System page for a step-by-step example.

Features

Note: Some features like data retention policies are defined in the settings of the selected Datastore.

Stale Data Detection

Each LoggedValue can have StaleDataDetection enabled. When the value has not changed for a time configured by the logger component's StaleDataCheckIntervalSec property, an alarm is set. For maximum confidence that the whole logging pipeline is working as intended, the check is performed by reading back the logged data from the datastore.

Note: This feature requires that the selected datastore supports reading back the data, so it is not available for all datastores (e.g. CSVDatastore). An alarm is set when the StaleDataDetection is enabled for an unsupported datastore.

It is recommended to enable StaleDataDetection for all LoggedValues that are expected to change frequently. In addition, enable it at least for one LoggedValue per application to ensure sibling CDP applications have started correctly and are producing data.

Tagging Data

The CDP Logger supports tagging logged data with metadata such as unit, description, and other custom tags. Tags can be set for each LoggedValue individually by modifying the Tags property of the LoggedValue node. Additionally, the CDP Logger supports TagLookup rules that allow fetching tags from the logged node or its parent nodes. This is useful for automatically tagging logged data with relevant metadata without having to manually set tags for each LoggedValue.

Built-in Server

The CDP Logger contains a built-in server that allows remote access to the logged data, see Viewing Data.

The server listens on a configurable port and can be bound to a specific network interface. The server port can be configured by setting the ServerPort property, and the network interface can be set by modifying the ServerInterface property. If the ServerInterface is left empty, the server will listen on all available network interfaces.

Delta Logging

The CDP Logger supports delta logging, which means that it only logs value changes that are larger than a configured delta value. This is useful for reducing the amount of logged data, especially when logging high-frequency signals that change frequently but only by small amounts. The delta value can be set for each LoggedValue individually by modifying the Delta property of the LoggedValue node. When the delta value is set to 0, all value changes are logged.

Size Alarm

The CDP Logger can set an alarm when the size of the datastore exceeds a configured limit. This is useful for monitoring the growth of logged data and ensuring that the datastore does not become too large. The size limit is set by the SizeAlarmGB property

Advanced Features

Other less frequently used features are described in the Advanced Features section.

Configuration

Here is a list of configuration options specific to this component.

LoggedValue

LoggedValue represents the node (signal or property) that is logged.

PropertyDescription
NameUnique identifier for the logged value. Also used as a friendly name when viewing logged data.
RoutingFull path of the signal or property we want to log.
RoutingStatusShows whether connecting to the node specified by the Routing property was successful.
DeltaValue change is only logged if it changes more than 'Delta'. Use this to save disk space.
StaleDataDetectionIf true, an alarm is set when the value has not changed for a time configured by the logger component's StaleDataCheckIntervalSec property.
IsStaleIf StaleDataDetection is enabled, this indicates whether the value is stale, i.e., it has not changed for a time configured by the logger component's StaleDataCheckIntervalSec property.
TagsSemicolon-separated key-value list of metadata associated with the logged value (e.g. "tag1=val1;tag2=val2"). Note, that this will override any tags fetched by TagLookup.
EffectiveTagsDuring runtime, displays the combination of tags set directly on this LoggedValue and tags found by TagLookup rules.
EffectiveTagSourcesDuring runtime, displays the full path of source nodes for tags found by TagLookup rules. For example, when using a TagLookup rule with SearchType='Node in scope', this property will allow us to determine on which level the tag was found.

Datastore

Datastore is the backend used by CDP Logger, usually some database. The default is CDPCompactDatastore.

For more information about datastores, see the Choosing a Datastore page.

TagLookup

TagLookup defines a tag that should be fetched for each LoggedValue (if available) and for each node that emits a CDP event (when Event Logging is enabled) and saved to the chosen Datastore as metadata for the node. The tag for a LoggedValue is fetched once during startup while for an event sender, it is fetched when it emits the first event.

For example, a TagLookup with SearchType='DirectChild' and Value='Unit' means that for each logged value, if the value has a child named "Unit", it will be saved at startup.

Note: When a tag for a node is not found on a subsequent startup anymore, what happens will depend on the chosen datastore implementation. The default CDPCompactDatastore will delete missing tags and only keep the most up-to-date information. Other implementations are recommended to do the same.

PropertyDescription
NameName of the tag key.
ValueEither the direct child of the target node or a node in scope that is used to retrieve the tag value (for example 'Unit') or a constant value. In the case of SearchType being "Direct child" or "Node in scope", the Value can refer to any child of the logged value but also to the following node intrinsic attributes: Name, Model, Value, Type (the value type, e.g. "double").
SearchTypeConfigures how to look for the node specified by Value. The options are:
  • Direct child - the Value must be a child of the logged node. Use dot (.) to refer to the parent of the logged node, e.g. '.Model' will refer to the parent node's 'Model' attribute.
  • Node in scope - when the logged node does not contain a child matching Value, the parent nodes are searched until the node is found.
  • Constant - the Value is used as a constant. Use this to set the same tag to all logged nodes, e.g. "ship_name = MyShip".
EnabledAllows to enable/disable fetching of a tag.
TagNameOverrideNormally a tag name is taken from the Name property but in case the desired tag name is a reserved word or contains characters that can't appear in the Name property, this property can be used to set the tag name. Leave this empty to use Name as the tag name.

By default, the following tags are fetched for each LoggedValue and each event sender:

  • unit - the unit of a logged value (if available).
  • description - the description of a logged node (if available).
  • metric - a container for related values from a single measurement or device (e.g. "weather_sensor" metric can contain "temperature" and "humidity" values). It is used by some Datastores when creating the schema (for example, the metric could become a table name in a database). By default, it is the Model of the logged node's parent.
  • label - the type of the logged data, e.g. "temperature" or "humidity" (it does not have to be unique). It is used by some Datastores when creating the schema (for example, the label can become a column name in a table). By default, it is the short name of the logged node.
  • group - the Group property of a CDPAlarm. Useful for filtering logged alarm events.

If the default TagLookup rules are not suitable, they can be disabled by setting the Enabled property to false.

Event Logging

When enabled, the logger will subscribe to CDPAlarm (Set, Clear, Acknowledge) and other CDP events and log them to the selected Datastore.

PropertyDescription
IgnoreReprisesA reprise event is a repetition of a CDP event that has been reported before - courtesy for late subscribers. For example, CDPAlarms periodically report that they are still active. Ignoring reprises will reduce datastore size but when a datastore reaches its size limit and starts deleting older data, the reprises can be used to determine that an alarm is still active.

Note: Each application has an internal buffer for a few thousand events by default, so if the logger application is started after the event has been reported, it will still be logged.

SenderPathRegexRegular expression to match the event sender's full path for the event to be logged. If empty, all events from all applications will be logged.

Note: CDP does not currently provide any widgets for browsing logged event data (e.g. CDPAlarm Set, Clear and Acknowledge events). Datastore-specific third-party tools must be used. If necessary, use the EventLogReader sequencer block and connect it to a LogWriter block to export event data to a different datastore, for example to CSV - see the example here.

Signals

SignalDescription
SamplesDroppedLastMinuteThe number of samples the logger skipped when the application was overloaded during the last 60 seconds. This can happen when the datastore is too slow to keep up with the logging frequency. An alarm is set when a sample is dropped.
SamplesLoggedLastMinuteThe number of samples (changed values and events) received by the logger and forwarded to the selected Datastore during the last 60 seconds. One can add an alarm operator to this signal to be notified when less data is received than expected which could indicate a problem with the source component or some connection issues.

Properties

PropertyDescription
BufferSpanMinutesWhen logging to buffer (LogToBuf state), this sets the buffer length. Use 0 for default. Can be configured only when PeriodicLogFrequency is set.
InMemoryLoggingStart the logger in LogToBuf state. When false, the logger is started in LogToOutput state.
PeriodicLogFrequencyLogging frequency in Hz. Decreasing the logging frequency will save disk space and improve performance when logging thousands of values. Set it to 0 to log every value change instead of periodically (only valid when Protocol is set to StudioAPI, otherwise it defaults to 100 Hz).
ProtocolProtocol used by the logger to get values. The default is Messenger which uses regular CDPProperty routings passing values through the MessengerIOServer. The second option is StudioAPI which connects through StudioAPIServer (the same way as CDP Studio). See the Advanced Features section for a detailed comparison of the two protocols.
ServerInterfaceA network interface defined in the application node. The selected interface will be used by the CDPLogger's built-in server which provides remote access to logged data. Leave empty to listen on all interfaces.
ServerPortPort of CDPLogger's built-in server that provides remote access to logged data.
SizeAlarmGBSets an alarm when the datastore has exceeded the specified size. Use 0.0 for no limit.
SizeGBDuring runtime displays the current size of a datastore in gigabytes.
StaleDataCheckIntervalSecSets an alarm when LoggedValues have StaleDataDetection enabled and their values don't change during the interval. Use 0.0 to disable the checks.

Viewing Data

CDP Logger contains a server for remote access to the logged data that can be used to view data no matter which datastore is used.

There are several options to view logged data through the log server:

  • Using CDP Studio Analyze mode Historic Data functionality which will detect a running CDP Logger or LogServer and connect to it. The Analyze mode can also be used to export the logged data to CSV format.
  • Making your own GUI application that includes Database Graph Widget.
  • Python code can query values from a running CDP Logger or LogServer using the PythonCDPLoggerClient.
  • The ValueLogReader and EventLogReader sequencer blocks can be used to extract and process logged data.

The selected Datastore might provide other custom ways to view logged data. See the manual for the selected datastore to get specific information on that.

Note: CDP does not currently provide any widgets for browsing logged event data (e.g. CDPAlarm Set, Clear and Acknowledge events). Datastore-specific third-party tools must be used. If necessary, use the EventLogReader sequencer block and connect it to a LogWriter block to export event data to a different datastore, for example to CSV - see the example here.

Advanced Features

Here are some advanced features of the CDP Logger that are not commonly used but can be useful in specific scenarios.

In-Memory Logging

The CDP Logger has limited support for in-memory logging, which means that it can log data to temporary buffers instead of directly to the datastore. This is useful for scenarios where you want to log data only when certain conditions are met, such as when an interesting event occurs.

Note: When in LogToBuf state, the logger does not write any data to the datastore meaning the data can't be viewed or accessed until the logger is switched to LogToOutput state and the buffer is written to the datastore.

The in-memory logging can be enabled by setting the InMemoryLogging property to true. When in-memory logging is enabled, the logger starts in the LogToBuf state. The content of the buffer can be written to the datastore sending the LogToOutput message. The buffer span can be configured by setting the BufferSpanMinutes property.

Switching the Front-end Protocol

The CDP Logger supports two front-end protocols: Messenger (the default) and StudioAPI. It is configured by the Protocol property. The front-end protocol determines how the logger retrieves values from the CDP system.

Messenger Protocol

The Messenger protocol is the default protocol used by the CDP Logger. It uses regular CDPProperty routings to retrieve values from the CDP system (through the MessengerIOServer component).

Benefits:

  • It is well-established and widely used in the CDP ecosystem.
  • It supports all CDPProperty-based nodes, including signals, arguments, parameters and properties - it can log any value that can be routed in a CDP system.
  • It is suitable for most use cases where periodic logging of values is sufficient.
  • Excellent performance when logging values from the same application where the logger is as local values are retrieved directly from the CDPProperty nodes without going through the network.
  • Logging local values continues to work even when the network interface is down.
  • For nodes where the Value property has RouteType=Periodic (e.g. all CDPSignals, CDPSignalChannels and Arguments), the values are published at a fixed frequency even when not changed, making the protocol highly resilient to packet loss and temporary network issues.

Limitations and drawbacks:

  • It only retrieves values from nodes that are either CDPProperties or have a child CDPProperty called Value, which means it cannot log some values seen in CDP Studio (e.g., CDPSettings).
  • Periodic properties publish their values at a fixed frequency (whether changed or not), which may cause excessive network traffic when logging signals from high-frequency components residing in a remote application.
  • Only periodic logging is supported (configured by the PeriodicLogFrequency property). There is no option to log every value change as it happens.
  • Timestamps of logged values are assigned by the logger when the value is received, which may not match the exact time when the value was produced by the source application.
  • For remote applications, the CPU load is usually similar to the StudioAPI protocol, although the latter can have an advantage in case of many rarely changing values.

StudioAPI Protocol

With the StudioAPI protocol, the logger retrieves values through the StudioAPIServer - the same way as CDP Studio.

Benefits:

  • It allows logging every value seen from CDP Studio, including CDPSettings and other non-CDPProperty nodes.
  • It supports logging every value change as it happens instead of periodically checking for changes. To enable this, set the PeriodicLogFrequency property to 0.
  • The protocol provides a timestamp for each value change, which is the exact time when the value was produced by the source application, not when it was received by the logger. Note, this is only used when sampling is disabled by setting the PeriodicLogFrequency property to 0.
  • Reduced network traffic because it only sends changed values and for high-frequency values, multiple changes are sent in a single packet (with exact timestamps of each change).

Limitations and drawbacks:

  • The protocol is more advanced and complex, which often causes a higher CPU load.
  • Even logging local values requires a network connection to the StudioAPIServer, which causes some performance overhead and also means that logging local values does not work when the network interface used by StudioAPIServer is down.

Note: The protocol selection only affects how the logger retrieves values from the CDP system. The events are always retrieved with the StudioAPI protocol. In addition, all the tags defined by TagLookup rules are fetched with the StudioAPI protocol. This means that only simple value logging will continue to function if the StudioAPI connection fails.

Internal Properties

When disabling the Hide Internal Items filter, some additional properties become visible. It is normally not necessary to access them.

PropertyDescription
fsThe frequency [Hz] that the component state machine is run at. While each CDPComponent has this, it is hidden by default for the logger because the logging frequency is controlled by the PeriodicLogFrequency property. When the Protocol is set to Messenger, the fs is automatically set to the same value as the PeriodicLogFrequency property. When the Protocol is set to StudioAPI, the fs does not affect the logging frequency.
TagsFetchTimeoutSecWhen the Protocol is set to Messenger, the logged value tags defined by the TagLookup rules are still fetched over StudioAPI. This sets the StudioAPI connection timeout - when reached, the logging will proceed without tags info and a warning is printed to the Application Output pane.

How to Setup Logging in Automation System EventLogReader

The content of this document is confidential information not to be published without the consent of CDP Technologies AS.

CDP Technologies AS, www.cdpstudio.com

Get started with CDP Studio today

Let us help you take your great ideas and turn them into the products your customer will love.

Try CDP Studio for free
Why CDP Studio?

CDP Technologies AS
Hundsværgata 8,
P.O. Box 144
6001 Ålesund, Norway

Tel: +47 990 80 900
E-mail: info@cdptech.com

Company

About CDP

Contact us

Services

Partners

Blog

Developers

Get started

User manuals

Support

Document download

Release notes

My account

Follow CDP

  • LinkedIn
  • YouTube
  • GitHub

© Copyright 2025 CDP Technologies. Privacy and cookie policy.

Return to top