TCP Vs. UDP, how can I turbo charge data transfer?

Thread Starter

strantor

Joined Oct 3, 2010
5,508
I am making a 3D machine simulator in Blender (animation/game design suite w/ Python 3 interface) and it needs to communicate with an Omron PLC over Ethernet. I have found Python 2 code online which communicates with Omron PLCs using Omron's own "FINS" protocol. The code is provided in two files; one for TCP and one for UDP. Not knowing the difference between TCP and UDP, I picked TCP because it rings familiar to me. I spent a lot of time converting it over to Python 3, only to find that it is not quite fast enough.

My simulation/"video game" runs @ 24FPS, and I need it to read/write to the PLC each frame, so total communication time needs to be <40mS. Using the TCP Python code, I can read data from the PLC in 60-90mS, and it doesn't matter whether I read 2B or 30kB, same comms time. So after a bit of reading about TCP Vs. UDP I thought using the UDP code would make for faster comms, but that's not so. The UDP code gives me the exact same comms time (EDIT : wrong, actually UDP takes over 1.2sec to read).

What can I do to speed things up? I don't care about data integrity, error checking, or network congestion. I'm cool with blindly sending/receiving and assuming it worked. It just needs to be as fast as conceivably possible on 10/100 ethernet. The network will consist of a PC, PLC, and touchscreen.

EDIT: attached python files if anybody is interested. The two original python 2 files and my converted Python 3 file. rename to .py
 

Attachments

Last edited:

Papabravo

Joined Feb 24, 2006
15,518
UDP or User Datagram Protocol has no method for ensuring the reliable delivery of data. If that is what you want, to spray and pray, then UDP is for you. I agree that ditching Python should speed things up. It is interpreted after all.
 

Brownout

Joined Jan 10, 2012
2,390
Seems odd that UDP would be slower. As mentioned, UDP streams data without mechanisms for data integrity. It should be faster.
 

sconsulting

Joined Feb 8, 2021
1
Seems odd that UDP would be slower. As mentioned, UDP streams data without mechanisms for data integrity. It should be faster.
Indeed, UDP should be faster here, but it will not ensure data integrity since it does not deliver data packets in a sequence, and it is impossible to retransmit them in case of fail, see TCP vs UDP
 

michael8

Joined Jan 11, 2015
134
Which Omron PLC? Model number?

Do you know how fast the PLC is supposed to respond to packets from the ethernet?

Local 10 Mbit ethernet packet times are in the microsecond(s) range, so something is very slow. It could be the PLC or
all the binary<->character conversions or just Python dict lookups on all the symbols in the code.

What is the PLC supposed to be doing (input? output?).

"FINS" protocol https://en.wikipedia.org/wiki/Factory_Interface_Network_Service
www.kepware.com/Support_Center/SupportDocuments/Help/omron_fins_ethernet.pdf

Oh, at a quick glance this seems complex and like something retrofitted to emulate a 9600 baud serial link.

Perhaps the PLC isn't designed to run that fast on the ethernet interface.
 

Thread Starter

strantor

Joined Oct 3, 2010
5,508
Which Omron PLC? Model number?

Do you know how fast the PLC is supposed to respond to packets from the ethernet?

Local 10 Mbit ethernet packet times are in the microsecond(s) range, so something is very slow. It could be the PLC or
all the binary<->character conversions or just Python dict lookups on all the symbols in the code.

What is the PLC supposed to be doing (input? output?).

"FINS" protocol https://en.wikipedia.org/wiki/Factory_Interface_Network_Service
www.kepware.com/Support_Center/SupportDocuments/Help/omron_fins_ethernet.pdf

Oh, at a quick glance this seems complex and like something retrofitted to emulate a 9600 baud serial link.

Perhaps the PLC isn't designed to run that fast on the ethernet interface.
Thread is 6 years old. It was a CJ2M PLC I believe. I did end up getting it to work. I don't remember what the problem or the solution was.
 

vanderghast

