I am afraid that what you are up to may not be possible. There are basically following things in play:

- The efficiency of the actual implementation. Assuming that the "slowness" does not come from your own processing of browse results, we are left with the OPC server, the connection in between, and the OPC Client part in QuickOPC. If you cannot influence the speed of the OPC Server or the connection to it, we are left with the QuickOPC. I have no indication that our implementation of browsing is significantly slower than that of other OPC clients, or ineffective in a particular way. If you have an information to the contrary, let me know, otherwise I think there is no room for improvement either.

- The general approach taken. There you must evaluate whether you actually do need to browse through the whole thing. But, if the answer is yes, then going from branch to branch and getting a list of sub-nodes is the only way to go: That's given by the design of OPC specs, not by our own decision in the client implementation.


As a side note, this kind of things (globally disabling/enabling alarms) is better handled with OPC specs designed with such requirements in mind. For example, in OPC Alarms&Events, all alarms residing in a hierarchical "area" can be enabled/disabled with a single call and with just identifying the area, without even having to know the individual alarms affected.

A cleverly designed system can achieve similar effect with OPC Data Access as well, but only with an OPC server that is already developed with the requirements in mind. There can be, for example, OPC Data Access tags that enable/disable the whole structure at alarms at will.

BTW. I understand that "hours" do not sound good as a time to start up a system. Can you provide some concrete information? Have you measured the actual speed? How many tags are you able to browse in what time?

Also, even if it were hours, why isn't is possible to go through this step once, store an information e.g. in a file, and cache it for long time? OPC is designed in such a way that while the address space CAN generally change, it is assumed to be generally stable for long periods of time.

There are two basic things being done in the code: The BrowseXXXX calls, and the ReadXXXX calls. There isn't much that can be don to speed up the browse operations, maybe except that if that information is stable, you can gather the structure of the address space just once or on demand or infrequenrly, and store it, so that the browsing does not have to be repeated over and over.

The other part that affects the performance is the reading. Reading OPC items one by one is quite unefficient. Assuming that the branches contain (on average) significantly more than one item, you can gain speed by reading all items in each branch using the ReadMultipleItems or ReadMultipleItemValues method.

I will answer the part about Properties in the separate topic you have started.

(here is the original post:)


I have an application that has to parse through the nodes, leaves and branches of an OPC server and put all tag names into a database table. some of these servers are gigantic and I was wondering if you could look at the code which was created utilizing your example and tell me if there is a way to get this to run faster. it takes forever to browse through and opc server with say 30,000 tags this takes over 5 hours.

I did see your post yesterday, but it appears that you have edited it to "NA" later? I was about to answer with a suggestions revolving around the use of ReadMultipleXXXX. Have you already found your solution? And, would you mind if I put your original post back and reply to it, because it might be a useful reading for other users?

Best regards