Online Forums
Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.
Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.
Do not use the Contact page for technical issues.
Issue with Data Type Detection in OPC Labs QuickOPC
Regarding the "Class not registered", I believe you must be doing something wrong - it is already suspicious that the error message says "localhost.OpcTestLab.OpcAnalyzer.1", because the correct ProgId does not have the "localhost." in it.
I received the OPC Analyzer trace files and other material via email. Unfortunately, the one that seems to contain the "good" trace, i.e. the file AbbRTDBOpcServerReadFromOpcExpertClipboardCopy.tra , is somehow corrupted. I cannot open it in the OPC Analyzer. Can you please re-do this, and check the OPC Analyzer can actually open this file (File -> Open Trace)?
Nevertheless, it looks like that you have already properly noticed that the weird double value *is* actually being returned to us - because the OPC Analyzer has captured it and displayed in the same way:
Regards
Attachments:
Please Log in or Create an account to join the conversation.
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
Attachments:
Please Log in or Create an account to join the conversation.
Please allow me sometime to respond with the results.
It should take 2-3 days to arrange this.
Please Log in or Create an account to join the conversation.
Thank you for the answers.
Subscription support is not optional in OPC servers. The "thing" that does not support subscriptions cannot be called an OPC server. I would be surprised if ABB released such a product. Can you please describe describe what happens when you press the Subscribe button in the EasyOPC-DA Demo Application? Note that this is not just out of curiosity. It has relevance for troubleshooting the problem at hand.
In order to obtain information about what is happening between the OPC client and the OPC server, I suggest that you collect traces of the communication using OPC Analyzer. Instructions are here: kb.opclabs.com/How_to_use_OPC_Analyzer . I will send you download link - to the email address you used to register with the Forums.
What we need are two captures:
1) The "correct" one
2) The "incorrect " one.
In both cases, it should be as minimal as possible (ideally just reading one item - the one that shows the problem). For correct one, use any OPC client that returns what you think is the correct value. For the "incorrect" one, I suggest that you actually use the EasyOPC-DA Demo app (instead of your real project), if it appears to give the same results as your real project - because of the simplicity of the app.
Best regards
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
Thank you for your answers. I have some additional questions and notes.
Question 1: Please confirm that the problem with incorrect data value can, after fixing the problem with "Unknown" requested data type, be reproduced with QuickOPC 5.80..
Note 1: Passing in "Unknown" as requested data type is always incorrect. If you do not want to prescribe a specific data type, use "Empty".
Question 2: In the Easy OPC DA Demo program which gives the incorrect value when you press "Read": What happens when you press "Subscribe item"? Do you get correct, or incorrect values?
Question 3: With this server, does the problem happen with all Double items , or just some items? When it happens with an item, does it always return an incorrect value, or just sometimes?
Note 2: While I agree with you that the incorrect numbers "look" like that there may be an encoding/decoding problem (although it is not sure), I disagree with the actual reasoning. First, it is obvious that Float and Double are represented differently. It is not necessary to go through the conversions to figure it out. Second, it is not correct to say that, in your example "the real-time value is a bit off by couple digits". They are totally different numbers. The values from QuickOPC have large negative exponent (E-315).
Best regards
Please Log in or Create an account to join the conversation.
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.
Attachments:
Please Log in or Create an account to join the conversation.
Hello,
and thank you for the nice words about the product.
We will work on this but it may take some effort. I want to clarify upfront that we can only provide support for the latest version (5.80). I take the information from your report about the (sometimes incorrect) behavior of past versions as possibly useful input to the investigation, but nothing that we would actually be trying to solve.
Questions:
1. Is it possible to obtain a copy of the server you are connecting to - a demo version possibly?
2. In image1, there is an error message that starts with "No server specific error codes defined". We do not have this text, in its literal form, in our software. Is it a text that is generated somewhere in your application? (if it is not, which I think is the case, then it might be a server-specific message coming from the OPC server).
3. Due to the "unknown" message text (#2 above), we cannot determine the actual error code. Can you please provide us with a) the type of exception object you are getting (is it COMException?), and b) the ErrorCode property of the exception (an integer).
4. You wrote that "…the library is detecting the data type as "Unknown, …". I do not fully understand this statement. From the error message, it can be seen that "Unknown" is the requested data type, i.e. something your code passes into our method (ReadXXXX), and it is not something that "the library is detecting". In the default setting, what the code passes in is the data type "Empty", which causes the server to return the value in the item's canonical data type. So I believe it is actually your code that passes in the "Unknown" data type. It is possible that, preceding the ReadXXXX call, you somehow obtain the data type, receive "Unknown", and then pass it to the ReadXXXX method. But if so, I will need more details about it - why are you doing it, and how precisely are you doing it (how are you obtaining the data type). Or, if you think your *not* doing it, please post here the relevant pieces of code that assembles the arguments for the ReadXXXX method and calls it, because I believe there must be something that sets the data type to "Unknown".
Best regards
Please Log in or Create an account to join the conversation.
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
Attachments:
Please Log in or Create an account to join the conversation.