Have you ever noticed an increasing delay while UDP protocol send/receive packets?

Dear matlab users, I'll be thankful for the answer on the following question. Have you ever noticed an increasing delay while UDP protcol send/receive packets? It seems, that latency is going on and on during the time. I've worked with xPC real-time windows target in simulink in the external mode. I've made a closed-loop system where the embedded system receives assignment via UDP to drive a motor and sends encoder data to simulink. For example, if I send sinusoidal signal to the object with 1 ms and then send it back to the host, I will see an increasing error at the host side if I subtract the received signal from the sent signal. It seems to me that matlab puts received packets in the queue and takes it one by one with 1 ms. The delay is really increase: closed loop system is stable in the beginning of simulation and during the time it is getting more and more unstable. So, maybe there are some method to purge this queue and receive actual data? I'll be thankful for any information Host: PC Windows 7 Remote PC: Arm Cortex M3

[Suneesh]

I would expect delays to occur if you are using the "UDP Send Binary" or "UDP Send Binary" blocks since these are not real time blocks and run in the background. The real time UDP blocks are in the library 'xpcrtudplib'. these do require a separate dedicated Ethernet card and do run in real time. Any kind of increasing time delay for these would cause a target CPU overload. However your description of your setup is extremely confusing:

1. You mention " xPC real-time windows target". There is no such product. It should be EITHER "xPC Target" or "Real-time Windows target"

2. Since you talk about a second machine acting as target I am assuming that you are using xPC Target. Still something sounds off here, xPC is NOT supported on Arm Cortex M3, but only for x86 PC-compatible machines

[Uladzimir]

I agree with you, possibly I missed the teminology, sorry for that. But the situation is the following: the host machine is a target at the same time - self-targeting. Coder generates real-time application for a target - Windows PC. Then I run simulink in the external mode, connect to the target (Windows kernel) and start simulation. May be it's more appropriate termin "Real-time Windows target" not xPC. I use Packet Output and Packet Input blocks from Real-time windows target blockset and configure it as standard UDP protocol. Here is my diagram

Thats the increasing delay, which represented as dynamic error. Embedded system just receives x and sends data x' back, and error is computed as x-x'

And here is the time intervals, with which the embedded system receives packets from the PC with the 10us resolution. That's jumps from 0 to 3 ms, while I sending data with 1 ms. 0 ms is impossible, there must be at least one 10 us interval. So, I suppose, It's nonstability of data logging.

ARM supports UDP protocol and used for motor control and receive/send data over UDP. The PC is included in the control system loop. The main trouble that delay is increasing, and I'm looking for a way to make it as in the beginning of simulation during the whole simulation time. Could you help me, dear Suneesh?

Answer 1

[Suneesh]

From the image of the model, you are using blocks from the product "Real-Time Windows target (RTWT)". I am not too familiar with it and recommend you contact tech support but here are my thoughts:

1. The Real-Time synchronization block is used to synchronize a normal mode simulation to the real time clock. So if you are running in external mode then perhaps this block is not required. Try the experiment without this block.

2. I also feel you should try a loop back test. Get rid of the embedded system from the loop and make the Packet output block send the packets to the Packet Input blocks. If the delay goes away, then the issue is with the embedded system. If the issue remains then perhaps RTWT is behaving differently, in which case please contact tech support.

I will have no further inputs on this.

[Uladzimir]

Thank you, these proposals seems to be interesting, I'll try it. I don't think that the problem with the embedded system, it doesn't do any difficult calculations, just form 400Hz pwm and send/receive data over UDP. It are not too much for 150MHz MCU. But anyway, a chaining of blocks is interesting. Thank you again