Joined Jun 14, 2018
53
UDP is a protocol based on IP which is about broadcasting messages. Like a radio station, it emits, but don't care if the intended listener is present or not. You can instance it by using the "all" network adress, such like 192.168.0.255 meaning every one on 192.168.0.0. The one who emit does not expect to receive 254 acknowledge confirmations of the reception!
TCP is a protocol also based on IP which is more about a one to one message, with confirmation and robustness. As example, if the message is broken in multiple IP packets, and one is not confirmed by the recipient, the emitter would (could) resend it. The TCP-IP suite expose many network functions, from the PING, to TRACERT, as examples.
The IP protocol is about the packets. Among other things, it specifies the packet size. Having a larger packet size implies less overhead, so a possible improvment, but if they are too large, it may become less responsive, having to wait longer to avoid collision of packets send through the local (sub-)network. The IP protocol allows to use multiple port, multiple IP-adresses, on a given workstation (you need more than one physical TCP-IP port though, to be effective). Using a sub-network dedicated to fewer IP users could increase dramatically the overall speed, since the wire will likely be free to send your packets, right "now".
So, basically, try a faster physical casd, a faster HUB (and/or router if communication between sub-networks is required), a dedicated sub-network, "zipping" the data before sending it, reduce (if too many collisions occur) or increase the IP packets size are the standard "first steps" (well, packet size is probably in the fine tuning bag, since you need to analyze what happens on the wire). TCP or UDP is to be selected by the required functionnality, knowing that UDP is not as reliable as TCP, but faster is you have to send "annotations" to MANY users.
 

ApacheKid

Joined Jan 12, 2015
379
I am making a 3D machine simulator in Blender (animation/game design suite w/ Python 3 interface) and it needs to communicate with an Omron PLC over Ethernet. I have found Python 2 code online which communicates with Omron PLCs using Omron's own "FINS" protocol. The code is provided in two files; one for TCP and one for UDP. Not knowing the difference between TCP and UDP, I picked TCP because it rings familiar to me. I spent a lot of time converting it over to Python 3, only to find that it is not quite fast enough.

My simulation/"video game" runs @ 24FPS, and I need it to read/write to the PLC each frame, so total communication time needs to be <40mS. Using the TCP Python code, I can read data from the PLC in 60-90mS, and it doesn't matter whether I read 2B or 30kB, same comms time. So after a bit of reading about TCP Vs. UDP I thought using the UDP code would make for faster comms, but that's not so. The UDP code gives me the exact same comms time (EDIT : wrong, actually UDP takes over 1.2sec to read).

What can I do to speed things up? I don't care about data integrity, error checking, or network congestion. I'm cool with blindly sending/receiving and assuming it worked. It just needs to be as fast as conceivably possible on 10/100 ethernet. The network will consist of a PC, PLC, and touchscreen.

EDIT: attached python files if anybody is interested. The two original python 2 files and my converted Python 3 file. rename to .py
There are many variables to consider with this.

First you need a reliable, objective way to measure the data transfer performance, if you do that informally, crudely you'll have problems, you'll not be able to compare implementations objectively.

Language performance is vital of course, Python is interpreted so I'd be concerned about the choice of Python.

I've designed very high performance server communications for the Windows OS, I've spent lots of hours measuring and profiling and improving performance but on Windows.

Now on Windows the number of IO writes is a big factor in CPU usage, for example doing a small number of writes with very large packets uses much less CPU than a large number of writes with small packets - testing this with say 100 Mbytes of data will reveal this.

So this observation led to the design of a store-and-forward mechanism with an age counter, the app would "send" data but it would be accumulated in a store-and-forward ring buffer then if the buffer became full or the age timer expired, the entire buffer was sent in a single write operation.

I'm only mentioning this to give you some idea about the kinds of things involved, on other machines, MCU boards and so on, I have no idea what kinds of issues play a role, but until you know that you're going to be struggling.
 

Thread Starter

strantor

Joined Oct 3, 2010
5,508
Thread is 6 years old. I did end up getting it to work. I don't remember what the problem or the solution was.
 
Top