Omron trajexia CJ1W-MCH72 Operation Manual page 328

Sysmac cj-series programmable controller
Hide thumbs Also See for trajexia CJ1W-MCH72:
Table of Contents

Advertisement

How-to's
5-1-7-4 Troubleshooting with the oscilloscope
In the example given above, the value of the UNITS parameter is set to
encoder counts. The position of the master axis MPOS AXIS(0) is given in red.
The position increases linearly, because the speed of the master axis is
constant.
The demanded position of the slave axis DPOS AXIS(1) is given in blue. This
graph is a cosine curve. It corresponds to the created CAM table.
The measured speed of the slave axis MSPEED AXIS(1) is given in yellow.
This graph is a sinusoidal curve, because the speed is a derivative of the
position, and the derivative of the cosine is the sine. At high speeds, there are
some ripples.
The green graph is the torque of the motor for the slave axis set with
DRIVE_COMMAND=11 as a percentage of the nominal torque. The torque is
proportional to the acceleration. Because the acceleration is a derivative of the
speed and the speed is sinusoidal curve, the acceleration (and also the
torque) is a cosine curve. There is one peak at the start and another peak at
the stop because there is a discontinuity in the acceleration. There is also a
high frequency oscillation in the torque curve, suggesting a resonance
frequency that can be eliminated using the notch filter settings in the Sigma-II
Servo Driver. The high frequency is reinforced, because it is also reflected in
the speed curve. For more information on notch-filter settings, refer to the
Sigma-II Servo Driver manual.
When the desired data is captured and recorded into the Table memory
entries, you can use the oscilloscope to visualize this data. This can help you
when you commission and troubleshoot the 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 slaves are connected and initialized. For an example of a start-
up program see section 5-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
Section 5-1
317

Hide quick links:

Advertisement

Table of Contents
loading

Table of Contents