Hello,
please create a new topic on the forums next time, for a new issue.

Yes, there appears to be an unwanted "interlocking" problem in QuickOPC 2022.1 between item subscriptions, and reading. Thank you for reporting it!
It should be fixed now - please download QuickOPC 5.63.246 or later, rebuild, and retest.

Best regards

I looked again at the piece of code you sent, and I think you need to fix it and repeat the tests.

The problem is that many of the settings involved (AllowImpersonateClient, useCustomSecurity, TurnOffCallSecurity) are set AFTER you call AssureSecurityInitialization (if you have that code branch enabled). In such case, they are really ignored - that is by design.

Best regards

If it Hello.

I am surprised because you have not mentioned before that in your old application you were setting some COM-related parameters from the code. In my previous replies, I therefore assumed that you were not doing that. But now I can see in the commented out parts of the code from the old version that you probably were setting them. And, since the objects/parameters have changed in version 2022.1, you either must have removed the setting or have done them differently with the new version. This invalidates any previous reasoning made with an assumption that the simple fact of upgrading the app to a new version has changed things.

The error you are getting is not blocking anything, but it means that whatever security parameters we are trying to use with COM initialization are ignored, and some different parameters are in use. In the links I have provided in my previous post, there is an explanation with hints as to how to prevent the error (it is not always possible, though).

It is also not clear to me what you mean "We ran into a problem while doing this.". What is "this"? Is that with the first suggestion I gave, or with the second one?

I suppose it is with the first one (AllowImpersonateClient = true), can you confirm? If so, what result do you get when trying the second one (UseCustomSecurity = false)?

Regards

Hello,
thank you for the download. I tested it and the CLSID of the Matrikon simulation server is the same as in newer version, so this possible cause is ruled out.

There were changes related to COM security in QuickOPC version 2022.1. Some information to that:

- kb.opclabs.com/What%27s_new_in_QuickOPC_2022.1
- kb.opclabs.com/COM_management
- kb.opclabs.com/COM_settings_in_OPC_Classic_client_components

This means that the default behavior is somewhat different too. I suggest that you experiment with changes below. Always place the statement at the very beginning of your program.

Try
If that does not help, remove it, and try
Best regards

Hello,

although it is not much likely to be the case, I first need to rule out one cause: The new version contains a database of some common OPC servers, and their ProgIDs and CLSIDs. And, when it knows the server (by its ProgID), it directly uses the CLSID from its internal database, so that it does not have to contact the OPCEnum on the target computer. This relies on fact that the mapping from version-dependent ProgIDs to CLSIDs should be stable.

We have a mapping for 'Matrikon.OPC.Simulation.1' in the database. I need to verify whether the version 1.5.0.0 did not have, in fact, a CLSID different from the one we have in the database. Unfortunately I do not have that version available (we currently have 1.7.something), and the MatrikonOPC site only offers me the latest version. Can you either somehow make the version 1.5.0.0 available to me, or figure out (by browsing servers) what its CLSID is?

Only if this is OK, it would make sense to investigate other possible causes.

Best regards