Hi,

I was partially able to finish the test that you have requested.

#1 The subscription mode is supported by the server, external opc client like opc-expert is able to read the tag data which is updated every second and values are decoded properly. however opc labs is throwing DCOM permission exception.



And the demo tool does not fetch any values afterwards. I have to close and re-open application.

#2 I tried to write data through old version of opc labs and opc-expert tool but both of them gave errors for class not registered. I did try to register the exe with RegServer command but the EasyOPCDemo tool was not throwing any error and it was able to write it.




I will forward the logfiles in the same email where i received the OPC Analyzer.

Thank you,
Harsh

Thank you!

Please allow me sometime to respond with the results.

It should take 2-3 days to arrange this.

Hi,

Sure please find my answers below.

1. Yes I agree with the Note 1 and can confirm that problem can be reproduced with QuickOPC 5.80.
2. This specific server does not support Subscription based reading.
3. Yes this problem seems to be across all double items. Strings and int values are fine. I have manually tested with 4,5 different tags from the Easy OPC DA Demo tool but our production client is reporting problem across all the double tags.

I also agree and with Note 2 and am aware that they are totally different values.

Please let me know what is our path forward to fix this problem?


Thank you

Since I could not edit my previous response, I have corrected few links and formatting,


Thank you for the response.I am only looking for the resolution on the latest version. My aim to include behaviour of the old version to help us find a useful clue to the investigation.I will answer your questions point by point.
1. No, the closest product description i could find is in the below document. library.e.abb.com/public/b6bbb4296157445795b5674e79085532/2P...stration_and_Configuration.pdf
2. Yes you are right it is a server-specific error message coming from the OPC server, we do not have that error message string defined in the tool.
3. It seems a COMException because I received the errorMessage string inside DAVTqResult[] after making the ReadManyRequest Call.
4. You are right in understanding that my code is passing the Unknown DataType. it was a minor oversight which caused the confusion. the flag was turned on in the system without supplying a data-type, which led default selection of Unkown to be selected.



Now Please let us focus on the main problem,
I am trying to receive the same data that old version of the OPC Labs and Third party tool OPC Expert is receiving. i.e 242 for TAG "SAG_Tonnege_PARC_PidPV" but in the latest version i'm getting 3.4456124702383e-315 as a double. Please review the screenshot 2, 3, 4 from earlier post.

My question is, how can i get the same value as the old version of OPC Labs was providing?

I did try to manually convert the value what might possibly be happening in the SDK I am supposed to get the same decimal value after conversion but instead it is resulting into a wrong value.

See from the below screenshot 1 i tried to convert 242 decimal to binary, I used the following online converter,

www.binaryconvert.com/result_double.html?decimal=050052050


Then I took the hex value and fed into another online IEEE754 Floating point converter,
www.h-schmidt.net/FloatConverter/IEEE754.html



In the SDK's data type detection, it appears that the expected value of 242 is not being returned. The other third-party application decodes the value correctly, so I strongly suspect that OPC Labs may be mishandling the conversion of values to float or double. The actual data type is double, but it seems that OPC Labs is converting it to a float and then returning that value as a double.




the real-time value is a bit off by couple digits but we can ignore that since the actual value that we received could be a different. And I am also aware that tags are a bit different.

Hi Zbynek,

I hope this message finds you well. My name is Harsh, and I am part of the software development team at Woodgrove Technologies. We have been utilizing your OPC Labs Classic (OPC-DA) and OPC UA components in our software, which is built on the .NET Framework 4.7. We purchased a permanent license with five years of support in December 2022, and I am pleased to inform you that your components have proven to be highly stable and integral to our software for many years.

However, we have encountered an issue during a recent deployment. When connecting our application to the ABB.RtdbOpcDaServer.1 OPC server, we observed that the library is detecting the data type as "Unknown," as illustrated in the attached Image 1.


Image 1: Woodgrove's test opc client built with OpcLabs.QuickOpc.5.80.347


Testing with another recent version resulted in correct data type detection, but it provided incorrect values:

Image 2: Woodgrove test opc client built with OpcLabs.QuickOpc.5.70.1152



The original values, as seen in the OPC server and validated by other clients, are shown in Images 3 and 4:

Image 3: OPC Expert's result from the same DA server




Image 4: Woodgrove's opc client built with OpcLabs.QuickOpc.5.59.1034



Additionally, using the demo application included with the OPC Labs QuickOPC 2022.2 Installer resulted in a similar issue as shown in Image 2:



Image 5: OPC Labs EasyOPC.NET Demo application



We have not encountered this problem with other OPC servers, nor did we face it with previous versions of OPC Labs components (Ref. Image 4). The current behavior, where data type detection fails and incorrect values are retrieved without any clear conversion or mapping, is very concerning.

can you please advise if there are any specific method parameters or configurations we should use with the EasyDAClient to retrieve the data without any conversion? Alternatively, we would appreciate it if you could provide a fix or workaround for this issue.

Thank you for your support. We look forward to your prompt response to help us resolve this matter.

Best regards,
Harsh
Woodgrove Technologies