Motor Drive System

8/12/2019 Motor Drive System

1/6

On Applying P arallel Processing to a Versatile Induction M otor Drive SystemPatrick Chi Kwong LukSchool of Electronic and Electrical Engineering,The Robert Gordon University,Schoolhill, Aberdeen AB9 lFR, United Kingdom.

Abstract arallel processing is becoming a key approach torealise cost-effectively the many features found in a modem inductiondrive system comprising advanced real-time control, diagnostics andthe like. The proposed drive system has been implemented by theapplication of medium-to-coarse grain parallel processing, throughexploiting the novel features of the transputer. Salient features of thedrive include real-time generation of pulse-width modulated (FWM)waveforms, program mable soft-starting, on-line user input for PWMparameters, dynamic braking and open loop vector control.Experimental results confirming such features are presented. The lowcost, high flexibility and extendability of the drive system provesuperior to systems developed by conventional methods.Introduction

With the recent advent of microelectronics and power electr onic s, theemph asis on a.c. variable speed drive system design has alreadyshifted from the maturing technology of achieving efficient andreliable power conversion to the challenging discipline of improvingthe dynamic response of the drive. The search for high performanceand versatile electrical drives, impelled in a market-pull, technology-push manner, is therefore becoming more evident in manyengineering applications. It is anticipated, for example, that electricaldrives will be rapidly replacing internal combustion engines in theautomobile industry due to environmental factors in the near future.The inherent advantages of the induction motor in variable speeddrive applications such as electric vehicles (EV) have been identifiedsome time ago by pioneers such as Chan [ l ] and others. Theadvanced control functions required by such systems as EV, whenimplemented digitally, often call for the computational power of amulti-processor system [2]. On the other hand, it has been envisagedthat integrated drive systems which comprise such features assimulation study, real time control, expert system for monitoring anddiagnostics will emerge in the near fu ture. The philosophy behind theintegrated drive appears to be that implementation particulars suchas sampling rate and control algorithms of the controller to the drive,c n be traded off and an optimisation of the entire drive system c nbe established at the design stage.One key approach to realise such versatile drives is by means ofparallel processing. Although parallel processing in induction motordrive systems has been implemented in multi-processor systems, theavailable literature usually considers only the verification aspect ofthe system [2 3]. The implementation complexity in terms ofhardware and software in such systems has seldom been addressed,and little design guidelines are offered. For example, it has beenargued in other applications such as image processing that it isimportant to balance the computational load of each processor inorder to reap the benefits of parallel processing. There appears nosimilar debate among researchers in electric drive application [4]. Itis hoped that this paper will initiate further discussions and motivatemore research activities in parallel processing applications for motordrive systems, and in particular to draw attention to formulatingdesign rules.The illustrative example used in this paper is an induction motordrive system using a multi-transputer network to handle real-timecontrol, signal processing, house keeping and diagnostics functions.0-7803-0891-3/93 03.001993IEEE

In particular, experimental results of vector control and soft-startingare illustrated. For reawns of simplicity in implementation, the motordrive was derated and only light load tests were performed. Thetransputer was used mainly because of its direct relevance to theconcept of parallel processing, particularly when used in conjunctionwith its programming language OCCAM.The paper is organised as follows. The basic theory of parallelprocessing and the notations used are outlined, with particularemphasis on parallelism in drive systems. The method ofimplementation, by means of transputer and OCCAM, is thendiscussed. The implementation of two features of the system, theon-line user-interface and the soft-start process, is illustrated in moredetail. Experimental results are presented, and then followed byconcluding remarks.

Theoretical MethodologyThe basic principle of parallel processing is simple and yet powerful.If a processor can execute 1 million instructions per second, then 100of such processors operating in concert c n execute 100 millioninstructions in a second. It also offers notional elegance since in thereal world processes are predominantly concurrent. However,problems of coordination between processors could pose seriouspenalty in performance and the consequence could become c ounter-productive. T he benefits of parallel processing have been recaptu redby the introduction of the Com mun icating Sequential ProcessesCSP) [ ] where each process uses message passing approach toachieve synchronism. The proposed system is based on CSP nd oneto two comm unications per cycle is assumed.TerminologyRecently, a design methodology which involves the defining ofdifferent templates as building blocks for a generalised parallelsystem has been proposed [6]. An alternative method, which exploitsthe well-entrenched flowchart representation of program flow, isadopted here. This notation has the obvious advantage over theformer in its familiarity to many users Fig.1 summarizes the basicnotations. The rectangular box denotes a sequential process, thearrowed box denotes an output or input communication, and the loopcomposed of arrows represents infinite message circulation. Sinc ethe notation used here is an extension of the conventional flowchart,one can express the program flow in more detail by breaking theprocess into smaller blocks as in a conventional flowchart. Differenttemplates such as manager-worker, worker-assistant and mailbox-receiver [6] c n be constructed accordingly. This flowchart notationc n also serve as a timing diagram. If the timing of individualprocesses is determined, and the simple rule that processes nvolvingcommunication can proceed only Vth e sending end and receiving endare both ready is observed, the program timing c n be calculatedaccordingly.Task level parallelism in drive systemsThe practical implementation of parallel processing usually entailsmapping a problem onto a parallel architecture. The level ofparallelism selected for the task must closely map to that of the targetcomputer system for optimised performance and effective use of

