TM223TRE.40-EnG Automation Studio Diagnostics V4000
TM223TRE.40-EnG Automation Studio Diagnostics V4000
TM223TRE.40-EnG Automation Studio Diagnostics V4000
TABLE OF CONTENTS
1 INTRODUCTION.................................................................................................................................. 4
1.1 Learning objectives................................................................................................................. 4
2 THE CORRECT DIAGNOSTIC TOOL.................................................................................................5
2.1 Checklist.................................................................................................................................. 6
2.2 Overview of diagnostic tools...................................................................................................8
3 READING SYSTEM INFORMATION...................................................................................................9
3.1 Controller operating status......................................................................................................9
3.2 Online comparison................................................................................................................ 10
3.3 Error analysis in Logger........................................................................................................12
4 MONITORING AND ANALYZING PROCESS VALUES....................................................................17
4.1 Monitoring and modifying variables...................................................................................... 17
4.2 Recording variables in real time........................................................................................... 21
4.3 Monitor and force I/O............................................................................................................25
5 SOFTWARE ANALYSIS DURING PROGRAMMING........................................................................ 26
5.1 Configuring the Profiler and evaluating data........................................................................ 27
5.2 Searching for errors in the source code...............................................................................31
5.3 Using variables in programs................................................................................................. 37
6 MAKING PREPARATIONS FOR SERVICING................................................................................... 39
6.1 System Diagnostics Manager (SDM)....................................................................................39
6.2 Query the status of the battery.............................................................................................42
6.3 Runtime Utility Center diagnostic tool...................................................................................44
7 SUMMARY......................................................................................................................................... 47
8 APPENDIX..........................................................................................................................................48
8.1 "Loop" sample program........................................................................................................ 48
1 INTRODUCTION
Automation Studio and Automation Runtime provide several different diagnostic functions for machine
programming and commissioning, runtime system analysis , and service operations.
The diagnostics process begins by selecting the right tool for the application or situation at hand.
Figure 1: Diagnostics
Diagnostic functions have been specially incorporated into Automation Runtime that allow the user to
analyze the data it records either with or without Automation Studio.
The System Diagnostics Manager is an integral component beginning with Automation Runtime V3.0.
This training module uses selected examples illustrating different diagnostic possibilities during program-
ming, commissioning and servicing to help you learn how to work with the various diagnostic tools.
You will learn the criteria for selecting the correct diagnostic tool.
You will learn how to evaluate and store general system information.
You will learn how to observe and record process values.
You will learn about the possibilities for diagnosing the system and application.
You will learn which Automation Runtime configuration options are relevant to which diagnostic
tools.
Selecting the correct diagnostic tool makes it possible to quickly and effectively localize a problem.
Analyzing irrelevant data yourself or sending it to someone else for examination can lead to substantial
delays in finding a solution.
The Logger can be used to recognize a cycle time violation. However, the cause of the cycle
time violation would not be best diagnosed by using the Logger in this case.
The cause of the error in the Logger will be given as a cycle time violation in Task Class #1.
The backtrace data also refers to a task where the cycle time violation occurred.
Situation 1
Since a multitasking system allows one task to be interrupted by a higher priority task, it is possible that
this higher priority task is the cause of the cycle time violation. This is because the higher priority task
has a longer execution time in this cycle, which means that the task used in the Logger no longer has a
chance to be completed within its configured cycle time or tolerance.
Situation 2
Several tasks are executed one after another cyclically in the same task class. If one of the previous
tasks takes longer to complete, then the task shown in the Logger will also not be the cause of the cycle
time violation.
In both cases, the Logger window would be the wrong diagnostic tool to determine the error. This
problem can only be detected using the Profiler (5.1 "Configuring the Profiler and evaluating data" on
page 27), which displays the chronological sequence of individual tasks as well as the time needed
for them to complete.
2.1 Checklist
There are a number of different ways to analyze a problem. Combining different localization and analysis
strategies can considerably increase effectiveness when trying to locate errors.
With an optimal overview, specific areas can be isolated and analyzed in greater detail.
The more detailed the actions taken have been documented and information collected, the bet-
ter the chances that the problem can be found (see also training manual "TM920 Diagnostics
and service for end users").
When did the problem begin? Have there been any changes in the software and/or hardware config-
uration or machine environment since then?
In what state is the CPU, and what is the LED status of the accompanying components?
What information has been loaded from the CPU for analysis purposes (no screenshots!)? e.g. log-
ger, Profiler data etc.
Table 1: Checklist for relaying information
Automation Studio provides appropriate tools that can handle diagnostics during programming, commis-
sioning and servicing.
Only by selecting the right diagnostic tool is it possible to accurately and quickly access the necessary
information.
This training manual applies some of the possible diagnostic tools using different tasks.
System information can be read from the target system in Automation Studio as well as with the aid of
an Internet browser.
A number of options are available in Automation Studio for evaluating the operating status of a controller:
3.1.1 "Status bar"
3.1.2 "Information about the target system"
3.2 "Online comparison"
This information can also be read and displayed using the System Diagnostics Manager (6.1
"System Diagnostics Manager (SDM)" on page 39).
The status bar is located at the bottom of the Automation Studio window.
With an active online connection you can query information about the target system using <Online> /
<Info> in the main menu or using <Online Information...> in the Physical View shortcut menu.
The target system's clock can be set manually or synchronized to that of the PC in this dialog box.
Diagnostics and service \ Diagnostic tools \ Information about the target system
To get an overview, it is necessary to check whether the hardware and software configurations in the
opened project match those in the target system. This check is supported by the comparison functions
in Automation Studio.
A window with two columns is opened. The left side shows the elements configured in the software
configuration, while the right side shows the configuration active on the target system.
In this example, the task "LampTest" on the target system has been stopped, whereas the task "Loop1"
is not present on the target system.
The window is divided into two halves. The left side shows the hardware configuration in the project.
The right side shows the hardware configuration which is used at runtime. Differences are indicated by
a red warning triangle.
In this configuration, two digital modules were configured on the X2X Link bus, but two analog modules
are being used on the target system. All other identified modules have not been configured in the project.
Automation Runtime logs all fatal errors (e.g. cycle time violations), warnings and information messages
(e.g. warm restarts) that take place when the application is executed.
This log is stored in the controller's memory and is available after restarting.
The Logger can be opened from the Physical View using the <Open> / <Logger> menu item, <Open
Logger> in the controller's shortcut menu, or using the keyboard shortcut <CTRL> + <L>.
The entries displayed in this image show the events logged by Automation Runtime after cre-
ating CompactFlash data and loading it to the controller.
Exercise: Cause a cycle time violation and check the entries in the Logger
Based on the "Loop" program (8.1 ""Loop" sample program" on page 48) a cycle time violation can
be achieved by incrementing the "udiEndValue" variable in the variable monitor.
Once an online connection has been reestablished between Automation Studio and the target system
after restarting, open the Logger window and look for the cause of the boot into service mode.
2) Increment the "udEndValue" variable until a cycle time violation occurs (loss of connection and
restart in service mode).
Once opened, the Logger indicates the cause of booting in service mode.
Once an entry is selected in the Logger, pressing <F1> displays a detailed error description in the Au-
tomation Studio help documentation. Additional information about error entry is available by displaying
the backtrace.
This opens a description of the selected error number in the Automation Studio help system.
Application case
The logger data is stored by the service engineer
using the System Diagnostics Manager. The trans-
ferred data can now be opened in Automation Stu-
dio and analyzed.
Figure 15: Saving Logger entries
In Automation Studio, Logger entries can be saved
and reloaded from the Logger's toolbar.
Logger functions can also be used by the application program to log certain events that occur within
that application.
This is handled using the functions in the AsArLog library.
Applications:
Logging service actions (e.g. replacing batteries)
Logging user actions
Querying exceptions in the exception task and entering them in the Logger window
Insert the example in the Logical View by selecting <Add Object> / <Samples> / <Library samples>
from the shortcut menu of the main node.
User error numbers are only allowed in the range "50000 - 59999". All other numbers are re-
served by the control system.
If the CPU is still in service mode after the last task, it can be booted back into RUN mode by
performing a warm restart in Automation Studio.
Writing the values 1 and 3 to the step sequencer variable "Logger.Step" generates an entry in
the "usrlog" Logger module.
Process values can be monitored, analyzed and modified in many different ways in Automation Studio.
More information about analyzing NC data can be found in the motion training modules (TM4xx).
The Watch window allows the values of variables on the target system to be displayed, monitored and
modified.
Variable lists can be saved in the variable monitor for the different diagnostic and function tests and
reused at a later time.
Overwriting of process variables during operation may only be carried out by authorized per-
sonnel.
Insert the variables from the table above using the toolbar
or by pressing the <Ins> key.
Once the variables have been inserted in the variable monitor, the process sequence of the
application can be simulated.
2nd Turn on the coffee machine and operate it from the Watch window
1 Switch on
"gMainLogic.cmd.switchOnOff = 1"
2 Check the status of the process
Reaching the temperature setpoint is indicated by "gMainLogic.cmd.vis.messageIndex = 2".
3 Deposit coins
The coins deposited with "gMainLogic.par.givenMoney" must be greater than or equal to the
coffee price "gMainLogic.par.receipe.price".
"diStartCoffee = 1"
5 Monitor the progress of the process
Monitor the "gMainLogic.status.progressStep" variable.
Value = 1 corresponds to filling; Value = 2 corresponds to dispensing the cup.
The variable list in the variable monitor should be saved for later use. This allows the process
sequence to be reproduced at any time.
Variables on the controller can be monitored and modified using the Watch window.
In addition to their values, additional information about the variables such as their scope, data
type and I/O type, is displayed.
Variables can also be managed in separate lists to handle various other tasks.
If a value is changed in the Watch window, it will be transferred to the controller immediately after <Enter>
is pressed.
The controller will then apply the new value in the next cycle.
In order to enter several values in the variable monitor without their being immediately applied, archive
mode must be turned be on.
After the values for the variables that need modification have been entered in the variable monitor, all of
them will be sent to the controller by clicking the "Write values" push button in the toolbar.
It is important to consider which variables have been inserted into the variable monitor when
dealing with synchronous writing operations. Using archive mode incorrectly in this case can
lead to undesirable behavior when changes are made to the process sequence.
In the variable monitor, the controller variables from Automation Studio are read asynchronously1 gele-
sen.
However, this type of asynchronous accessing of the actual value changes in the Automation Runtime
task class system leads to the following limitations:
Value displayed asynchronously to the task class
Unable to determine series of value changes and their dependencies
The "Trace" function can be used to record changes in values on the target system synchronously in
the context of the task class.
This example shows how another process is started when the state of a particular variable is changed.
The measurement cursor can be used to establish the time difference between the corresponding value
changes of both curves.
By analyzing recordings, processes in the application can be optimized and errors detected.
1 Asynchronous means in this case that the variable values are not transferred to the variable monitor via a
network connection according to a specific schedule.
The Trace dialog box is started for the corresponding task in the software configuration using the
<Open> / <Trace> shortcut menu.
A new Trace configuration must be inserted in the Trace dialog box by clicking the "Insert Trace Con-
figuration" pushbutton.
The variables to be recorded are added to this Trace configuration by clicking the "Insert New Variable"
pushbutton.
Values are recorded cyclically in the context of the task class. The period and start condition of the
recording can be configured in the Trace configuration's properties.
In this example, the recording starts when the coffee machine is switched on
(gMainLogic.cmd.switchOnOff = 1).
2nd Trace configuration: Configure the recording buffer and trigger condition
Open the properties dialog box for the Trace configuration.
The dialog box for selecting the variables for the trigger condition is opened by pressing the
<Spacebar>.
Once the recording itself has been configured, it will be transferred to the target system by clicking the
"Install" pushbutton.
In this case, recording does not take place manually with the "Start" icon on the toolbar, but rather when
the start condition has been met.
If the Watch window configuration for the task in was saved, it will be reopened automatically.
Monitoring and modifying variables gespeichert, wird diese automatisch wieder geffnet.
Recording can be paused at any time by clicking the "Stop" icon in the toolbar. The results are displayed
by clicking the "Show target data" icon after the upload has taken place.
Data is recorded when the start condition has been met. Values can be modified as needed in
the variable monitor. After the data has been uploaded from the target system, the recording
will look something like this (depending on how the values of the variables have been changed):
Changes in value over time can be analyzed using the measurement cursor, which is the same for all
variables on the time axis.
The "Force" option makes it possible to assign any of the I/O data points regardless of their actual
physical value a value for that channel, e.g. in order to test the program sequence. The "Force" function
is enabled in the I/O allocation and in the variable monitor that is linked to the I/O data points.
Figure 34: I/O configuration in monitor mode; forcing I/O channels in the I/O configuration and in the variable monitor
When commissioning of the system is completed, it must be ensured that there are no force
operations still in effect. This can be done automatically by restarting the system or using the
<Online> / <Force> / <Global force off> menu item.
Diagnostics and service \ Diagnostic tools \ Monitors \ Mapping I/O channels in monitor mode
Diagnostics and service \ Diagnostic tools \ Force
Diagnostics and service \ I/O and network diagnostics
There are several different diagnostic tools available in Automation Studio that provide support when
designing the application software.
Not only that, there are ways to detect application/software errors in both Automation Runtime as well
as the actual source code.
The descriptions and images in this chapter refer to the X20 CPU-
based project designed in both training manual TM210 (Working with
Automation Studio) as well as TM213 (Automation Runtime).
Executable project on the controller
Online connection between Automation Studio and the
controller Figure 35: X20 CPU
If an error occurs (e.g. cycle time violation), the log can be loaded from the target system at any time
and analyzed in Automation Studio.
When recording, it is recommended to log all of the events under the "Events" tab. This makes
filtering possible later if there is an error or the Profiler data is passed on to someone else.
A change in the Profiler configuration is transferred to the target system by clicking the "Install" icon
in the toolbar.
Profiler data can be uploaded from the target system to the Automation Studio Profiler in order to perform
runtime analysis of cyclical programs.
Exercise: Cause a cycle time violation and evaluate the Profiler data
A cycle time violation can occur by increasing the value of the "udEndValue" variable in the "Loop" task.
After restarting the target system in service mode, open the Profiler and load the Profiler data from the
target system.
1) Cause a cycle time violation by setting the "udEndValue" variable to the value 500000 in the vari-
able monitor
2) After restarting into service mode, open the Profiler in the software configuration by selecting the
<Open> / <Profiler> menu item.
If the configured cycle time + tolerance was exceeded during runtime, Automation Runtime
triggers an exception. If the application program is not configured to handle this exception, the
target system will restart in service mode.
The "Zoom" button in the toolbar can be used to set the range or area for the Profiler data to
be viewed. When analyzing the data, it is recommended to start at 100%. This can be done
simply by pressing the <ESC> key.
The Project Explorer can be hidden in order to get as much on the screen as possible.
Diagnostics and service \ Diagnostic tools \ Profiler \ Recording Profiler data \ Analyzing Profiler
data
At a certain point in time (e.g. when too many loop cycles have occurred), the time it takes to
complete the task exceeds the configured cycle time and tolerance. This event (exception) is
indicated by an appropriate icon.
To analyze the cause, the data that comes before this point in time must be observed.
Using the measurement cursor and zooming in as necessary on the Profiler data are two ways that the
data can be analyzed.
This image shows how a simple application is recorded in the Profiler. The cause of a problem is generally
harder to detect in real applications since there are usually several tasks / task classes running.
Example:
Two tasks are running in Task Class #1 that usually finish executing within the configured task class cycle.
If it takes longer to complete the first task (beyond n+30 ms in the diagram) and the completion time for
both tasks together exceeds the configured cycle time plus tolerance, then it will be the second task that
is entered as the cause of the error although it is not really the reason for the cycle time violation.
The sequence of events can be analyzed chronologically by evaluating the raw data ("Output data"
icon in the toolbar).
This list shows the the start and finish entries for the "Loop" task. If the chronological sequence were to
be traced further, you would see that although the task itself has been started, it has not ended.
Diagnostics and service \ Diagnostic tools \ Profiler \ Recording Profiler data \ Analyzing Profiler
data \ Analyzing Profiler data in table form
When it comes to software, statistics have shown that there are usually around two to three errors
contained in every 1,000 lines of code.
Automation Studio provides extensive diagnostic tools for locating the source of program errors.
Watch window
The Watch window is shown next to the source code when monitor
mode is enabled. It is also possible to open the Watch window from a
task's shortcut menu in the software configuration or from the online
software comparison.
5.2.2 Powerflow
The path of a signal can be displayed in visual programming languages such as Ladder Diagram.
This signal path is enabled by selecting the "Powerflow" icon in the toolbar.
Once the contact condition for the "Switch" variable has been met, the signal is then shown
for the "Lamp" variable.
Diagnostics and Service \ Diagnostic tools \ Monitors \ Programming languages in monitor mode
\ Powerflow
If line coverage is enabled for textual programming languages, the marker indicates the lines of code
that are currently being executed.
This makes it possible to see exactly which lines are being run at
which time. Line coverage is enabled via the "Line Coverage" icon
in the toolbar.
Diagnostics and service \ Diagnostics tool \ Monitors \ Programming languages in monitor mode
\ Line coverage
The IEC Check library contains functions for checking division operations, range violations, proper array
access as well as reading from or writing to memory locations.
The corresponding checking function is called by the program (supported IEC 61131-3 languages or
Automation Basic) before each of these operations is carried out.
With the IEC Check library, the user can can use a dynamic variable (REFERENCE TO) to determine
what should happen when divided by zero, out of range errors or illegal memory access occurs.
The debugger is an important tool for programmers that makes it easier to find errors in program or
library source code.
PROGRAM _CYCLIC
FOR index := 0 TO 10 DO
Program code AlarmBuffer[index] := 10;
END_FOR
END_PROGRAM
Table 4: Faulty program subroutine
Error description: The limits of the array are exceeded (0-10) since the array only contains 10 elements
(0-9). This type of error is often difficult to detect at first glance and causes the program to overwrite the
next variable memory location.
When the program is started, the value 10 is written to each of the ten elements of the array;
the program seems to be working.
The information in the debugger as well as the variables (and their values) in the variable monitor will
be used to try to analyze the error situation.
The left side of the window shows the program code, whereas the variable monitor is shown
on the right side.
Setting breakpoints
Move the cursor to the first line in the FOR loop.
Set a breakpoint using the <Debug> / <Toggle Breakpoint> menu item or by pressing the
<F9> key.
Reaching a breakpoint stops the entire application running on the target system.
If the debugger hits a breakpoint, then the active line is indicated by a yellow marker.
If the <F11> key is pressed several times, each iteration of the loop causes the value of an
element of the array to be changed.
Step-by-step execution
Continue through each step with <F11> until the new value has been assigned to the last ele-
ment of the array.
In this case, the "index" variable receives the value 9, which also corresponds to the upper limit
of the array ([0..9]).
If continuing step by step with <F11>, the loop will iterate once more with a value outside of
the array.
Any value returned by a function must also be evaluated in the program itself.
If the status of the function (the program code in the orange box) is not evaluated accurately, then the
function itself or the subsequent program might not execute correctly.
The proper usage of variables in the different programs that are in Logical View can be checked by
creating a cross-reference list or explicitly searching for a known variable name.
You can analyze the cross-references for variables and their attributes in the output window.
If a variable is selected on the left side, its usage and the type of access will be displayed in
the source code or in the I/O allocation on the right side.
If you are looking for parts of names, product IDs or comments, you can search for it in the project files.
To search for a variable, use <Edit> / <Find and Replace Find in Files> or press <CTRL> + <Shift>
+ <F>.
A search term is entered into the dialog box, and the results of the search are displayed in the output
window in the "Find in Files" tab.
Double-clicking on a result in the output window opens the respective source file and places the cursor
at the corresponding position.
It is necessary during the configuration, commissioning and testing of the application to prepare the
machine or system for service activities that may occur later.
SDM is automatically activated when creating a new project. The SDM configuration is opened in Phys-
ical View using the <Configuration> option in the controller's shortcut menu.
Figure 65: Opening the configuration, SDM and web server settings
The System Diagnostics Manager requires the web server service, which is also an integral
component of Automation Runtime.
1) Open the AR configuration from the controller's shortcut menu in the Physical View.
The information in the System Diagnostics Manager can be displayed using any web browser.
In order to gain access, the IP address of the target system must be known.
The target system IP address can be checked in the controller's Ethernet configuration. if there
is already an active connection to the controller, SDM can be opened using the <Extras> /
<System Diagnostics Manager> menu option.
Figure 66: Check the network settings in the controller's Ethernet configuration
A plug-in is installed automatically for Internet Explorer (starting with version 7.x) to provide SVG (Scal-
able Vector Graphics) support.
Diagnostics and service \ Diagnostic tools \ System Diagnostics Manager \ FAQ \ SVG plug-in
After pressing <Enter> to complete the URL, the SDM pages are loaded from the target system
and shown in the browser. The left side of the SDM is used for navigation.
Exercise: Save the Logger entries in SDM and evaluate them in Automation Studio.
Situation: The system has booted into service mode for no apparent reason. Unfortunately, Automation
Studio is not available on site. Since the System Diagnostics Manager is enabled on the target system,
it is possible to establish a TCP/IP connection to the controller using a web browser.
Once the SDM is opened, the Logger entries can be displayed from the navigation menu (Logger). Upload
the Logger file "$arlogsys" and open it up with Logger in Automation Studio.
6) Highlight the error entry in the logger and press the <F1> key to receive detailed information
Automation Runtime events are shown in the SDM Logger without additional supplementary
information. This can only be displayed in Automation Studio.
The online data must be deselected in Automation Studio's Logger; otherwise, both the online
entries as well as the entries in the .BR module will be displayed.
The backup battery for the real-time clock and the nonvolatile vari-
ables (retain, permanent) being used in the application can be mon-
itored from the application itself.
Note the replacement of the battery in the service instructions for the machine / system. The
life of the battery is specified in the documentation for the controller being used.
Figure 73: Querying the battery status in the controllers I/O allocation
The Runtime Utility Center program is not just used to copy an executable application to CompactFlash
from Automation Studio.
Runtime Utility Center also includes functions useful for commissioning, maintenance, diagnostics and
servicing.
Runtime Utility Center is started in Automation Studio by selecting <Extras> / <Runtime Utility Center>.
After an Automation Studio project is built, a project list file (.pil) is generated that is displayed
when Runtime Utility Center is opened.
One function of Runtime Utility Center is to load variable values from the controller and to restore them
at a later point in time.
2) Create a new list by selecting <File> / <New> from the main menu
The IP address of the target system needs to be entered in the connection settings.
4) Insert the command for loading the variable list by selecting <Command> / <Process variable
functions> / <Variable list>
Only the variables in the "Loop" task are being backed up in this example. The list can be stored
to any directory.
Diagnostics and service \ Service tools \ Runtime Utility Center \ Operation \ Commands \ List
functions
Diagnostics and service \ Service tools \ Runtime Utility Center \ Operation \ Commands \ Es-
tablish connection, wait for reconnection
Diagnostics and service \ Service tools \ Runtime Utility Center \ Operation \ Menus \ Start
The variable values from the "Loop" task are backed up using the directory and filename spec-
ified.
1) Open Runtime Utility Center in Automation Studio Create a new list by selecting <File> / <New>
from the menu
4) Insert the command for writing the variable list by selecting <Command> / <Process variable
functions> / <Transfer variable list to PLC>
The variable list saved in the last task can be selected in the <Browse> dialog box.
The variable values saved in the file are written to the corresponding variables in the "Loop"
task.
If every variable from every task is backed up and then transferred back to the controller, be
aware that writing to variables sequentially can cause unexpected behavior in the process.
If this situation is still necessary, it is recommended to put the controller in service mode first.
Completed Runtime Utility Center project lists can be passed on as executable applications for servicing
and installing on machines.
The only thing necessary for this is a PC with a physical online connection to the CPU.
An executable image for the project installation has been created without the aid of Automation
Studio.
To pass on the Runtime Utility Center installation to others, the contents of the destination directory
specified during the CD creation process can be burned to CD or copied to a flash drive.
The "Start.bat" file simply needs to be run on the PC at the new system.
Diagnostics and service \ Service tool \ Runtime Utility Center \ Creating a list / data medium
7 SUMMARY
There are several different tools available to localize problems and errors.
They need to be used sensibly in combination with analytical thinking.
To be able to use these diagnostic tools effectively, it is necessary to get an overview of the situation,
clarify the general conditions and examine these conditions from a certain distance.
Only then can the circumstances be cleared up and analyzed in detail. A comprehensive overview of
potential errors can be achieved by excluding and reducing the number of possible error sources, making
it considerably easier to correct any errors that may still occur.
8 APPENDIX
"Loop" program
The "Loop" program involves a program written in the Structured Text programming language. The pro-
gram contains a FOR loop with variable start and end values. By increasing the end value, it is possible
to increase the CPU load and trigger a cycle time violation.
TRAINING MODULES