TMS320C2000 Motor Control Primer
It is not usually clear how software variables are related to the signal parameters on the diagram, nor where in the
software these parameters can be found and accessed. Moreover, the boundary between software and hardware is
blurred (i.e., where the software controls the on-chip peripheral and where the peripheral output pins control the
external hardware, such as the PWM-to-inverter interface). By adopting a modular strategy and enforcing some clear
definitions, the classic block diagram shown in Figure 2 can be rearranged and redrawn to reveal a great amount of
information about the actual software which is used to implement such a system. This new style of system
representation can be seen in Figure 3. The advantages and features of such a representation will be expanded upon
in later sections, but a summary of key points are given here:
•
The system block diagram has a clear one-to-one mapping to the modular system software.
•
Each module graphic or block represents a self-contained software function or object of the same name.
•
Input and output terminals of each module correspond exactly to global variables within the software function.
•
Modules are categorized (color coded) to clearly designate dependencies on peripherals and target hardware.
•
Connections between modules show data flow via corresponding input/output variables.
•
Each module is reusable and has its own documentation explaining usage and instantiation.
Figure 3. ACI Sensored FOC – System Block Diagram Showing Clear One-to-One Mapping to Software
Reusability, Compatibility, and Expandability
Engineering reuse in today
’
s competitive environment is critical and software modularity is the perfect vehicle to
achieve this, especially in DMC systems. If we examine various motor control systems, it becomes clear that a large
degree of commonality exists between them. The PID regulator, for example, is useful across all systems. Therefore,
if each module is realized only once, but implemented according to well defined guidelines, then compatibility and
predictability can be assured across all modules. Since this approach allows efficient reusability, efforts which may
typically be used to
“
reinvent the wheel
”
can be re-deployed on expanding the module library base for greater
functionality and features.
There are several DMC blocks common for 3-phase motor control in general. On the other hand, in most cases, the
difference between a sensored and sensorless system is only one or two modules, e.g., a position or speed estimator.
The remaining modules are again common. Therefore, in keeping with the reuse philosophy, design efforts can be
focused on expanding the library with more robust estimators which meet various system requirements, rather than
recreating entire system infrastructures.
Target Independent Modules and Drivers
Understanding the exact dependencies of a software module is very important. This knowledge is invaluable during
debugging, software porting from one target to another, and on planning a system commissioning strategy. The
modules which are part of the DMC Library (examples of which are shown in Table 3) are categorized into two main
types: