If the GUI calls synchronous operations on EasyXXClient like ReadXXXX, it would freeze until they are completed. OPC is connection oriented, but we provide a connection-less API on top of our component. If connecting other client make things better, it may mean that the long completion times are caused by us connecting to the server/server start up/one-time tasks that the server needs to perform a read.
We disconnect from a server, if it is not in use, automatically, after a configurable "hold period", which is relatively short (I think that it is 10 or 15 seconds). If your application is accessing the server more often than this, the server will stay connected. If it accesses the server less frequently, we will repeatedly disconnect and then connect again, possibly causing an extra delay. To prevent this, set the values under HoldPeriods property correspondingly. (Note: The Timeouts have no influence on this, unless some operation actually does time out, which does not seem to be the case).
Another factor here is that (Again, depending on the configuration) we set up an OPC subscription after a Read, and try to maintain it at a rate that is derived from the frequency your applications calls the Reads. This way, we can (sometimes) give you a value "from memory", instead of actually accessing the server inside the Read. The initial subscription rate after the Read is configured inside the UpdateRates (or it can be disabled altogether), and the maximum allowed age of the value that you can get "from memory" during the Read is contained in the read parameters which are also configurable.
Best regards
