Examples and tips
PROGRAMMING MANUAL
275
Revi
si
on 3.0
system. This section gives an example of how a bug, which is
difficult to analyze, can be clearly explained and solved using the
captured data and the oscilloscope.
The parameter
end_pos
, which defines the values in the CAM
table, depends on external conditions of the system. Therefore a
program that runs in another task or even a controlling device using
FINS communication, can change it while the main program that
links two axis runs. Suppose that these changes in conditions,
which result in a change of the
end_pos
parameter, happen most
of the time when the axes are not linked, i.e. when the
CAMBOX
command is not executed. Suppose furthermore that very rarely
the condition changes when the axes are linked. The change of the
end_pos
parameter triggers the recalculation of the CAM table
while the
CAMBOX
command is executed. The consequence is
that the part of the demanded position of the slave axis follows the
profile before the change, and the other part follows the profile after
the change. In the end this leads to a discontinuation of the profile,
which causes an indefinite speed of the axis and ends up with this
error: the WDOG goes off, and all axes stop.
The scenario above is hard to analyze when you do not know what
happens. The only thing that the user sees is that the slave axis
has an error once every few hours or even less often. But the
oscilloscope can clearly show where the problem is. In order to be
able to use the oscilloscope, all desired parameters must be
captured at the time of an error. This can be achieved by arranging
the application programs in a certain way. The good programming
practice suggests to have a separate start-up program that is set to
run automatically on power-up of the system and checks the
integrity of the system, whether all the expected devices are
connected and initialized. For an example of a start-up program
see section 6.1.1. It is recommended to let the start-up program,
when it is finished, start only one program that takes care of the
safety and integrity of the application and execution of all other
application programs. This program is usually referred to as a
SHELL program. For more information on designing a SHELL
program, see section 6.2.1.
I52E-EN-03.book Seite 275 Freitag, 29. Juni 2007 11:55 11