907


2/6

c rocess

lu i t sys tem (power off)

High priorityprocess

(a) Input Process (b) Output Process (c) Multi- input Process (c) Priorised ProcessFig. 1 Basic Notations used in the Flowchart for Program s in Parallel Processing

silicorl. The transputer, armed with on-silicon communications links The transputer and OCCAMand protocols, lends itseli as an ideal processing unit for building up Although i t has beeil argued by many that the transputer is far frommedium-to-coarse grain o r M IMD ( Multi-In struction, Multi-Data) enjoyin g an unrivalled position in parallel processing, it isparallel processor arrays. A typical drive system, shown in Fig. 2, nonetheless the autho rs view that the transputer and its programmingexhibits a task-oriented parallelism, in which each process is language OCCAM remain a very useful tool in illustrating the elegantresponsible for a different task. The tasks are classified according to concept of parallel processing, a nd the relative ease of implementingtheir priority and execution time, and are depicted by different i t in the control of electrical drives. Since the transputer can beshade s. Th e tasks requiring very high speed and high priority consist programmed in OC(IAM with virtually no loss of coding efficiency,mainly of signal processing and conditioning required for the power the hardware -software sem antic gap is narrow ed. This also results inconverter and have been conventionally relegated to h ardware. Tasks a reduction of program development time when compared withof medium speed and priority s.re those of transforma tion of fram e of conventional methocs.reference and vector control algorithm. The low speed and prioritytasks Are those of rotor speed and position measurement and thehandliqg of user input/ouiput where large mechanical time constantsand sli)w response are i n \ olved

low speedlow priorlty medium sp e@medi um prcorlty high speedhigh prioriiy

Fig.2 Task-oriented Pa rallelism in a Typical Vector ControlInduction Motor Dnv e

P r o g r m level purullelisniProgram level parallelism is a lower level parallelism when comparedwith task level parallelism. Procedures or subroutines executing inparallel are examples. The internal hardware timer of the transputerand the OCCAM protocol to access to this Timer allows programlevel parallelism. In the generation of the PWM waveform, the highpriority Timer was used in generating a communication signal atcarrier frequency of the PWM waveforms. The transputerautomatically deschedules thc timer process while waiting for thehardware timer to time out, and reschedules the timer process uponliming out. This feature enables a conceptually novel method ofgenerating PWM waveforms. However, the relatively slowcoinmimication transputer link speed may limit the carrier frequencyto several kHz in practice.

