We do not limit this on client side. The practical limits will come "from other sides" - wheny ou create too many connections, it will eat memory, it will eat CPU, it may be too many for the target computer, it will become inefficient. It is impossible to give a number or a formula.

Each different remote server will have one connection.

That's kind of obvious in the OPC world: a connection (represented by DCOM OPCServer and the stuff that gets created from it) is a two-ended "pipe" between a client and a server. There cannot be a pipe that connects one client to multiple servers.

Whether a TOP server itself has a limitation, I do not know.

As to the connections on the client side: Each process (app) that uses QuickOPC assemblies (more precisely, each app domain, but usually there is just one app domain in a process), has its own connections.

And, all the EasyDAClient objects in one app domain will normally create just one (shared) connection to any given OPC server - no matter how many of these EasyDAClient objects you use. You can force a creation of separate connections by setting the Isolated property on each such EasyDAClient object to 'true'. Then, separate connections will be created. There is practical hard-coded limit on the number of such connections to be created on our side (QuickOPC), however it is advised that unless there is true reason, you use just one connection, or a handful of them, but not too many.

Best regards

Thank you for update.

- Settings made in one application do not affect other applications.

- Increasing the hold period should not negatively affect the performance of Top Server - in fact, it can be expected that it'll have a positive effect. The reason why the default is relatively short is that some servers need to be disconnected from all clients (and shut down) in order to update their address space, if it's dynamic.

- The connections are per server & per machine. Attempting to use the "subscription hold" technique to a local server will not keep the remote server connected.

- I can only guarantee the "subscription hold" technique with the latest QuickOPC version (5.34). Some older versions have functioned differently in this respect; and, we do not support them.

- If you have purchased a license while 5.3x (e.g. 5.30 or 5.31 etc.) was the current version, then you are automatically licensed to all 5.3x version (including the current version 5.34) and do not have to pay anything.


And, last of all, it should be said that it is still weird why the connection should take so long (longer than the default of 1 minute). Anything described above is basically just a workaround, but does not address this issue. It is, however, likely, that the delay is on the server side.

Best regards

Thank you for the answers. I am sorry - one more question: How is the subscription used? Is it e.g. so that you subscribe t something at the very beginning, and then keep it subscribed for long time, or do the subscriptions also change or go away?

The reason I am asking is because the error you are getting has to do with "initial" connection to the OPC server. But the connection should be kept open as long as there is any subscription in effect. However the matter is a bit more complicated, so I need to gather the facts first.

Anyway, the basic two suggestions to start with are as follows:

1. Increase the "hold period". For individual Reads or Writes, this is the amount of time for which the connection is kept open after the operation. If the problem is in establishing the connection, then having a long hold period would mean that the connection will stay open and will not have to be reestablished again. It can be e.g. a value around half an hour easily, i.e. 30*60*1000 milliseconds. On the EasyDAClient object, it is in HoldPeriods.TopicWrite property.

2. Upgrade to recent version (5.34 as of now).

Best regards