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.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Connections, Reconnections, COM/DCOM
- Compatibility and Functionality Issues with QuickOPC at DeltaV Sites
Compatibility and Functionality Issues with QuickOPC at DeltaV Sites
It is weird that connecting to OPC Analyzer gives "Class not registered". There is something seriously wrong there.
Did OPC Analyzer offer you a choice of OPC servers to connect to, and have you selected the DeltaV server? What do you have in the "Server" field shown below (where I have the Merz OPC server)?
Thank you
Attachments:
Please Log in or Create an account to join the conversation.
- FAnsariCMC
- Topic Author
- Offline
- Premium Member
- Posts: 13
- Thank you received: 1
I sincerely apologize for the delayed response. I had to take care of other development tasks this past month.
We understand how difficult it is to recreate scenarios with OPC DCOM so thank you for your continued support and suggestions in trying to pinpoint this problem.
1. I disabled setting "EnableNativeClient = false" and tried testing the connection with the OPC Analyzer again. It did not resolve the connection problems
with 5.63.246
2024-12-08 05:00:49,864 [10] WARN - The following 1 error(s) were encountered when trying to verify the tags specified for localhost/OpcTestLab.OpcAnalyzer.1:
Tag 'ItemId="Channel1.Device1.Tag23"': Class not registered
+ This error may be caused by damaged or missing OPC Server registration on the specified computer.
It can also be due to a problem with OPC proxies/stubs, which can be resolved by installing OPC Core Components (from OPC Foundation).
+ The machine name was ''.
+ The server class used was 'OpcTestLab.OpcAnalyzer.1'.
+ Execution details: HasNativeClient=True, HasNetApiClient=True, ProcessBitness=32.
+ The client method called (or event/callback invoked) was 'ReadMultipleItems[1]'.
with the latest version 5.81.485
2024-12-08 06:15:18,137 [5] WARN - The following 1 error(s) were encountered when trying to verify the tags specified for localhost/OpcTestLab.OpcAnalyzer.1:
Tag 'ItemId="Channel1.Device1.Tag23"': Class not registered
+ This error may be caused by damaged or missing OPC Server registration on the specified computer.
It can also be due to a problem with OPC proxies/stubs, which can be resolved by installing OPC Core Components (from OPC Foundation).
+ The machine name was ''. The server class used was '{b8aadba5-382f-45da-aa0a-d7bb21e4ae97}'.
+ Execution details: HasNativeClient=False, HasNetApiClient=True, ProcessBitness=32.
+ The client method called (or event/callback invoked) was 'ReadMultipleItems[1]'.
Here is our code for the read and write logic, in case you see anything wrong with the implementation
/// <summary>
/// Reads the values of the read tags from the OPC DA server.
/// </summary>
/// <returns>
/// The item values read.
/// </returns>
public DAVtqResult[] Read()
{
DAVtqResult[] vtqReadResults = _daServerMgt.ReadMultipleItems(OpcServerName, ReadTags_Identifiers);
List<string> errorMessages = new List<string>();
for (int i = 0; i < vtqReadResults.Length; i++)
{
if (!vtqReadResults[i].Succeeded)
{
string errorMessage = $"Tag '{ReadTags_Identifiers[i]}': {vtqReadResults[i].ErrorMessageBrief}";
errorMessages.Add(errorMessage);
Console.WriteLine($"{OpcServerName}: vtqResults[{i}] *** Failure: {vtqReadResults[i].ErrorMessageBrief}");
}
}
return vtqReadResults;
}
/// <summary>
/// Writes the specified values of the write tags to the OPC DA server.
/// </summary>
/// <param name="writeTagValues">
/// The item values to write.
/// </param>
public void Write(List <WriteTagValue> writeTagValues)
{
// Create a new list that only selects write tags with non-null values.
// This is to avoid flushing non-null values as 0s to all write tags in the WriteTag List when write-method is called.
var writeTagList = writeTagValues
.Where(WV => WV.Value != null)
.Join(WriteTags, WV => WV.Id, WId => WId.Id, (WV, WId) => (WV.Value, WId.Identifier));
int _tagCount = 0;
int nonNullTagArraySize = writeTagList.Count();
OperationResult[] resultArray;
DAItemValueArguments[] nonNullTagArray = new DAItemValueArguments[nonNullTagArraySize];
List<string> errorMessages = new List<string>();
//This operation will create the actual array type required for executing WriteMultipleItemValues
foreach (var TagId in writeTagList)
{
nonNullTagArray[_tagCount] = new DAItemValueArguments( MachineName, OpcServerName, TagId.Identifier.ItemId, TagId.Value);
_tagCount++;
}
if (writeTagList.Count() > 0)
{
resultArray = _daServerMgt.WriteMultipleItemValues(nonNullTagArray);
for (int i = 0; i < resultArray.Length; i++)
{
if (!resultArray[i].Succeeded)
{
string errorMessage = $"Tag '{resultArray[i]}': {resultArray[i].ErrorMessageBrief}";
errorMessages.Add(errorMessage);
Console.WriteLine($"{OpcServerName}: vtqResults[{i}] *** Failure: {resultArray[i].ErrorMessageBrief}");
}
}
}
}
I made sure to install the OPC Core components in the test machine so I don't think that should be the issue.
3. Regarding this issue, I remember investigating into it and could not find a concrete error message and upon further research, I came to the conclusion that it could have been due to improperly installed DLLs, since our installer had difficulty installing/upgrading to the newer nuget packages that were required for the latest version of QuickOPC. So for now, I think it may not sense to focus on this until I can replicate this at the client's site with the latest version of QuickOPC again. I apologize for not having a detailed log for this.
Please Log in or Create an account to join the conversation.
I would like to say as a foreword, that without having a reproducible scenario here locally, all my replies would be in the realm of "try this because it is related, and see what happens", not a targeted advise given with knowledge how to reliably resolve the problem, I hope you will understand.
1. Unless you have a specific reason for the "EnableNativeClient = false" setting, please remove when using recent QuickOPC versions (did OPC Labs recommend it to you, or did you copy it from recommendation to another client's issue?) This setting can also explain the difference you are now seeing between Connectivity Explorer, and your own application, when connecting through OPC Analyzer.
2. Make sure that the latest version of OPC Core Components (from www.opcfoundation.org ) is installed on both client and server machines. On 64-bit machines, it must be the 64-bit version of OPC Core Components!
3. I was reviewing the discussion we had so far, and I realized I still miss a clear answer to one of my questions, and it is quite important. It is the question #2 from Oct 13, where I asked "
What do you mean by "…cause connectivity problems"? What precisely happens? Is it the "Specified method is not supported", or is that a separate issue? Why would you call it a connection problem if it happens only with some items?" and you replied "I apologize for the unclear language in my post. What I meant by connection issues was that ALL read tags seem to fail when the ReadMultipleItems method is called on DeltaV sites with version 5.80.293 and the tag address I provided was just an example." What is still not clear to me is *how* do these tags fail - what is the error message?
I have some more hints up my sleeve (before I forget: a) CLSID, b) write methods), but I'd like to hear you answer first, because what I have in mind may not apply, depending on it.
Please Log in or Create an account to join the conversation.
I am currently travelling and will reply by Monday. I apologize for the delay.
Regards
Please Log in or Create an account to join the conversation.
- FAnsariCMC
- Topic Author
- Offline
- Premium Member
- Posts: 13
- Thank you received: 1
This is our initialization logic:
public QuickOPC_DaServerMgtWrapper()
{
//Addresses DCOM hardening changes by Microsoft CVE-2021-26414
ComManagement.Instance.Configuration.SecurityParameters.EnsureDataIntegrity = true;
ComManagement.Instance.AssureSecurityInitialization();
_daServerMgt = new EasyDAClient();
//Increase timeout for connections
_daServerMgt.InstanceParameters.Timeouts.WriteItem = 6000;
_daServerMgt.InstanceParameters.Timeouts.ReadItem = 6000;
_daServerMgt.InstanceParameters.HoldPeriods.TopicRead = 200;
_daServerMgt.InstanceParameters.HoldPeriods.TopicWrite = 200;
//This line was recommended to force usage of their underlying rewrite for the DA Client
_daServerMgt.InstanceParameters.EnableNativeClient = false;
_daServerMgt.ItemChanged += ServerStateChanged;
}
We are setting up EnableNativeClient as false, I had done this a year ago due to a recommendation I saw on another forum post here. Please let me know if this should be set to True and if EnableNetApiClient should also be set to a value?
The application running our communication service is a WCF console app that runs as a windows service.
Please Log in or Create an account to join the conversation.
thank you for the additional information. The behavior is somewhat strange, but still it brings some new information.
First of all, are you setting properties in QuickOPC like EnableNativeClient, EnableNetApiClient anywhere in your code?
The reason I am asking is because if you do *not*, the error message actually implicates that you are running your program under .NET Core or .NET 5+, which would mean a big difference in QuickOPC, because the underlying low-level OPC Classic code is different.
Also, what type of application you have? Such as desktop app, console app, WIndows service, Web service, Web app etc.? (asking because of DCOM).
Regards
Please Log in or Create an account to join the conversation.
- FAnsariCMC
- Topic Author
- Offline
- Premium Member
- Posts: 13
- Thank you received: 1
1. I gave the example of one tag not connecting, but there were 3 different tags I was testing (including a write-tag) and they all gave the same error.
2. I meant Kepware quickclient and not quickopc client.
Please Log in or Create an account to join the conversation.
- FAnsariCMC
- Topic Author
- Offline
- Premium Member
- Posts: 13
- Thank you received: 1
Thank you for providing us with the link to the OPC Analyzer. We are coordinating with our client's IT department to get these logs to you ASAP.
In the meantime, I was working with the OPC Analyzer with our local test-bed to see if I could get it to work there first by following the instructions provided and noticed another odd issue. The DA client in our application throws this error when trying to connect to the OPC Analyzer:
Tag 'ItemId="Channel1.Device1.4224FI492"': OPC NET API error - result ID: E_NETWORK_ERROR; Could not connect to server.
+ This error may be caused by damaged or missing OPC Server registration on the specified computer.
It can also be due to a problem with OPC proxies/stubs, which can be resolved by installing OPC Core Components (from OPC Foundation).
+ The machine name was ''.
+ The server class used was 'OpcTestLab.OpcAnalyzer.1'.
+ Execution details: HasNativeClient=False, HasNetApiClient=True, ProcessBitness=32.
+ The client method called (or event/callback invoked) was 'ReadMultipleItems[3]'.
For reference, the actual tag address is localhost/Kepware.KEPServerEX.V6/Channel1.Device1.4224FI492, which our software has no trouble connecting to.
Furthermore, both QuickOPC Client and OPC Lab's Connectivity Explorer showed no issues when connecting to the OPC Analyzer intermediary server. I also made sure that they were all running under the same user with admin rights to take DCOM issues out of the equation. This was all tested on the same machine, so there shouldn't be any network issues affecting the result.
Could this be an issue with how we are initializing the connection to the server or the QuickOPC version being used (5.63.246)?
Thank you
Please Log in or Create an account to join the conversation.
thank you for additional information.
Regarding the "Specified method is not supported", it is probably not from us, but in order to figure it out, please obtain the call stack contained in the exception, it should tell you more (or post it here).
I will send you a download link for the OPC Analyzer to the email address you used to register with the forums. Make sure you understand and observe the conditions of use.
Please read this:
- kb.opclabs.com/Collecting_information_for_troubleshooting
- kb.opclabs.com/How_to_use_OPC_Analyzer
Ideally we would like to always obtain traces for the "working" and "non-working" scenario (e.g. the Write with other client versus the Write with QuickOPC).
Regarding your question about async in WriteMultipleItemValues: To you (the caller of this method), it always works synchronously. Under the hood, it can be either sync or async. If it is async, QuickOPC waits for the completion callback so it looks like sync to you. There is a way to influence which one is used, but I'd rather wait to see what OPC Analyzer tell us, because the sync/async difference what just a wild guess, just one of the possiblities.
Best regards
Please Log in or Create an account to join the conversation.
- FAnsariCMC
- Topic Author
- Offline
- Premium Member
- Posts: 13
- Thank you received: 1
Thank you for the prompt response.
A.
1) We are targeting .NET Framework 4.8
2) I apologize for the unclear language in my post. What I meant by connection issues was that ALL read tags seem to fail when the ReadMultipleItems method is called on DeltaV sites with version 5.80.293 and the tag address I provided was just an example.
3) The error message we got was "Specified method is not supported". When I was looking into this error message, it did seem like the error message was not actually being returned from the QuickOPC API itself but the result of the try-catch failing when the ReadMultipleItems was called, so I understand if this is not something that can be identified on your end and may be an issue with our implementation.
B.
1) I understand and fully agree, as we have not encountered these specific issues outside of the DeltaV sites.
2) Thank you for the explanation, is WriteMultipleItemValues an async method under the hood or sync? Or is there another method for writes that is async so we can try that as a possible solution?
3) We would really appreciate that. Could you please provide me with a link to this software?
4 and 5) I understand and agree.
6) I see, that is good to know. It may just be an issue with our upgrade process as we had multiple issues with certain assemblies that were added for later versions of QuickOPC not being replaced/properly upgraded as dependencies for our service.
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Connections, Reconnections, COM/DCOM
- Compatibility and Functionality Issues with QuickOPC at DeltaV Sites