337978-1-4799-2228-4/13/$31.00 ©2013 IEEE

Synchronisation of two DC Servo SRV-02ET motors using xPC Target

Mădălin Mătăsaru

Department of Automatic Control, Electronics and Mechatronics, University of Craiova

200585-Craiova Romania e-mail: madalin@automation.ucv.ro

Abstract - Embedded computing systems have become a pervasive part of daily life, used for tasks ranging from providing entertainment to assisting the functioning of key human organs. As technology scales, designing a dependable embedded system atop a less reliable hardware platform poses great challenges for designers. Cost and energy sensitivity, as well as real-time constraints, make some fault-tolerant techniques unviable for embedded system design. Many techniques to improve reliability can incur performance, energy, or cost penalties.[4-8] Further, some solutions targeted at a specific failure mechanism could negatively affect other mechanisms.[11] In this paper we will try to see how fit is xPC Target as a solution for real time communication on a long term operating schedule by conducting an experiment that involves remotely controlling one DC Servo SRV-02ET motor that models it’s behavior by receiving a acquisition signal from another DC Servo SRV-02ET motor.

Keywords: Xpc Target, Matlab, Real Time solution, DC Servo, Target Control, Distributed Control

I. INTRODUCTION

A real-time computer system is a computer system where the correctness of the system behavior depends not only on the logical results of the computations, but also on the physical time when these results are produced. By system behavior we mean the sequence of outputs in time of a system.[1]

A real-time system changes its state as a function of physical. Based on this a real-time system can be decomposed into a set of subsystems: the controlled object, the real-time computer system and the human operator. A real-time computer system must react to stimuli from the controlled object (or the operator) within time intervals dictated by its environment. The instant at which a result is produced is called a deadline.[2,3,5]

The present paper is trying to find the answer at the question: how fit and reliable is xPC solution as a real time operating environment? In order to find out we set up a network which topology is described in Figure 1.

We also intend on studying the way in which xPC Target sends out a acquisition signal and how fast it is received by another computer running xPC Target as operating system, which will use it as a control signal for a SRV02 Servo Motor produced and offered by Quanser.

II. SETTING UP THE EXPERIMENT As seen in Figure 1, for implementing this application

we need a laptop running Matlab2009 and Visual Studio 2008 and 2 computers running xPC target version 4.2, a router device for configuring the network and the instruments delivered by Quanser to be used in academic purposes. From the laptop that has Matlab together with xPC Target and a compiler(we will use VS 2008) installed, we are going to load a *.m file on a PC, the file being used to dictate the operating mode of the motor.

The PC that has the 2 motors attached uses a acquisition signal that takes the data from the first motor and sends them to the second PC. This one should retrieve the data and depending on a reference value must send a command to control the second motor attached. We will use standard UDP protocol communication in the beginning and if the results won’t meet the expectations we will try other communication protocols and even network topologies.

Fig. 1. The structure of the network used to implement the application

There is only one communication network that connects the host computer to the target one. Same communication interface is used to send commands and also send the modified parameters to the Target PC. xPC Target supports either a RS-232 or a TCP / IP

338

communication protocol. RS-232 protocol uses a null cable modem and a standard PC COM port on both computers host and target.[14] RS-232 protocol helds transfer rates of 115kBaud and offers the advantage of having an easier configuration, without requiring a Ethernet card. TCP\IP communication is faster, offering data transfer speeds of maximum 100 Mbit\sec on any distance. xPC Target includes a RS-232 cable and also a Ethernet PCI card for the target PC.[5,9,11,12]

The layer that stays at the communication basis is an object-oriented command line MATLAB interface, that is used to send commands to the target. The commands could also be included in M type files for batch testing. The command line interface is made of three function groups: application control, parameters tuning and signal (data) acquisition. The user graphic interfaces, built on the command line interface, can be used on the host PC or the target PC, or through a standard internet browser. On the host GUI, xPC target Explorer, allows the configuration, control and monitoring of the target system’s operations, including access to more targets that operate concurrently[11-13].

With the help of the Matlab set of commands we can connect to any of the target PCs(using xpcexplr command) or we can study the evolution of the measurements of used parameters, with the help of Scopes, as it can be seen in Figure 2 and represented by the Target Scope blocks called Target Scope Id:1 �i Target Scope Id:2 that are being added to the loaded model only for this functionality(xpctargetspy command)[18]

