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

Thread Starter

strantor

Joined Oct 3, 2010
5,446
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,013
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
119
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,446
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.
 
Top