Hello,
and thank you.

The COM demo application is essentially using the same method call as you were originally. That's why it is weird that the code in ASP behaves differently. The C++ source of the demo app is installed with QuickOPC, if you like to view it.

However, the code inside QuickOPC makes internal decisions about which methods to use, and it does not report back which method it has chosen. The decisions depends largely on availability: If the server does not support certain flavor of OPC DA 1/2/3, of course we choose something that server does support. But in your tests, the server was always the same server, so this should not make a difference. There are other factors: For example, the async operation require more involved security settings than the sync operations (because not only the client calls to the server, but also the client calls into the server). So it can happen that the sync interfaces work, but the async ones don't. I actually suspect that this may be the case here, because the ASP/IIS is quite restricted.

Now back to your test: Unfortunately the code you have used is incorrect, which explains why it always fails with the RPC error. This is partly my fault - I should have instructed you better. What happens here is that in COM API of QuickOPC, there are no method overloads, and you cannot just call ReadItemValue and pass it the "data source", as in .NET. For scenarios where more than the standard parameters need to be specified, you need to switch over to the ReadMultipleItemValues (albeit for just one item), and pass it an argument object that contains the full set of parameters.

So, you need to start with an example like this one: opclabs.doc-that.com/files/onlinedocs/OPCLabs-OpcStudio/Late...20Read%20multiple%20items.html , reduce it to one item, and in the DAReadItemArguments object that gets passed to the ReadMultipleItems, set .ReadParameters.DataSource accordingly.

Also, after you do this and get it working, please test the same VBScript (with just modified output code) outside the IIS - placing it in .VBS file, and running from command line through CScript. The aim is to test whether the behavior depends on the hosting (ASP versus console).

Regards

Hello.

First of all, it not correct to say that the the script is not returning a value. That would be akin to getting back e.g. a null reference.
From the output of your script, however, it is clear a String-typed value is returned - and it is an empty string.

Second, with almost certainty, this is a server problem. This statement is not invalidated by the fact that other clients get a different value. Let me explain my reasons for this claim:

- QuickOPC code has been intentionally written to treat the Value-timestamp-quality triple received from the server as "sacred". That is, (aside from necessary type conversions) it never modifies its individual elements. So, if there is *some* Vtq received form the server, we always pass it to your code in the shape it was received.

- Of theory there can always be a bug in the above approach somewhere. Leaving aside the fact that it would be relatively difficult to actually create such bug, there is this: The code for all of this has its origins that are 20+ years old. It is time proven and it works well. Over the years, we dealt with many QuickOPC bugs - but there was not a single case in which the Vtq presented to your code was different from what the server has provided.

- Moreover, we have seen various server bugs that can cause this. This is compounded by the fact that there are *many* ways to make a Read in OPC-DA. The way the things are done differ between OPC DA 1.0, 2.x and 3.x. There are internally sync and async reads. And there is a read from the device and a read from the cache. In many cases the chosen way to do things is up to the client, and one client may be unlucky and chose the way that has a bug in the server.

- One relatively common bug in the servers (I am not saying it must be this one) is that if a Read is made immediately after OPCGroup object is created and an OPCItem added to it, the value is not immediately correct - only after certain time. Anyone who tests the server with the usual UI-based tools will inevitable introduce delays in order of seconds between these calls. And things will work for him well. But then the automated client will perform the calls one after another, and the server will show the bug.

What can be done?

- try to use read from Device: opclabs.doc-that.com/files/onlinedocs/OPCLabs-OpcStudio/Late...tem%20from%20the%20device.html
- try to force Sync read: opclabs.doc-that.com/files/onlinedocs/OPCLabs-OpcStudio/Late...an%20item%20synchronously.html

Also, OPCAnalyzer tool can be put in the middle between the client and the server and we can capture the "good" and "bad" communication and determine who is at fault. However, the tool has its own problems (such as that it only supports some specs), and doing these things always introduces a variant of the Heisenberg's indeterminacy principle: Thew behavior may change when the tool is used.

Regards