Fig. 2. The *.m file that is being loaded on the PC used as acquisition

III. RUNNING THE EXPERIMENT

For running this experiment we have to load the next 2 files: on the PC used as an acquisition signal(the one that has the IP set at 10.1.2.142 in the network created specially for this experiment and described in Figure 1 ) we load the next *.m file that describes the modality in which data is packed when leaving the source PC and the way in which the unpacking is done when it reaches the destination (see Figure 2).

On the second PC, considered as control unit(the one that has the IP set at 10.1.2.141) we load the *.m file that is described in Figure 8. In order to be able to connect the 2 motors and to read and send the position of one as a reference for the other we are going to use a Universal Power Module from Quanser(power amplifier) and all the necessary connections implemented as described in the manual provided by the producer. The UPM source is described in Figure 3 together with the necessary connections.

Fig. 3. Universal Power Module from Quanser

Besides the UPM we also need a data acquisition board with 4 inputs and 4 outputs: Quanser MultiQ PCI/MQ3/Q8 NI-E. The acquisition board MultiQ-PCI is a multifunctional plug and play I/O board, that works on a PCI bus (32 bits, 33 MHz), realised by Quanser Consulting in Canada.

The management of analogical and numerical inputs and outputs, and also of general functions is made under the supervision of the real time software WinCon, developed by the same company, that works with Matlab/Simulink under Windows.

The board can be controlled under Linux also, by using the software package Simulink Real-Time Control, associated to Matlab\Simulink.

Both WinCon and Simulink Real-Time Control provide the necessary drivers required by the board, and Matlab\Simulink plays the role of acquisition software.

The acquisition board MultiQ-PCI includes the next set of functions:

• 16 analog input channels(from which the first 8 of them can be configured single ended), with a 14 bit resolution(16 bit if we include the sign bit also), with possible domain values -5V,÷5V, -10÷10V;

• 4 analog output channels with a 13 bit resolution(14 bit if we include the sign bit also), with possible domain values -10÷10V;

• 48 numeric I/O channels;

• 6 counters that work on 24 bits, grouped in 3 pairs(that also offer the possibility of connecting the board to incremental encoders)

• a watchdog for controlling the PCI bus

339

In Figure 4 the acquisition board MultiQ-PCI is presented, together with the connectors to the terminal board.[9,11-14,19]

Fig. 4. The acquisition board that has 4 inputs and 4 outputs: Quanser MultiQ PCI/MQ3/Q8 NI-E

The necessary cables used to create the connection to the motor, UPM and acquisition board are described in Figure 5.

Fig.5. Connections and cables required for implementing the experiment

Fig. 6. The DC Servo SRV-02ET Motor

The Quanser Motor is described in Figure 6. The detailed description of the motor and the technical specifications can be found at the address specified by the producer.

A high quality DC servo motor is mounted in a solid aluminium frame. The motor drives a built-in Swiss-made 14:1 gearbox whose output drives an external gear. The motor gear drives a gear attached to an independent output shaft that rotates in a precisely machined aluminium ball bearing block. The output shaft is equipped with an encoder. This second gear on the output shaft drives an anti-backlash gear connected to a precision potentiometer. The potentiometer is used to measure the output angle. The external gear ratio can be changed from 1:1 to 5:1 using various gears. Two inertial loads are supplied with the system in order to examine the effect of changing inertia on closed loop performance. In the high gear ratio configuration, rotary motion modules attach to the output shaft using two 8-32 thumbscrews. The square frame allows for installations resulting in rotations about a vertical or a horizontal axis.[16,19]

To connect the SRV-02ET we have a couple of options. As you may see in the Figure 7, you have 5connectors in the rear part of the motor. We can see that we have three kind of sensors: the potentiometer(it can measure in two ways), the encoder (which has this 5 pin Din Connector), and the tachometer (which has the 6 pin Mini Din connector). The other connector that is in the top part of the rear of the motor, is to connect the “To load” cable. When we want to measure the velocity of the system, we use the tachometer and if we want to measure position, the encoder is more accurate than the potentiometer. The tachometer should be connected directly to the Universal Power Module using the Analog Sensors Cable, and the encoder should be connected to the DS1104 Interface Card.[4,5,7-13,19]

