1756-ENBT slow socket communication (UDP)

I'm using a 1756-ENBT network card to communicate via socket communication (UDP) with a PC.
Now the signal runtime until the PC sends a bit, the PLC scans and reacts to that bit and sends a bit back to the PC lasts about 500ms.
The PLC scan time is about 20ms. I made a Trend with the incoming and outgoing bit. The reaction time is about the scan time.

Could it be that the data update time (RPI) from the network card is to slow?
Unfortunately I can´t change the RPI time. Even not when I´m offline. The RPI field is still grey and no value is in it.

Any suggestions?

Thank you!

Troubleshooting steps:
Have you used wireshark to determine if the hold up is in the PC or in the PLC?
I think the only thing that would be holding up your PLC is high CPU utilization or high message utilization. Check the processor status for these values. Check all of your message instructions and associated logic to make sure you aren't filling up the communications buffer. I don't recall how to check the message buffer.
Only other thing I can think of would be network lag.
The RPI for a message instruction is how often you trigger the rung from false to true.

The RPI setting for a 1756-ENxT doesn't have anything to do with MSG instructions; Ian is right that your MSG instruction trigger and the processing of the message are the limiting factors.

I agree; get out a protocol analyzer and figure out how fast things are actually happening on the wire.

The 1756-ENBT bridge module does not support open socket interface communications with 3rd party devices. It only supports CIP data packets to 3rd party devices that can decipher and reply using the CIP protocol i.e. EtherNet/IP compatible devices.

The 1756-EWEB has been the long standing supporter of open socket services, but most other 1756 Ethernet modules also support its use...

1756-EN2T
1756-EN2TR
1756-EN2F
1756-EN3TR

...among others.

Request Packet Interval (RPI) values are only relevant for Ethernet modules polling implicit I/O through the I/O Configuration. For open sockets, you are using unconnected UDP messaging.

For unconnected MSG instructions, the timeout is controlled by the .UnconnectedTimeout value. This is part of the message instruction's tag. The default value is 30 seconds. There are also no retry attempts for unconnected messages.

Other factors that can affect messaging throughput are the communications time slice, the execution of periodic tasks, other networking traffic on the backplane, the current CPU utilization on your computer and also its Ethernet loading. Not to mention other possible unknowns such as network switch appliances.

Also, if an Ethernet module is only using unconnected communications then it does not need to be added to the I/O Configuration. In fact, adding it can unnecessarily tie up resources for other more critical tasks under the I/O Configuration.

Regards,
George