Event logger as the very first function implemented in the program

Article#: 00082

Date: 2023-02-05

Author: Radim

It is necessary to know what is happening in the program, especially when something is not going according to our expectations.
A logger allows us to record and track events that occur while a program is running. This can be particularly useful for debugging and fixing problems that may arise. In addition, a logger can be configured to output event messages at different levels of severity, such as errors, warnings and informational messages.

Logger as a program module (function block) must meet a number of requirements:
1. Logger must work reliably and already be available as the first module in the program, since we will use it to log events from other modules. Entries in the log file can help when programming and testing these modules.

2. After starting the system, only when the logger has been successfully initialized and is ready to log messages we can start also the rest of the program. Otherwise we have to generate an error message in the visualization that the logger could not be started and is not working.

3. Logged messages must persist after the system restarts so we can view past events. (Often the last messages before the system crash are very important to find the cause of the problem, so we need to be able to record and keep them.)

4. Logged messages should be time-synchronized and sorted chronologically together with the system messages, which are normally logged by the system, in order to identify possible dependencies between system events and our application events. It's worth considering if we want to use the same storage/log file for our reporting as the system uses for reporting system events.

5. The content of the log file is primarily intended for developers, so we don't have to worry about translating the messages into the customer's local languages. The log file does not have to be accessible from the visualization either. (There will be other tools implemented into the visualization that inform the operator about machine, system and operator events, such as current alarms, historical alarms and events, etc.)

6. The logger must allow fast recording, as fast as the fastest PLC cycle, to be able to record each event.

7. When our program is split into multiple task classes, where a faster and higher-priority class interrupts a slower and less-priority class, we need to prevent inconsistent data recording. Inconsistent data recoding can occur when one instance of the logger module is logging messages from a slow task program and is interrupted by a faster task program that also wants this logger instance to log another message. In this way, the recorded message may incorrectly consist of two parts, each dealing with a different event. And it might not be obvious when we analyze the log file.

8. We need to be able to record messages after a power failure occurs. From the log file, we need to know that the power failure occurred and whether the system stopped properly after the power failure. Normally, the system requires an uninterruptible power supply (UPS) to stop properly in the event of a power failure. And our logger module must be able to write and save the messages while the system is stopped due to the power failure.

9. We (the developers) need to have access to the log file and be able to copy the log file from the machine to our PC. And this, for example, via remote access.
Even if the PLC can no longer start, the log file must be accessible (e.g. via a CF card reader).

10. We need to monitor that the log file doesn't take up all the free space on the local storage. It is necessary to monitor the size of the log file and the remaining free space on the storage. It is also advantageous to create new log files every 24 hours, for example, and copy old log files to a server when it is available.

11. When calling up the logger module to write a message to the log file, it must be ensured that the message, once written, is not written repeatedly in each PLC cycle, if the condition for writing this message is still set. This would quickly fill the log file with unnecessarily repetitive messages. (In the case of a ring buffer log file, it would even overwrite older and possibly important records.)

12. We only find messages in the log file that we have written there :-). So it's a good idea to record rather more events. Of course, the most important messages are the ones that let us know that something didn't go as expected. In addition, it can also be important to know how the program is executed - the order in which functions are called and what values they return and how the state machine steps are switched, etc. For example, we can distinguish between several levels of severity of the messages such as: success, info, warning, error.
If the program has already been well debugged and tested, we no longer need to record success and info messages in order not to overload the log file with irrelevant information. However, it still makes sense to keep this option. That's why it's good to have a configurable severity level of messages that the logger should write to the log file. Ideally, we should not only be able to activate and deactivate the levels in ascending order, but individually.
Enabling and disabling the logger severity levels must be possible from outside the program (e.g. in a configuration file) so that we don't have to recompile the program if we want to log more events.
It is also useful to be able to trace back lower severity events when an error severity event occurs. For this purpose, the logger module should have a local ring buffer in which all severity events are recorded, and the ring buffer should be copied to the log file in the event of an error.

13. From time to time we need to check the log file to make sure there are no error messages. If so, we need to investigate and solve the cause. The log file should not contain any error messages on a stable system.

14. The logger module should also notify the operator via an alarm on the visualization if an error message has been recorded in the log file. Only a general alarm message like "An error has been recorded!" with an alarm help like "Contact the software developer!" should be displyed on the visualization. Because the error in the log file is not intended for the system operator, but for the software developer.

15. In order to be able to locate easily a problem in the program, it is good if each event logged in the log file has its own unique identification number.

