closed – loop speed control of a brushless dc motor via ethernet

Upload: tien-dung-tran

Post on 01-Mar-2016

6 views

Category:

Documents


0 download

DESCRIPTION

Closed – Loop Speed Control of a Brushless DC Motor via Ethernet

TRANSCRIPT

  • Closed loop Speed Control of a Brushless DC Motor via Ethernet

    L. Samaranayake1, S. Alahakoon2 1Ph.D Student Royal Institute of Technology, Stockholm,Sweden

    2Senior Lecturer, Faculty of Engineering, University of Peradeniya, Sri Lanka

    ABSTRACT Ethernet is nowadays being focused by various automation system developers over other field bus systems due to its cheap hardware availability, straightforward integration to the Internet and support for the higher bandwidth requirements in the future. It is already being used at higher levels of plant automation. However, on a lower level of the control hierarchy, it is yet to be investigated. This paper describes the theoretical background and implementation of a Real-Time speed control scheme for a Brushless DC (BLDC) motor set-up, closed via an Ethernet network and investigates the Hard Real-Time capability of Ethernet within the scope of TCP/IP. 1.0 INTRODUCTION In a distributed system, the control loop formed by the sensor, controller and actuator of the controlled process is closed via a communication network. PROFIBUS, INTERBUS, and CAN (Control Area Network) are such commercially available dedicated Fieldbus systems. They are commonly in need of dedicated hardware resulting inherited incompatibility among different bus systems and high capital cost. Ethernet on the other hand, is rich in this context, if it could be used effectively as a field bus system to control Hard Real-Time applications within the scope of TCP/IP (Transport Control Protocol / Internet Protocol). There exist a lot of cheap hardware (i.e., single chip solutions) that integrate Ethernet and TCP/IP stack. Also the integration with Internet is straightforward. With the presence of TCP, it is possible to use all the conventional protocols such as FTP, HTTP, SMTP etc. Ethernet already supports future requirements in bandwidth. As everybody is using the same protocol set, the solution is universal and thus compatibility issues are solved. Vendors will only have to support a single solution instead of multiple field buses. On the other hand the capacity of existing field busses is reaching its limits [1]. Hence even at higher bit rates, it is unlikely that dedicated Fieldbuses would fulfill the future needs of bandwidth. On top of all the above, the market is asking for Ethernet [1].

    This paper addresses the theoretical aspects and practical possibilities to use Ethernet as the communication network to control a Brushless DC (BLDC) motor. The paper is organized as follows. Section 2.0 describes the timing aspects of Ethernet. In section 3.0, Inverter fed operation of the BLDC motor is described.

    In section 4.0, the test rig implementation is described. Obtaining a control system model of the partial system is described in section 5.0. Finally results and conclusion are presented in sections 6.0 and 7.0.

    2.0 TIMING ASPECTS OF ETHERNET Ethernet is a shared-media broadcast technology. Its media access control method CSMA/CD (Carrier Sense Multiple Access with Collision Detection) performs three functions [2]:

    1. transmitting and receiving data packets 2. decoding data packets and checking them for

    valid addresses before passing them to the upper layers of the OSI model

    3. detecting errors within data packets or on the network

    In CSMA/CD, networking devices with data to transmit over the network work in a listen-before-transmit mode. The device must check whether there are any signals on the networking media, before transmission. As soon as the networking media is vacant, it begins transmission. While transmitting, the device listens to the network to ensure that no other stations are transmitting simultaneously. At the end of data transmission, the device returns to listening mode. Networking devices detect a collision by the increased signal amplitude on the networking media. At a collision, each device involved will continue to transmit data for a short time. This is done to ensure that all devices see the collision. Once all devices on the network have seen that a collision has occurred, each device invokes a back off algorithm. This makes all devices on the network to stop transmitting for a maximum duration of twice the slot time, at first. Slot time is the length of time that one transmitting station waits before attempting to retransmit, following a collision. On a 10Mbps network, maximum possible back off time comes to 51.2s and for 100Mbps fast Ethernet, it is 5.12s. The back off time doubles every time the nodes repeat to collide. The doubling stops at the 10th attempt (after 1024 slot times) and declares an error after 16 attempts. Also the devices that were involved in the collision do not have priority to transmit data.

    Hence it is clear that Media Access Control (MAC) makes Ethernet in - deterministic. This makes one to think further about Hard Real-Time capabilities of Ethernet. The theoretical analysis in [3] shows that Ethernet with CSMA/CD can be used reliably for time

  • critical Hard Real-Time applications. The analysis assumes

    1. An isolated subnet within the same broadcast

    domain 2. Light network traffic load. 3. Packets are small and of equal size

    The "error" is defined as an event in which there are enough delays through repeated back-off s to cause the time to begin transmission of a packet to exceed the maximum acceptable delay ( Tmax ) in ms.

    If packets arrive the network randomly from a large number of nodes within the subnet, then the probability distribution of their arrival could be described by Poisson distribution as

    ( ) )(0 !

    xkuk k

    kffexx

    F =

    = (1)

    wBpS

    f8

    = (2) where

    Sp Size of packets (bytes) Rate of arrival of packets (packets/sec) Bw Net bandwidth (bits/sec) u Unit step function f Fraction of utilized net bandwidth Fx Probability distribution of packet arrival to

    media

    The probability of having three nodes trying to transmit at the same time (one active and two waiting) is simply one minus the probability that none, one, or two packets arrive. Therefore the probability of waiting can be given by,

    ( )21 xFwaitP = (3) ( )

    ++=

    !2

    212

    fffexF (4)

    Thus, it is expected at least two nodes waiting for a fraction Pwait s of time. On a lightly loaded network, the probability of more than two nodes waiting is negligible compared to Pwait. Then it is conservative to assume that the two waiting nodes will experience a collision with equal probability. From this point on, the contending packets will follow the CSMA/CD rules. First each of them choose a number from the set {0, 1, 2}. If they choose the same number i.e. a collision, then they choose a number from {0, 1, 2, 3, 4}, and so on. This will continue until an error event occurs when the total back off time exceeds Tmax. Probability that the nodes choose the same number out of the three at the first instance is 1/3. At the second instance, it is 1/5, and so on. The probability of continuing this N times,

    where N is the number of delay slots required to exceed Tmax, is given by

    = +=N

    n nerrorP

    1 12

    1 (6) where

    N Number of collisions to incur Tmax Perror Probability of error (N collisions to occur)

    Table 1 shows Perror until the error event

    N Maximum Slots

    10Mbps delay (s)

    100Mbps delay(s)

    Perror

    1 2 0.1 0.01 3.3x10-1 2 4 0.2 0.02 6.7 x10-2 3 8 0.4 0.04 7.4 x10-3 4 16 0.8 0.08 4.0 x10-4 5 32 1.6 0.16 1.3 x10-5 6 64 3.2 0.32 2.0 x10-7 7 128 6.4 0.64 1.5 x10-9 8 256 12.8 1.28 6.0 x10-12 9 512 25.6 2.56 1.1 x10-14

    10 1024 51.2 5.12 1.2 x10-17 Table 1

    The probability of one transmission without an error i.e. back off time has not exceeded Tmax is 1-Perror. Thus, the probability of not occurring an error in M transmissions is

    ( MerrorPokP = 1 ) , (7) where

    Pok Probability of no delay greater than Tmax M Number of packets sent before error Solving for M results in ( )

    ( )errorPokPM = 1ln

    ln. (8)

    M could be identified as the number of packets transmitted before exceeding Tmax. This can be converted to a time as

    M

    errorT = , (9) where Terror is the time until error occurs The above theoretical analysis, with the conservative assumptions, results Terror variation as shown in the Table 2.

    Bandwidth (Mbps)

    Packet size

    (bytes)

    Message rate (packets/sec)

    Tmax (ms) Terror

    100 128 1000 0.5 9years

    100 1024 1000 1 2years

    10 64 1000 7 9years

    10 64 1000 2 10hours 10 128 1000 7 1year 10 128 1000 2 1hour

    Table 2

  • As far as Terror is concerned, the theoretical results sound excellent. But it is heavily dependant upon Tmax, which is essentially a function of minimum valid packet size and maximum valid cable length. Therefore prior to recommending Ethernet with CSMA/CD for Hard Real-Time applications, acceptability of the magnitude of Tmax has to be investigated. For applications that demand Tmax less than 1ms, this seems not to be a good solution.

    The application considered here is speed control of a Brush less DC motor, where the rise time of the closed speed control loop is in the range of 10-100ms. The experimental timing aspects have been presented in section 6.1.

    3.0 INVERTER FED OPERATION OF

    BLDC MOTOR Brushless dc motor considered here is basically a surface mounted, non-salient pole, permanent magnet (PM) synchronous machine with trapezoidal flux distribution in the air gap due to concentrated full pitch windings in the stator. This is becoming increasingly attractive in servo and variable speed applications since it can produce a torque speed characteristic similar to that of a Permanent Magnet DC motor while avoiding the problems of failure of brushes and mechanical commutation [4], hence ensuring long term maintenance free operation.

    Figure 1 shows the closed loop speed control system of the BLDC motor fed by an inverter. As in many three phase motor applications, the inverter here too acts like an electronic commutator. It receives PWM switching signals from the drive circuit, based on the converted current and speed feedback signal of the low cost Hall sensors.

    In the torque mode operation, current reference signal Iref is the external input to the closed loop system formed by the decoder, hysteresis comparator and PWM generator. There are three Hall sensors placed on the stator of the BLDC motor that give 1200 phase shifted square waves in phase with respective phase voltages. These waves represent the rotor position. The decoder circuit converts the latter waves into the six-step signals as shown in the Figure 1. These converted signals with appropriate polarities are then used to drive the gates of the MOSFET s (Q1 to Q6 in figure) of the respective phases. The actual phase currents of the motor, track the command currents by hysteresis-band current control. In this motor, at any instant, only two of the phase currents are enabled, one with positive polarity and the other with negative polarity. Hence make the currents of adjacent phases equal in magnitude but opposite in direction. When these currents (equal in magnitude) tend to exceed the hysteresis band, both the respective MOSFET s are

    Figure 1 - Inverter fed operation of BLDC motor

    Figure 2 - BLDC motor speed controller coupled to the current controller via Ethernet network

    turned off at the same instant to initiate current feedback through the free wheeling diodes, i.e., D1 to D6 in Figure 1. The outer speed controller can be closed externally or internally within the servo amplifier before coupling to the inner current controller as shown in Figure 1. Here the speed control loop is closed externally via an Ethernet network as shown in Figure 2.

    4.0 TEST RIG

    Figure 3 - Test Rig

  • In the test rig, decoder circuit, current control loop and the MOSFET driven inverters are present within the local servo amplifier for the BLDC motor. Rotor speed is calculated by means of frequency to voltage converting and differentiating the hall sensor position signals. The speed controller denoted by G in Figure 2, which is closed externally, is implemented in software within the network connected control computer.

    The rotor speed signal r is the main incoming data signal while reference current signal Iref is the main out going signal from the speed controller to the servo amplifier via the network. In addition, synchronizing and acknowledgement signals of connection oriented TCP, are present back and forth. In order to monitor the traffic in the Ethernet local area network, another monitoring computer with the software Ethereal, is connected to the local area same network. Since this does not generate any network traffic but just monitors what is available on the wire, traffic monitoring does not disturb the system at all

    In order to realize the assumptions on the network stated in section II, the following steps were taken on the test rig.

    1. Only the Control Computer and Micro-

    Controller were networked using a Switch or a Hub to create an isolated subnet within the same broadcast and collision domains.

    2. As there is no external communication traffic, the light load assumption is also satisfied.

    3. Frames were of 64 bytes equal size at 10Mbps bandwidth.

    A constant load torque is applied on the motor shaft by means of a shaft coupled identical motor. When the reference speed is set remotely at the control computer, the speed signal of the motor is read through the network for the first time. Then the corresponding control signal is calculated at the control computer and is sent back to the motor. Hence the speed control loop is closed via the isolated Ethernet network and the procedure repeats. Control computer is programmed using Borland C++ Version 5.02 and the Z-World BL2100 Micro-Controller is programmed using Dynamic C Premier 7.02. Both uses standard socket programming in connection oriented TCP. The physical arrangement of the entire test rig comprising the Z-World BL2100 Micro-Controller, back to back connected BALDOR BLDC motor unit with servo amplifier, control computer and the 10/100 Mbps Fast Ethernet Switch is shown in Figure 3.

    5.0 CONTROL SYSTEM MODEL It is important to have a linear model of the system in order to design a suitable speed controller for the network controlled operation of the BLDC motor. With inherent indeterminism, the Ethernet network plays the most prominent role, which may add delays to

    the measured speed information and computed control signal output. These delays are of stochastic nature. This critical environment demands exact representation of all the components in the open loop system, namely the Ethernet network from sensor to controller and controller to actuator and the rest of the system, which we call the plant. The plant comprises a Brushless DC motor, an inverter, a gate drive circuit, current controller in the servo amplifier and a Micro - Controller to interface the servo to the network.

    There are two possibilities in modeling such a system. One way is to model each component individually and cascade them to obtain the complete plant. The other method, which is less prone to accumulate model errors, is to model the entire system as a single module. This can be done by observing the response of the overall open loop system to a known input signal and assuming a suitable order to the system. The advantage here is the possibility of obtaining a simple model, which depends only on the dominant modes of the overall system. One disadvantage is the possibility of some non-linear behaviors contained in the system affecting the linear input output relationship. However, since the requirement here is to come up with a simple linear model of the open loop process, the second method is used and is described below.

    As the goal of this work is to build a linear control system model, it has to be ensured the motor operates in the linear region of its performance range. As pointed in [5], the linear operation of a BLDC motor is badly affected by its inherent cogging torque specially at low speeds. In order to identify the linear operating region in practice, first a slow sinusoidal input of typically 1.0Hz frequency and reasonable amplitude is applied to Iref in Figure 4. The corresponding speed response plotted against Iref gives the threshold Iref as shown in the Figure 5, which is approximately 1.1V. By gradually increasing the amplitude of Iref, the saturation limits of the partial system also can similarly be identified. Next a constant voltage greater than the threshold is applied to Iref and the motor speed is allowed to reach steady state after which, a step is superimposed whose upper bound is below the saturation limit. The corresponding speed response is assumed to be the output in the correct linear operating region of the BLDC motor This speed response is approximated using curve-fit functions of MATLABTM programming language to derive the transfer function of the entire open loop system except the micro-controller.

    Figure 4 - Block diagram of the plant to be modeled.

  • Figure 5 - Speed response for a sinusoidal Iref

    The constant voltage on Iref is 1.5V and the step is 0.6V. As the response resembles to be that of first order the following function format proved to be successful in fitting the speed response data to the curve,

    ( ) [ ]ateKKty += 121 . (10)

    The corresponding transfer function in s domain is in the format,

    ( )asksH +=)( . (11)

    Here, the steady state gain k/a can be found from speed response and Iref data. Results are shown in section 6.2.

    6.0 RESULTS 6.1 Timing aspects of Ethernet Packet transport times of connection establishment, data transfer and connection termination phases of Transport Control Protocol (TCP) may vary from frame to frame. Therefore, frame to frame delay profiles were taken for Micro-Controller to Control Computer and vice versa. i.e., sensor to controller and controller to actuator.

    In Figures 6 to 9, TCP sessions are denoted by the connection number, while the first and the last three on the frame axis represent the delays of three-way hand shaking of connection establishment and connection termination phases of the TCP session. The intermediate frames represent data transfer phase.

    In Figure 6, delay increases with increased network congestion. Due to absence of virtual circuits as in the case of Switch configuration in Figure 6, connection establishment and connection termination phases in Figure 7 takes longer time. Since communication takes place within the same collision domain, delay in the data transfer phase in the hub configuration is shorter than that of the Switch configuration.

    In Figures 8 and 9, controller to actuator needs more frames in data transfer phase than in sensor to controller data transfer. In Figure 9, the delay in data transfer phase increases in later TCP sessions degrading the performance due to missing samples. Figures 10 shows the total frame delays for sensor to controller, per session with both Switch and Hub configurations. It is below 10ms for the first few sessions as per the theoretical values given in Table 2.

    Figure 6 - Sensor to controller delay with Switch

    Figure 7 - Sensor to controller delay with Hub

    Figure 8 - Controller to actuator delay with Switch

  • Figure 9 - Controller to actuator delay with Hub

    Figure 10 - Sensor to controller total frame delay

    Figure 11 - Controller to actuator total frame delay

    But in later sessions as the network congestion increases, it exceeds even 30ms degrading the closed loop operation considerably due to missing samples. Figure 11 shows total frame delays from controller to actuator. They are well within the range of theoretical values except for one session with the hub. Response of rotor speed r to reference current signal Iref with both Switch and Hub configurations are compared with non-networked configuration, where the speed controller directly coupled to the current controller.

    Figure 12 - Comparison of Switched networked and

    non networked configurations

    Results of the Switch connected configuration are shown in Figure 12, where the current reference and the speed response are delayed approximately seven and four times respectively compared to non-networked configuration. Similarly, in the Hub connected configuration, current reference and speed response are delayed approximately eight and four times respectively and is shown in the Figure 13.

    Figure 13 - Comparison of Hub networked and nonnetworked configurations

    6.2 Control system model The resulting parameter values of the control system model identification are shown in Table 3.

    Parameter Value

    K1 0.2229 K2 0.6180 a 3.4272 k 0.3870

    Table 3 To evaluate the success of the curve fit, the two open loop speed responses from the motor and the modeled transfer function is compared as shown in Figure 14.

  • Figure 14 - Open loop speed response

    Figure 15 - Close loop speed response with P controller

    Figure 16 - Close loop speed response with PI

    controller

    Inserting the first order model and replacing other major components such as analog to digital converter, saturation limiter, digital to analog converter, etc., of the micro-controller with the standard models found in the MATLABTM - SIMULINKTM library, resulted in closed loop performance shown in Figure 15 and 16. A simple proportional (P) controller is used for the speed controller in Figure 15,while a simple proportional integral (PI) controller is used in Figure 16.

    7.0 CONCLUSION AND FUTURE WORK Delays in connection establishment and connection termination phases of TCP sessions are constants and the values depend on the configuration and the direction of traffic flow.

    Observed Controller to Actuator delays agree with the theoretical delay values derived in the Section 2.0. But the Sensor to Controller delay values deviate considerably, missing a continuous set of samples, resulting poor performance in the network connected operation in both configurations.

    The solution to this problem can follow two different approaches. One software engineering approach is to modify the TCP/IP stack of Ethernet to make it deterministic, so that it can handle Hard Real-Time applications.

    The other remedy, from control engineering perspective is to make the speed controller robust enough to handle the Hard Real-Time system by means of predicting the corrupted i.e., missing or delayed control signals and speed data signals in the actuator and controller respectively. In deriving the complete open loop system model that comprises the networking part and the open loop process i.e., plant, one can follow two approaches. One is to assume the network delays to be constant and is a certain integer multiple of the sampling period. Then the derived first order model can be used for any design with the network delays augmented to it. This approach is taken first and its effectiveness and limitations will be investigated. The other approach is to go for stochastic modeling of the complete system This will also be done later in this research project. 8.0 ACKNOWLEDGEMENTS Authors greatly acknowledge the financial support granted to the date, by the Swedish International Development Corporation Agency (SIDA) for conducting this research 9.0 REFERENCES

    1. J. D Decotignie., A Perspective On Ethernet TCP/IP as a Fieldbus, Proceedings Fet2001, Nancy, France, 2001, pp.138-142.

    2. R. Perlman, Interconnections Bridges,

    Routers, Switches and Internetworking Protocols, 2nded., vol.1.Addison Wisley, 2000, pp 1 40.

    3. S. Schneider., Gerardo Pardo-Castellote.,

    Mark Hamilton., Can Ethernet be Real-Time ?, Real-Time Innovations, Sunnyvale, CA94089.

  • 4. B. K Bose., Modern Power Electronics and AC Drives, Prentice Hall, pp 483 492.

    5. S.Bentouati, Z.Q. Zhu, D.Howe., Permanent

    Magnet Brushless DC Motors for Consumer Products , University of Sheffield, U.K.

    6. C.K. Lee, W.H. Pang., A Brushless DC

    Motor Speed Control System Using Fuzzy Rules, Proceedings Power Electronics and Variable-Speed Drives Conference, pp.101-106, October 1994

    7. T. S Low et al., Servo performance of a

    BLDC drive with instantaneous torque control, Proceedings IEEE Control and Drives conference 1990, pp.454-459

    8. Advanced Motion Controls, PWM Servo

    Amplifiers 1999-2000 Catalog and Technical Manual., pp C-11 C-16

    APPENDIX The parameters of the brushless dc motor are Rs = 4.07, Ls = 8.9mH, J = 0.12kgcm2, B = 0.0353Nms-2, r = 2000 rpm.

    Closed loop Speed Control of a Brushless DC MotL. Samaranayake1, S. Alahakoon2ABSTRACT

    APPENDIX