The 2 motors that will be connected to the Universal Power Module are represented in Figure by the 2 communication paths that are going in, respectively out(apacking respectively unpacking the data) from the Encoder and from the Analog Output. Data are transmitted from the signal generator under a binary form and must be sent packed to the destination.

Fig. 7. DC Servo SRV-02ET Motor connectors

340

In order to be able to use the 2 Pack\Unpack modules that are present at both source and destination ends, we need to set the inputs and outputs as vectors of 2 elements: each element represents the data type for the input respectively output. At the Unpacking Data end we must declare the length of each element from the vector(see Figure 9).

Fig. 8. The *.m file loaded on the PC used as a control element

Fig. 9. The parameters that should be set for the Unpacking module

The 2 modules from Figure 8: UDP Send Binary �i

UDP Receive Binary are used to send\receive data already packed\unpacked. Because the communication protocol that is used is UDP we can send data packages to all the computers connected in the network by setting the field IP address to a broadcasting value of 255.255.255.255. Because the specially created network for our experiment has only 2 target computers we are going to use the exact Ips of the PCs(see Figure 10)

UDP keeps the datagram limits between sender and receiver. This means that the receiver socket will receive an event OnDataAvailable for each datagram sent and the Receive method will return a complete datagram for each call. In case that the buffer is too small, the datagram will be truncated. In case that the buffer is too big , only one datagram is returned, the available buffer zone is not reached.

UDP is not a connection oriented protocol. This means that a datagram can be sent at any moment, without a prior notice, negociation or preparation. It just sends the datagram and it hopes taht the receiver is capable of handling it.[6]

Fig. 10. The parameters that are required to be set for the UDP Send\Receive Binary blocks

UDP is not a safe protocol. There is absolutely no guarantee that the datagram will be delivered to the destination. The failure rate over the internet is very low and almost zero in a LAN network with the exception when the broadband connection is full.

Losing datagrams or them not reaching the target is not the only possibility, we must also take into consideration the probability of them being delivered in a wrong order. This means that at receiver side it can arrive first a package that was sent later. Also same package can be received multiple times.[17]

Still, UDP has some advantages like speed and the ability to broadcast communication(it sends to all computers in the network in the same time). The main disadvantage is the lack of fiability. To be able to manage the speed of communication and to constantly update the position of the motor we use UDP protocol and we do not wait for the arrival confirmation after every sent datagram.[15]

Once we have the files loaded on the machines running xPc Target we can create 2 scopes on the PC that has the Ip address equal to 10.1.2.142 in order to see at every moment when the motor used as a reference has an activity and to study the way in which the second motor reacts(on the second scope we should get an identical wave signal).

By setting the amplitude of the signal generator to 360 degrees it is very hard to track how the 2 motors react, beacuse of this we are going to set the amplitude to 180 degrees(the motors will execute a rotation of 180 degrees to the right and then a rotation of 180 degrees to the left and then repeat until the program is stopped or it is set to a certain execution time).

What it can be easily noticed is that the CPU of the target PCs must be strong enough, if that is not the case

341

the application is going to crash after a 7-8 minutes running time. After this continous running time period the CPU is not able to run the calculations as fast as needed and xPc Target will throw an exception.

If the experiment is being ran on computers with enough computation capability, it is very easily observed(in case that the calibration of the motors has been correctly made) that in time(the longer the time that passes the more obvious it becomes) a small gap is present, in the way that the second motor receives the command with delays in the range of hundredths of a second, but they can easily grow and reach a second(in approximately 12 minutes of running).

When it comes to network overload the performance of the transmission protocol decreases noticeably. The router used in this experiment offers a bandwidth of 10/100Mbps. This means that if for a 20% network load the performances are good and the loss percentage is somewhere between 0% and 7%, for a network load of over 70% the loss percentage can rise to 78% even 80%. The effect of this package loss is represented by the presence of some delays in sending the command to the second motor and in this way a small gap is being introduced, that exponentially grows, until it reaches values in the range of seconds(hundred of times greater than the small imperceptible delays present at the beginning of communication, when the network has a very low overload)

