Compensation of Network Delay


Thread Starter

Deepa K.

I want some help regarding my project. It is about controlling an experiment over a Local Area Network. I want to control the speed of a DC
motor. The motor is connected to a computer which is connected to the LAN of the Institute. The objective is to control the speed of the motor from another computer which is located at another building but in the same Institute. The two computers are connected by the LAN of the Institute.

The technique implemented is Client-Server Technology. Socket programming in C is used for the communication. The operating system in the two
computers were chosen as Linux. The remote control over the LAN was successfully implemented. But the performance of the closed loop system became slow due to network delay. The delay is random but can be known in advance. It becomes as high as 1 sec. The controller implemented is PI controller. In the presence of the network, the closed loop system is stable but the performance became sluggish. I want to know whether there is any way to compensate for the network delay. I want the performance of the closed loop system like that of a non-networked system. If anybody has idea about this, I'll be grateful.
Probably the best way that allows the objective (remote motor speed control) is to put the PI loop in the drive - the "closer" the better-
instead of in the server software. If the actual objective is to find a way around the network delay then you might be on new ground (at least, so far as motor speed control is concerned).

The problem is load conditions can change at the motor many times faster than the nominal and worst case transmission delays. The control software can't change drive commands any faster than it finds out about what's happening via motor feedback, and network delays throw in a variable lag monkey wrench. If load changes are cyclic in some manner then I suppose that could be exploited to create a predictive algorithm, but I believe the underlying problem is the delay, and the essentially unpredictable nature
of load variations.


Jayaharan C J

Dear Deepa,

I think the network traffic in your Institute's LAN is affecting the performance of the control system.Try this option out...

Disconnect both the PCs from the LAN and connect them using a "cross-over" (ethernet)cable.Still the client server technology holds good excepting that it is segregated from IIT's LAN.

Then run your application in the PCs and check up the performance...Hope this idea works out..

All the best

Jayaharan C J

How is the motor connected to the computer on LAN?
is it thru some isa/pci card or serial / parallel ports?
You have not mentioned, what have you used to implement the PI(D) Control.
Is is software (using c/c++/LinuxPLC)?
Is it electronic hardware? (a dedicated PID control unit / a PLC with ladder logic)?

In any case, If you are using sotware, C/Ladder, you need to test the perfection of tuning of the PI control, before you think that the problem could be with the network delay.

Desktop OS's are not meant for real time control processing, so it can be the case that your client application may be taking more milisec's than you calculated, or even your server application.
Dedicated LAN's are heavily used for process control, but only for connecting scada, reporting applications etc, actual control is still in the hands of dedicated control units.
So What I want to mention is that even in case of highly available network, you may somtimes face heavy feedback lags because the cilent server application are not on a RT OS.
As an experiment, it is a good project. But you may like to mention in your report that guranteed control is not possible due to a lot of reasons like those mentioned above and also the fact that there is no reundancy implemented in client/server application.
I think network availability is not the only area to be bothered about. :)

Curt Wuollet

Look up the IPv6 working group and enable the QOS provisions built into the Linux network software. Of course if you have legacy servers in the path like SUN and MS that don't support this yet, you're out of luck. In the real world, this would be addressed by using a separate network for control. There is also realtime ethernet for Linux where behaviour is deterministic. I don't know if this will fly on a public network though. If you can, it should let you handle the delay with the classic methods as it would be predictable. You have a better chance with Linux than anything else right now IMHO.


Change the existing LAN to Fast Ethernet network.Also we should be eliminate the delay with 10 MBPS network.If not then use 100 MBPS

It seems to me that you are taking a big risk by not using a realtime operating system, but there is a solution to your problem that you should consider.

Instead of allowing the delay in you control system to be random, revise your control algorithm to contain a fixed delay that is longer than any random delay that the network generates. Your observer should estimate the needed control signals ahead of time by an interval larger than network delays. Your motor
control commands should be in a buffer waiting to be sent to the motor before any network delays can effect their transmission.

I noticed that no other solutions were this technical. Am I being too complex for this forum?


Johan Bengtsson

The problem is that introducing a delay don't help the original problem of the control being to slow. It is not really possible to control anything faster than the scan time of the controller (and the I/O scan is to be included here - of course)

The controller have to be moved to the coputer sitting close to the motor and the network used for passing parameters and similar.

/Johan Bengtsson

Do you need education in the area of automation?
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]