Hello. Obviously I am sorry to hear this news.
As long as Matrikon OPC Rendundancy Broker exposes regular OPC server interface, it is possible to use OPC clients such as QuickOPC to connect to it and work normally. The principle is somewhat similar to OPC Analyzer: It is both client and server piece that sits "in between" - bu t we do not really care on the client side about these things.

Hello, and thanks again for detailed information.
It looks like that the new "Access Denied" problem was introduced in an attempt to remove the need for configuring the DCOM security. I apologize for that. A fix has been made; can you please download the newest build 5.12.523.1 (from the same location as before) and try again.
Unfortunately, as you were not able to use the OPC Analyzer, I cannot tell more to the issue with "InvalidOperationException" during browsing righ now. Maybe if you get the new build working with the Analyzer, and capture the trace, that will tell us more. At the same time, can you please observe closely and determine whether the exception appears

a) When expanding a branch in left tree view (e.g. clicking on "+" mini-icon)
b) When selecting a branch in left tree view (e.g. clicking on a branch name there)
c) When selecting a leaf in the right list view
d) When pressing OK on the dialog.

With regard to OPC UA: OPC UA client cannot natively communicated with OPC "Classic" server such as OPC Data Access. It can be achieved by using a "proxy" which is OPC Data Access client, and at the same time it is a UA server.

Hello,
you can now download a new version of QuickOPC-Classic from our Web page. It is a actually newly released version (5.12), and it contains many improvements (see the What's New document installed with the product), including both changes we have discussed in this thread. Note that if you have already started some coding, you will need to change the assembly references, as the assembly names have changed in this release.
QuickOPC works with Visual C# Express Edition, to the extent and limitations allowed by that edition. For example, the project file format is somewhat different, so the example projects load with some error messages; but they work well. And, this does not happen to your new projects, if you create them from scratch in the Express Edition.
I am surprised by the long time to "get the tag". Can you provide some more details?
QuickOPC-UA is for OPC Unified Architecture. This is a new set of OPC specifications, different from "Classic" OPC, and is based on Web services. I think that neither of your servers supports OPC-UA.

Thanks for the server info. The plan is to use it for a workaround for the "failed server state" issue only. That is, EasyOPC will automatically ignore the failed server state for this particular server. If you keep the setting of ServerStatusCheckPeriod<span style="font-family: "Times New Roman","serif"; font-size: 12pt; mso-fareast-font-family: Calibri; mso-fareast-theme-font: minor-latin; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"> to -1, your code will always work, even if the server's identification change in the future. The idea is that if some other customer happens to use the component with this server, it'll work out of the box. Not everybody is willing to go through pains of technical support as you are. If the server identification changes in the future, it won't work out of the box any longer, but still there will be no harm as compared to today's situation. We can only make some help in this way, because on the technical level, the server appears to be compliant - it just reports that it has failed, but does so in the correct way, so we cannot tell whether it's genuine or not.
<span style="font-family: "Times New Roman","serif"; font-size: 12pt; mso-fareast-font-family: Calibri; mso-fareast-theme-font: minor-latin; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">For the browsing issue, the situation is different, because the server is reporting an error in a call that should not fail. We can therefore detect that there is a compliance problem with the server, and apply the envisioned workaround, without using other knowledge about the server itself. At least that's the plan.
<span style="font-family: "Times New Roman","serif"; font-size: 12pt; mso-fareast-font-family: Calibri; mso-fareast-theme-font: minor-latin; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">As to the "No such interface supported" with your DCS System OPC Server, we can have a look at it as well, if you capture the OPC Analyzer trace again (or if there is a trial version of it available).
<span style="font-family: "Times New Roman","serif"; font-size: 12pt; mso-fareast-font-family: Calibri; mso-fareast-theme-font: minor-latin; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">We think that our stateless API design makes for much simpler code that you - as application developer - have to write. With the stateful design, let's say you would instruct the API to connect to the server. The problem is that not only this creates a state, but that this state is not only controlled by your application, but also by other actors: For example, the server may "die" and you find yourself disconnected. So you have to write a code that detects this and connects again. And you have to write the code that re-establishes subscriptions in such case. And so on. All this complicates the logic, and has to be written in careful and correct way. With the stateless design we have incorporated all that logic into the component itself. For example, if the server "dies", all methods calls related to the server will be returning an error (and subscribed items will receive a special notification), but after a configurable period, the component will reconnect (if possible) and things will start working again (the reason why there is some delay is that otherwise an unwanted load can be created on the system if the reconnecion attempt is immediate). So in case of any failure, you just need to think about what should effects of that failure be onto your system, but you do not have to think (and write code for) at all about how to handle it in relation to the OPC side.
<span style="font-family: "Times New Roman","serif"; font-size: 12pt; mso-fareast-font-family: Calibri; mso-fareast-theme-font: minor-latin; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">As to the "how many tags" question: This depends on the performance of the system, and there are no hard-coded limits, but as a starting point, it is generally possible to subscribe to around 4,000 OPC items, and receive changes from every one of them once per second (measured in a local setup, i.e. OPC server and OPC client on the same computer).

Also, can you please send me the ProgID or the CLSID of the server? Unfortunately this cannot be taken from the analyzer logs. Thank you.

Just quickly going back to an earlier issue: Looking at one of the pictures you have sent, I noticed that even the Prosys OPC client displays the server status as "Failed" - see attached picture with the highlighting. So this is just to nail down the facts (and that I am not making it up...). Fortunately the workaround for this one wasn't so difficult, and I even plan to detect the particular server and handle it automatically.
Untitled.png