© Radim-Automation, 2020–2025. All rights reserved.
Sharing of this article is permitted with proper attribution (link to the original page).

Related previous articles:

Related next articles:

Comment#: 00001

Date: 2023-02-07

User: Radim

The recorded message can contain these parts:
TIMESTAMP - date and time with sufficient precision (milliseconds)
SOURCE OBJECT ID - identification number of the instance object where the event occurred
EVENT ID - unique event identification number
SEVERITY - e.g. Success, Info, Warning, Error
MESSAGE TEXT - Message itself describing the event

Comment#: 00002

Date: 2023-02-07

User: Radim

I noticed very strange behavior of the program/system due to lack of memory and CPU overload. It led me to believe that it is, in any case, appropriate to monitor the available free memory and percentage reserves of CPU usage and, in the event of a significant reduction in reserves, make a log file entry. So that we can possibly attribute the problematic behavior to a lack of memory or CPU performance.

Comment#: 00003

Date: 2023-07-21

User: Radim

"The essential function of the PLC is to receive data from sensors or other field devices; make a decision on what to do with that information based on its programming instructions, for example, to open or close a valve based on fluid levels or direct a robot to pick up an object based on its presence in the work cell; and send the correct signal to the actuator (such as a valve or robot gripper) to perform the task."
- David Greenfield. AutomationWorld (2023). Peer-to-Peer FAQ: Controllers.
- https://www.automationworld.com/control/article/22724233/industrial-controller-technologies

Comment#: 00004

Date: 2023-08-11

User: Radim

"How to eliminate fifty percent of your business worries.

Everyone who wishes to present a problem to me must first prepare and submit a memorandum answering these four questions:
1. What is the problem?
2. What is the cause of the problem?
3. What are all the possible solutions of the problem?
4. What solution do you suggest?

My associates rarely come to me now with their problems. Why? Because they've discovered that in order to answer those four questions, they have to get all the facts and think their problems through. And they've done that, they find in three-fourths of the the cases they don't have to consult me at all because the proper solution has popped out like a piece o fbread popping up from an electric toaster. Even in those cases where consultation is snecessary the discussion takes about one-third of the time formely required because it proceeds along an orderly, logical path to a reason conclusion."

- Dale Carnegie. Crescent News (1944). How to Stop Worrying and Start Living.
- https://www.youtube.com/watch?v=fKzlc_N2yxw (01:07:50 - 01:09:53)

Comment#: 00005

Date: 2023-08-11

User: Radim

"Basic techniques in analysing worry:
Rule 1 - get the fact. Half the worry in the wold is caused by people trying to make decisions before they have sufficient knowledge on which to base a decision.
Rule 2 - after carefully weighing all the facts come to a decision.
Rule 3 - once a decision is carefully reached, act, get busy carrying out your decision and dismiss all enxiety about the outcome.
Rule 4 - when you or any of your associates are tempted to worry about a problem, write out and anser the following questions:
a) What is the problem?
b) What is the cause of the problem?
c) What are all possible solutions?
d) What is the best solution?"

- Dale Carnegie. Crescent News (1944). How to Stop Worrying and Start Living.
- https://www.youtube.com/watch?v=fKzlc_N2yxw (01:12:50 - 01:13:50)

Comment#: 00006

Date: 2023-09-11

User: Radim

Does it make sense to think about digitalization if we don't see any use case?

"If you don't see any practical use case or clear benefit for digitalization in your specific situation, it may not make sense to pursue it blindly. Digitalization should always align with your organization's goals and needs. Here are some considerations:

1. Assess Business Objectives: Start by identifying your organization's objectives and challenges. Digitalization should align with your strategic goals, whether it's improving efficiency, reaching new markets, enhancing customer experiences, or reducing costs.

2. Customer Demands: Consider whether your customers or clients expect or would benefit from digital solutions. If there's no demand for digital services, investing in them may not provide a return on investment.

3. Competitive Landscape: Analyze your competition. If your competitors are effectively utilizing digital technologies to gain a competitive advantage, it might be necessary to explore digitalization to stay relevant.

4. Cost-Benefit Analysis: Conduct a thorough cost-benefit analysis to determine if the potential benefits of digitalization outweigh the costs. If the investment doesn't offer a reasonable return, it might not be justified.

5. Resource Availability: Evaluate whether you have the necessary resources, including financial resources, technical expertise, and staff training, to implement and sustain digital solutions effectively.