Implementation MethodologyThe drive system pr3posed in this paper was designed to achieve ahigh front-end flexinility by providing an on-line user interactiveenvironment. It was aimed to accommodate a highly comprehensiverange of functions bv means of parallel processing.Speci cations ( f p r o , r systemThe salient feature.; of the proposed system include real-timegeneration of 3-phase PWM waveforms (1Hz to 7SHz), open loopvector control, programmable soft-start procedure, forward andreverse mode of operation, dynamic braking, and speed and currentmeasurement/monitoring. Table andTable2highlight the flexibilityand user-friendlines of the system.

Table 1 : On- line PWM parameters available for user inputPWM Parameters Resolut ion Der Kevs for execut ion

e ri t

Table 2 : On line control parameters available for user input

Vector control (on/of f )Dvnarnic braking

908


3/6

System OverviewFig.3 hows the bloch diagram of the drive system. One main criteriafor the choice of the transputer system was the ease it offered toillustrate and perform parallel processing. The INMOS B008 andBO03 boards were used, which constituted a host transputer mountedinside a personal computer and four external transputers connectedin a network respectively. T he interface consists of the 3-phase timerfor PWM waveform generation, a counter for position and speedmeasurements, and A-to-D converter for current monitoring. Thepower conditioning IS a 3-phase MOSFET inverter with the gatedriver. The transputer defelopment system (TDS) provided a veryuser-friendly environment for programs to be edited, compiled and

Operatio ial taqs full.speed.tagacknowledge.tag

executed.

__

I

meed ref

transputer network

INT.REAL32REAL32

iiiterface power conditioning

machine.data - R 1 R2;L1 :LZ;Lo;LmstartuD.data - f;MO:M;N

Fig.3 Block Diagram of the Drive System

REAL32;REAL32;REAL32;REAL32;REAL32;REAL32REAL32;REAL32;REAL32;lNT

The communicution proti~~:olsSeveral types of data were req uired to be communicated between thetransputers within thch multi-transputer network for the control of theinduction motor drive system. A simple stop the motor commandfrom the host coinpuler to the network, for example, is nothing morethan a tag. Howevei, the m easurement of rotor speed used in vectorcontrol will require floating point data type for the necessaryaccuracy. The operational parameters for the PWM generator that

consist of such parameters as carrier frequency, frequency ratio andmodulation index, are best to be transmitted as a packet of data.Table 3shows the details of the PROTOCOL MOTOR, defined inOCCAM, used in the system. PROTOCOL is a OCCAM commandto construct protocols. It is a variant protocol that specifies a numberof data types including simple tags, INT (integer), REAL32 (32-bitreal number) and a combination of INT and REAL32. ThePROTOCOL MOTOR consists of several groups of message tags andprotocols with specific format for each protocol. For example, in thesecond column of Table 3, the machine.data protocol has a dataformat of six REAL32 numbers in sequence for the resistances andinductances of the machine. Incorrect data format used in theprotocol will result in error message. The tag has no data format.The links connecting the transputers were all assigned with thePROTOCOL MOTOR.Allocating p r o c m e s to proceJsorsThe initial stage of software development of the present system wasreported earlier elsewhere [7].The method of software developmentwas based on the concept of OCCAM model. The logical model ofthe final system was first developed and tested on the host transputer,then different processes were allocated to the processors. Instead ofobserving rigidly to the basic rule of keeping every processor a sbusy as possible, it was found convenient for instance to allocate aprocessor dedicated to low level PWM waveform generations. Fig.4shows the five processes allocated to the five processors linked by thechannels and the corresponding top level view of the OCCAMprograms, or the pwudo-codc of the program. The symbol represents a program(s) folded underneath.Tnt User Interiictiw Process and the Soft-start ProcessThe user interface to the drive system is facilitated by the UserInteractive Process which provides the on-line user inputs and outputsvia the keyboard and monitor of the host personal computer. Theprocess is described i n the flowchart of Fig.5. The PWM waveformwas generated on-line by the asymmetric regular sampling method.The user can input voltage boost and the number of increments to fullspeed prior starting the motor, whereas PWM parameters and othersystem parameters can be changed when the motor is running. Forexample, suppose N is the number of steps required to start thePWM waveform from Hz (note that 0 Hz corresponds to an infinitevalue loaded to the timer) to the reference frequency, ref, MO is therequired voltage boost, and is the required modulation index atreference frequency, then the processor would be required to

Table 3 : PROTOCOL MOTORIIClassification I1 Name of taaslorotocols data format I Data tvDe

change.reference.speed.tagchange.carrier.freq.tagchange. pwm.parameter.tagforward.tagreverse.tag Il r i ]REAL32Control i,rotoc3(s speedmeasure \REAL32positionlabc - 1a:lb:lc 2:REAL32REAL32REAL32:REAL2.II IIvector control.Darameters - Dh1;R.M IINT:INT:REAL32

909


4/6


5/6

set PROTOCOL MOTOR

openOccam user libranes

I declare variable and constank Iset up operating menu I

user inputs: IPerform the selected procedure

Chanae frea DrOces Chanaem wLxQ zssdisplayoperabng InStrucbonS I1 I fonvord Isend finish.tag to TOI set dyamic brake Hag Isend controldata o TOw

display message

wait lor timer setup signal-ig.6 Flowchart for User Interactive Process Providing On- line User Inputs

form sine tableget start -up data from TO

Calculate parameters for softstartprocess from the recievad start-up data high pnorityS f ramp c f ref

processf- I

(iti) Quit systemS < soft.start.time (i) vector control (11)PWM parameten

clock ? time.now

Vector control algrothmI?load1, o register of timer 1 of 8254 Iloadb o register of timer of 8254load 1, to reqister of timer 3 of 8254 I, I

Fig.7 Flowchart for PWM Process with Soft-start

91 1


6/6

Fig.7 Operating Icon of the Drive System

(a) Voltage Boost MO = 0.05 (b) Voltage Boost MO = 0.1Fig.8 Soft-start Process with a Programmable Voltage Boost

2) Vector Control Algorithm Disabled (b) Vector Control Algorithm EnabledFig.9 Dynamic Response for a Step Increase of 240 rpm in Reference Speed

912

Documents

Motor Drive System