This issue is very old and present in all networks. It doesn’t matter how large is the bandwidth it will eventually become overloaded if a continous communication task is running and keeps sending\receiving packages.

Congestion control mechanisms used for TCP communication protocol were the subject of many studies, over time, and they led to a great number of improvements in this domain. However, even with these improvements, TCP still has alarming rates of loss, especially when the network becomes congested.

An inherent weakness of active queue management schemes is represented by the fact that the congestion notification does not depend directly on the number of connections multiplexed along a link. To achieve rapid detection in congested networks, congestion notifications have to be sent to enough sources so offered load is sufficiently lowered in order to avoid losses due to buffer overrun. It should also be avoided sending notifications to too many sources so that the connection becomes underused.

Assuming that our link functions at a minimum capacity ie 10Mbps and is divided equally among multiple connections using TCP, when 100 connections sharing the same link, sending congestion notifications reduces the load at 9.95 Mbps. On the other hand (our case), when only two connections are sharing the link, sending congestion notifications reduces the load to 7.5 Mbps. Generally, when we have a bottleneck link that supports N connections, sending a congestion notification reduces the load by a factor of (1-1/2N). With the increase of N, the impact of sending a congestion notification decreases. These calculations are made based on the principle of using an algorithm for active management of the waiting list, but also for congestion avoidance namely RED (random early discard).

In the case of conventional queue elimination algorithms, a router or other network component adds as many packets as possible into the buffer, and simply discards the ones that do not have place to be stored in the buffer.

If the buffers are always full the network becomes congested. Discarding elements from the queue incorrectly distributes buffer space among different connections. Discarding elements from the queue may also lead to global synchronization because all TCP connections "are being remembered" simultaneously, and then they try to restart in the same time. The network firstly becomes underused (when all links are expecting) and then it is flooded at various time intervals (when the connections decide to resume communication simultaneously). RED algorithm addresses all these issues.

Most existing studies conclude that when multiple data streams are involved RED algorithm is useful as aggressively as possible in order to prevent packet loss and to send network congestion notifications on time. From the same various studies it was concluded that adapting RED algorithm parameters can be useful for network performance. If we have multiple streams between the host computer and targets it can be very useful to have such an approach, in the way that a RED algorithm should be used, one that becomes more or less aggressive depending on the size of the queue. If the length of the queue revolves around a minimum value this means that the algorithm is too aggressive. Otherwise, if the queue length revolves around a maximum value it means that the algorithm is not aggressive enough. Algorithm will have to adjust the value for the maximum length of the queue so as to always send congestion notifications.

IV. CONCLUSIONS

The experiment shows even from the beginning that we cannot use more xPC Target flows on any PC configuration. After an intense use of the processor in a short period of time, it will cope and finally it won’t be able to handle calculations.

Ethernet type networks don’t have an actual dynamic but hey can be modelled either in time domain(by modelling induced delays), either through logical systems(in which case the loss of packages in data networks used for control is being modelled)

The study of an Ethernet network’s behaviour used not as a data transmission network, but as a control network, is a relatively new domain. In order to implement an efficient control system, the knowledge of network’s parameters that have an influence over the quality control, like the delay induced by the Ethernet network or the number of lost packages is necessary.

The delays induced by the Ethernet network aren’t of a physical nature(the electrical signals are being transmitted almost instantly), they are a consequence of the communication stack’s software implementation presented in OSI or TCP\IP models. Also, the connection elements used in setting up the network

342

(switches,routers,servers) implements the routing logic for data packages. All these software components need an execution time that cannot be null, meaning that the delays induced in the network are mainly due to software execution from the network.

The package loss is ineherent for an Ethernet network. These packages are represented,when talking about control elements, by measurement signals(from sensors and transmitters) but also by command signals, provided by the controller and sent to the execution elements.

We also proved that even using only 2 target Pcs, as execution time increases, the delays can become pretty large, thing that in an industral environment would lead to unwanted, even catastrophic results. The main cause for this is not represented by xPC Target necessarily. From the studies made until present and from the experiments ran it seems to be an association of causes between the speed and topology of the network and the processing speed of the data by the xPC target blocks and Matlab.