6. Future Growth: Consider the scalability of your organization. Even if you don't currently see a clear use case for digitalization, it's essential to think about your organization's future growth and whether digital technologies could play a role in that growth.

7. Technology Trends: Stay informed about industry trends and emerging technologies. While there may not be an immediate use case, technological advancements could create new opportunities down the line.

8. Customer Feedback: Engage with your customers or stakeholders to gather feedback on their needs and preferences. They may provide insights that could uncover potential use cases for digitalization.

9. Pilot Projects: Instead of a full-scale digital transformation, consider starting with smaller pilot projects to test the waters and assess the feasibility and impact of digital solutions in a controlled environment.

10. Consult Experts: Seek advice from digital transformation consultants or experts in your industry. They can provide insights into potential use cases and help you determine if digitalization is appropriate for your organization.

In some cases, it may indeed be the case that digitalization doesn't make sense for your organization at a given time. However, it's essential to regularly revisit this assessment as technology and business landscapes evolve. What might not be relevant today could become essential in the future. Ultimately, the decision to pursue digitalization should be guided by a thorough understanding of your organization's unique needs and circumstances."

- https://chat.openai.com (Does it make sense to think about digitalization if we don't see any use case?)

Comment#: 00007

Date: 2023-09-27

User: Radim

"By continuously improving the design of code, we make it easier and easier to work with.
This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently add new features.
If you get into the hygienic habit of refactoring continuously, you'll find that it is easier to extend and maintain code."

- Joshua Kerievsky. Addison-Wesley (2004). Refactoring to Patterns.

Comment#: 00008

Date: 2023-10-02

User: Radim

How to get the right intuition?

"Developing and honing your intuition can be a valuable skill, but it's important to remember that intuition is inherently subjective and can't always be "right" in an objective sense. However, you can work on improving the accuracy and reliability of your intuition by following these tips:

1. Increase Your Knowledge and Experience: The more you know about a particular subject or domain, the better your intuition is likely to be within that area. Gain expertise and experience through study, practice, and exposure.

2. Trust Your Gut: Pay attention to your gut feelings or initial impressions. Sometimes, your subconscious mind processes information faster than your conscious mind, leading to intuitive insights. Don't dismiss these feelings outright; give them consideration.

3. Practice Mindfulness: Mindfulness meditation can help you become more aware of your thoughts and feelings. This self-awareness can improve your ability to recognize and trust your intuition.

4. Keep a Journal: Maintain a journal where you record your intuitive hunches and the outcomes. Over time, this can help you assess the accuracy of your intuition and learn from your experiences.

5. Seek Feedback: Discuss your intuitive insights with trusted friends, mentors, or colleagues. They can provide valuable perspectives and help you refine your intuition by offering feedback on your decisions.

6. Validate with Data: When possible, seek out data or information that can confirm or refute your intuitive impressions. This can help you develop a more evidence-based form of intuition.

7. Relax and Clear Your Mind: High-stress levels or a cluttered mind can cloud your intuition. Engage in relaxation techniques like deep breathing, meditation, or progressive muscle relaxation to clear your mind and enhance your intuitive abilities.

8. Ask Open-Ended Questions: When facing a problem or decision, ask yourself open-ended questions and let your mind wander. This can stimulate creative and intuitive thinking.

9. Learn from Mistakes: Embrace your intuition's imperfections. When your intuition leads you astray, use those experiences as learning opportunities. Analyze what went wrong and adjust your intuition accordingly.

10. Practice Patience: Sometimes, intuition needs time to develop. Don't rush your decision-making process if you're unsure. Give yourself the space to allow your intuition to emerge.

11. Combine with Analysis: Balance your intuition with analytical thinking. For important decisions, use your intuition as an initial guide but then follow up with critical analysis and data-driven assessment.

12. Cultivate Emotional Intelligence: Understand and manage your emotions effectively. Emotional intelligence can enhance your ability to perceive and interpret your own and others' emotional signals, which can inform your intuition.

Remember that intuition can vary from person to person, and it's not always infallible. It's a skill that you can refine over time, but it's also important to recognize its limitations and use it as a complementary tool alongside rational thinking and evidence-based decision-making when appropriate."

- https://chat.openai.com (How to get the right intuition?)

User:

Log in user:

Log in user:

Log in user - Failure:

Log in user - Failure:

Request password:

Request password:

Request password - Failure:

Register user:

Register user:

Register user - Failure:

Register user:

Register user - Failure:

Register user:

Register user - Failure:

Register user:

User settings:

User settings:

User settings:

User settings: