Nobody thinks much about logging while everything is running. And then very intensely, when it isn't.
Logging is the least spectacular function in a machine application. It delivers no feature you can sell in a specification, and in normal operation nobody notices it is there. It proves its worth in exactly one moment: when someone needs to know what actually happened – and the installation has been in the field for years.
The phone call after three years
The pattern is always the same. An installation runs reliably for years. Then it stands still on a Tuesday morning, and the question is: what happened at 03:47 last night? The operator remembers a message but no longer which one. The developer who built the project back then has left the company.
Whether that question is answered in hours or in days is not decided on Tuesday morning. It is decided years earlier, during commissioning – by whether anyone considered that this question would come up at all.
Why "just write to a file" isn't enough
The obvious reflex is to write a line to a file when a fault occurs. In practice that leads to three problems, all of which surface later.
Writing blocks. File access takes time – and if it happens inside the cycle, the controller waits. As long as the log rarely writes, nobody notices. In exactly the situation where you get many messages, namely during a fault, the diagnostic tool becomes part of the problem.
You end up with a wall of text. Free text without structure cannot be filtered, sorted or analysed later. What is missing is not more lines, but reliable fields: time, severity, origin, affected order.
The context is missing. "Drive error" helps nobody. What matters is which drive, in which state, on which batch, on which machine – and no one voluntarily writes all that at every point in the code.
The controller must not wait
That is why the first point of a usable logging concept is not a feature but an architectural decision: the call in the application code and the actual writing have to be separated.
With the AS Logger, the call hands the message to a decoupled queue and returns immediately. The writing happens asynchronously behind it. For you as a developer that means: you may log where it makes sense functionally – not only where it currently looks harmless in terms of timing. That is a bigger difference than it sounds, because it decides whether the interesting places are logged when it matters, or only the harmless ones.
One event, several targets
The second point: a log event does not have one target, but several – simultaneously. The operator at the machine needs the latest messages right away in the visualisation. The service technician looks into the controller's log. And anyone running several installations wants to see the messages centrally on a server, without connecting to each machine individually.
That is exactly what the output targets – "sinks" in the AS Logger – provide. Available are a memory ring buffer that feeds the visualisation with alarm list and history, a console output, the controller's CODESYS log, and syslog per RFC 5424 over UDP for central analysis. Several of these can run in parallel, each with its own filter. And if you need a target that isn't included, you add it through the open ISink interface without touching the rest.
Structure instead of a wall of text
For anything to be analysable later, the message needs structure. The AS Logger works with six log levels – TRACE, DEBUG, INFO, WARN, ERROR and FATAL – and a fluent API that lets you assemble a message in a single line.
More important than the levels, though, is how values are handled. Messages are not passed as finished prose but with {key} placeholders: the message stays a template, the values stay fields. That is the difference between a line you can read and a line you can search.
Recurring context is handled by decorators. Timestamp as well as machine and host context are attached centrally instead of being dragged along at every call site. That keeps the calls in the application code short and ensures the context is complete even when a project had to move fast.
What does not belong in the log
A point that regularly surfaces too late in practice: not everything that technically passes through the logger may be stored permanently in a file or leave the plant network. Recipe values, customer references, credentials – as soon as logs are collected centrally or passed on, this becomes a topic.
The AS Logger can mask sensitive fields (redaction) and filter differently per output target – by level and by alarm severity. In practice that means: the visualisation may show more than the log that goes to the central server. Retrofitting that separation is unpleasant; having it from the start costs nothing.
From log to alarm
Logging and alarming are related but not the same: an alarm is a state someone has to acknowledge, a log entry is an event that gets documented. For diagnostics you need both together – the alarm history and what happened around it.
The AS Logger therefore logs alarms with severities and alarm codes and can be connected to the alarm handling through a listener interface. On top of that come diagnostic counters for the messages themselves: how many were created, how many written and how many dropped. The last value is the most important one, because it is the only way to notice at all that a log is incomplete – a gap you would otherwise discover in a service case, which is exactly when it hurts.
What this means for your project
- You may log where it fits functionally – asynchronous writing removes the fear of cycle time.
- One message, all targets – visualisation, CODESYS log and syslog in parallel, without duplicated code.
- Analysable, not just readable – levels and
{key}fields instead of free text. - Careful with data – redaction and per-target filters, from the start.
- Extensible – your own sinks, decorators and filters through open interfaces.
None of this is spectacular. But it is the difference between a log that answers the question in a service case and one that merely confirms that something happened at some point.
The AS Logger is available now in the CODESYS Store; the demo video shows what it looks like in a project.
— Jürgen Renner, Managing Director, ASKS GmbH