Typical structure of a udc task – Rockwell Automation SD3000 Drive Configuration, Programming User Manual

Page 73

Advertising
background image

4.2.1

Typical Structure of a UDC Task

The typical structure of a UDC task is described below. The first part of the task, described in steps 1
to 4 below, is considered task initialization. This part of the task will only run on the initial scan of the
task or on any subsequent restart.

1. Local and common variable definitions

This section of the task defines names for values internal to the task (LOCAL

S

) and all UDC dual

port memory registers used in the task (COMMON

S

).

2. Pm-defined local tunable variable definitions

This section defines the variables that are used by the PMI for functions such as tuning the control

algorithm and calibrating the resolver. The UDC task “skeleton” file in the Programming Executive
software includes these local tunable definitions. See section 4.2.2 and Appendix B for more
information.

3. Initialization

a) UDC Meter Port set-up: The registers whose values will be output on the UDC Meter Ports are

defined here. These registers can also be defined on-line using the Programming Executive
software (optional).

b) Scans per update definition: The scans-per-update register (2001 for both drive A and B) is

defined to tell the UDC Processor when to update the Nth scan registers, and optionally, also
when to interrupt an AutoMax Processor task that has defined a hardware EVENT tied to the

UDC’s interrupt register. The AutoMax task can then read from and write to the UDC dual port

memory registers on a deterministic basis, and coordinate with the other tasks in the system

(optional).

c) Any other initialization required for the application.

This portion of the task (steps 1-3), before the SCAN-LOOP block, only executes the first time that
the task is scanned, after a STOP ALL command and subsequent Run command, or after power
is cycled to the rack.

4. SCAN-LOOP block/Enabling CCLK

This control block tells the UDC operating system how often to execute the task based on the
constant clock (CCLK) signal on the rack backplane. Note that the CCLK signal must be enabled
by a task in the rack before any UDC tasks in the rack can be scanned beyond their SCAN-LOOP
blocks. Note that CCLK must be enabled again after a STOP ALL in the rack. CCLK is enabled by
setting the appropriate “CCLK enable” bit on certain modules in the rack, such as the UDC
module. CCLK must be enabled on one module only. If CCLK is enabled on multiple modules in
the rack, an overlap error will result (error code 38).

The UDC task runs based on “ticks;” one tick is equal to one 500

(.5 msec) CCLK interval.

The value can range from 1 to 20 ticks.

The programmer must specify how often the task should run in the TICKS parameter of the
SCAN-LOOP block in the task itself. The TICKS value represents the number of 500

intervals

within which the task must execute or an overlap error will occur. In order to calculate this value,
both drive A and drive B tasks must be considered together because they execute one
immediately following the other (A, then B). See figure 4.1 for more information.

When determining the value to enter, the programmer must consider how long it will take both
tasks to actually run, allow some time for processing overhead, and use the resulting value to
determine the TICKS value for the SCAN-LOOP block in both the drive A and drive B tasks. The
AutoMax Control Block Language manual (J-3676) lists the execution times of the Control Blocks.

For example, if the programmer assigns UDC task A a TICKS parameter of 8 (4 ms.), then UDC

task B must also have TICKS defined at 8, and both tasks must be able to execute within an 8 tick
window of time, or an overlap error will result and all tasks in the rack will stop. If the tick rates do

not match, error code “956” will be reported for one or both tasks in the error log and all tasks in

the rack will be stopped.

4-3

Advertising