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.

Application hang-up in the call “WriteValue(this IEasyUAClient easyUAClient, UAWriteValueArguments writeValueArguments)”

Start
Prev
1
Next
End

1

support
Offline
Moderator

More

01 Dec 2015 09:04 #3711 by support

Replied by support on topic Application hang-up in the call “WriteValue(this IEasyUAClient easyUAClient, UAWriteValueArguments writeValueArguments)”

I do not quite understand your response. The quotation below, from my previous post, still holds, and answering it would aloow me to proceed further:

I'd like to obtain some more information about that is happening inside. Can you please add an event handler to the static EasyUAClient.LogEntry event, and log the information received? (at leats the text of the messages, ideally with the time received).

If you can obtain the extended tracing info, as described here: www.opclabs.com/files/knowledgebase/QuickOPC/QuickOPC-UA-2-H...nable%20extended%20tracing.pdf , it would be even better.

Best regards

Please Log in or Create an account to join the conversation.

Alex-Derksen
Topic Author
Offline
Elite Member

More

30 Nov 2015 07:33 #3710 by Alex-Derksen

Replied by Alex-Derksen on topic Application hang-up in the call “WriteValue(this IEasyUAClient easyUAClient, UAWriteValueArguments writeValueArguments)”

Dear Sir and/or Madam,

First of all I would like to indicate that your answer is too simple. The solution you provide, solving the problem the UI application, is unsatisfactory in my opinion.

In my opinion it would be better if the OPC labs library provided the solution, since the hang-up is caused by the interface-Nod ID which is made by OPC subscription.

The fact that you want to keep it short and simple is completely fine by me. However, what is not acceptable is the quality of the interfacing overall response blocks. You should consider making your interface-student trial in such a way that the UI thread does not contain a direct binding to these subscription procedures. If this is the situation and an error occurs, it would be more efficient if an exception handler then connects a message interface to the UI thread. This message should contain information about the failure and the whether the disturbed UI thread can process it.

For more information, please consult the previously attached line Forums (3691). In this online Forum (3691), we used your own previously sent Demo program, to simulate this subscription hang-up at disconnection.

I would strongly advise to use this online Forum (3691) as a main guide to solve this issue.

If there are any more problems, do not hesitate to call me.

Yours sincerely,
Alex Derksen.

Please Log in or Create an account to join the conversation.

support
Offline
Moderator

More

18 Nov 2015 16:16 #3691 by support

Replied by support on topic Application hang-up in the call “WriteValue(this IEasyUAClient easyUAClient, UAWriteValueArguments writeValueArguments)”

Hello,
thank you for the detailed post.

There may be several things in this, and we first need to separate them.

One of them is easy:

1) The fact that the demo application UI freezes while the write call blocks. This happens because the Write is called on the UI thread. And it is done in such a way because we wanted to keep the code simple. In order to keep the UI responsive, such operations (that can block for some time) should be called on a non-UI thread.

This, of course, does not address the other issues:

2) Why is the Write call blocking for so long,
3) Why the communication to the server breaks down after this long Write
4) Why a further Write then hangs and does not recover.

I have some thoughts about the causes and possible actions to take, but before we get to it, I'd like to obtain some more information about that is happening inside. Can you please add an event handler to the static EasyUAClient.LogEntry event, and log the information received? (at leats the text of the messages, ideally with the time received).

If you can obtain the extended tracing info, as described here: www.opclabs.com/files/knowledgebase/QuickOPC/QuickOPC-UA-2-H...nable%20extended%20tracing.pdf , it would be even better.

Thank you, and best regards

Please Log in or Create an account to join the conversation.

Alex-Derksen
Topic Author
Offline
Elite Member

More

18 Nov 2015 06:54 #3684 by Alex-Derksen

Application hang-up in the call “WriteValue(this IEasyUAClient easyUAClient, UAWriteValueArguments writeValueArguments)” was created by Alex-Derksen

In our application, we get a hang-up when the communication between the application and the MLC-PLC is malfunctioning. We found an error that is connected to the removal of the hardware cable (UTP) or when the MLC-PLC is powered down. Next up, when the hardware cable is reconnected and the MLC-PLC is once again powered up, the application will remain non-responsive. Afterwards the log file seemed to contain signs of the fact that the hang-up stopped working within the UAClients’ communication of write and read conditions, all of this within the scope of the MLC-PLC tags.

Further exploring this hang-up, we used the OPClabs demo program of EasyOPC-UA Demo “QuickOpcCSharpExamples”. In the attachment you will find the conclusion of the test, which contains information about the way we can simulate the hang-up.

My question to you therefore is whether it is possible to respond, and if so how, to this hang-up. If you need further information on this matter or anymore clarification on the demo and/or application, just let me know.

Yours Sincerely,
Alex Derksen