The experiment leads us to the conclusion that from the point of view of using a Ethernet network for control, the time took by signals to travel from source to destination is critical, not necessarily the certainty that they do. The Ethernet network is from this point of view considered inadequate, the main purpose it had to fulfill was sustaining safe transmission of data, not guaranteeing the time in which it will be done.

For remote controlling time is essential, this means we can say that from a theoretical and experimental point of view, Ethernet networks are the most challenging for study and research. The way in which delays induced in the network are correlated with the percent of lost packages due to collisions is not very precisely determined, and highlighting this interdependence requires a great hardware and software effort.

For a didactic purpose xPc Target can be used in order to study different aspects of real time applications but a practical applicability, in an industrial environment, doesn’t really exist.

V. FUTURE DIRECTIONS

A challenge encountered while running the experiment was eliminating the delays induced both by the transmission protocol and environment. Finally, a cause of the occurrence of such delays (to a lesser or greater extent) can be represented even by XPC Target.

In order to try complete elimination of these delays we are going to change all these elements and repeat the experiment until we get a solution closer to the ideal

model, to obtain an answer in a time interval by at least an order of magnitude smaller.

VI. BIBLIOGRAPHY [1] Christian Köhler, – Enhancing Embedded Systems Simulation

Publishing Springer Fachmedien Wiesbaden GmbH 2011, ISBN 978-3-8348-1475-3

[2] Teng, F.C., "Real-time control using Matlab Simulink," Systems, Man, and Cybernetics, 2000 IEEE International Conference on , vol.4, no., pp.2697-270, vol.4, 2000.

[3] Luce, B.; Rahnamai, K., "Controller design for a multi-fan hovering system," Electrical Insulation Conference and Electrical Manufacturing & Coil Winding Conference, 2001. Proceedings , vol., no., pp.311-317, 2001.

[4] Selisteanu D., Ionete C., Petre E., Popescu D., Sendrescu D. – Aplicatii LabVIEW pentru achizitia si generarea datelor, Publishing SITECH, Craiova, 2004, ISBN: 973-657-594-2.

[5] Shiakolas, P.S.; Piyabongkarn, D., "On the development of a real-time digital control system using xPC-Target and a magnetic levitation device," Decision and Control, 2001. Proceedings of the 40th IEEE Conference on , vol.2, no., pp.1348-1353 vol.2, 2001.

[6] Nilsson, H.; “Rapid Prototyping with Matlab/Simulink –A Case Study”; Masters Thesis, Department of Automatic Control, Lund Institute of Technology, Sweden, 2002.

[7] Ionete, C., D. Şendrescu, D. Popescu, D. Danciu - Simulation of Distributed Networked Control of a Rotating Flexible Beam and Inverted Pendulum, 7th International Carpathian Control Conference ICCC’2006, pp. 201-204, May 29-31, 2006, Rožnov pod Radhoštěm, Czech Republic.

[8] Wilamowski B., Irwin D. – Industrial communication systems, Second Edition – Publishing Taylor & Francis Group, 2011, ISBN: ISBN 978-1-4398-0281-6

[9] http://bigfoot.cs.utt.ro/~cami/sptr/caract-str.html [10] Sebestyen G., Informatica industriala, Publishing Albastra, 2006 [11] The Matworks, Matlab 7.7.0 R2008b Help Documentation [12] Mathworks, XPV Target Tutorial, Control System Design, Feb.3,

2004 [13] Introduction to the MATLAB Real-Time Workshop and xPC

Target System [14] Sean Wilkinson, Integrating PID Controllers into Automated

Processes via Ethernet, 2008 [15] Koppetz H. – Real Time Systems Second Edition Design Principles

for Distributed Embedded Aplications – Publishing Springer New York Dordrecht Heidelberg London, 2011, ISBN 978-1-4419-8236-0

[16] Laplante P. – Real Time Systems Design and Analysis – Publishing JOHN WILEY & SONS, INC, 2004, ISBN 0-471-22855-9

[17] Lamie E. L. – Real Time Enbedded Multithreading – Publishing Elsevier Inc, 2009 ISBN: 978-1-85617-631-6

[18] Lee R., – Software Engineering, Artificial Intelligence,Networking and Parallel/Distributed Computing – Publishing Springer-Verlag Berlin Heidelberg 2011 ISBN 978-3-642-22287-0

[19] www.quanser.com