It takes the same amount of time to respond to a data request message on a Q, QnU, or R series CPU via the MELSEC protocol over TCP/IP regardless of message size. So for an 11 byte response or a 1920 byte response, the time to service that request is the same. KepServerEX’s Mitsubishi driver supports a maximum of 577 bytes for a response, so overall performance is approximately one-fourth of what it could be with the driver optimized for the full 1920 message format. I submitted an enhancement request for this change in February 2016. I have yet to test the Mitsubishi MX-OPC server to see what maximum block size it supports, but I have a feeling it would adhere to the 1920 byte standard as it has been in place for more than a decade. I’m not sure where Kepware got the 577 byte limit. This limitation would not be seen in projects where there are small numbers of tags to be polled, but in larger projects, this limitation would absolutely be noticed. Unfortunately, there is no easy way of migrating OPC tags from KepServerEX to MX-OPC as MX-OPC does not support simple import and export. You have to go through their iQ Works suite and have the tags basically generated from a ladder program developed in GX Works2 or 3 and you have to be using label-based programming to generate OPC tags which our customers do not prefer. I have seen a successful test using a generic client like PuTTY where a Q series was able to return a 1920 byte message, so I know it is possible. The question is will MX-OPC support it? Stay tuned.