Professional OPC
Development Tools

logos

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.

Value not written on UAClientMapper.Write()

More
21 Feb 2019 09:23 #7123 by support
The mapping model shines in some scenarios (subscriptions, reads), but gets a bit awkward with writes.
For reads and especially subscriptions, it feels natural to receive error indications through the same "channel" (in the same way) as the successful results.
Write, on the other hand, has no "output" other than success/failure, so instinctively one would expect it to "throw" in case of error.

But there are issues with it.
One I have already mentioned: The write may involve multiple nodes. Some may succeed and some not. Throwing an exception should be reserved to situations when the *whole* operation have failed. That's how the developer expects it to behave. If we have thrown if just one or some writes have failed, it would be difficult to connect the exception(s) with the nodes they relate to.

Second reason is consistency of the whole development model - so that the operations (Read, Subscribe, Write) all behave and play together.

Best regards

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

More
21 Feb 2019 09:16 - 21 Feb 2019 09:16 #7122 by support
Hello.

1. - Yes, on every variable. This is necessary because some errors affect all nodes in a Write, but others may affect just some of them.

2. - After the mapper's Write method returns, you can check immediately. By that time all the mapped values will be set. [This holds provided that that the mapper's QueuedExecution property is at 'false', but that is the default behavior]. The Write operation only sets the members mapped with following mapping kinds: Result, ErrorCode, Exception, ErrorMessage, StatusInfo. They are all just variations of the same piece of information: The outcome of the operation. So you need to pick just one, normally. Most data is contained in the Result; the others contain selected sub-properties of it. 'Exception' is usually enough, and is easy to process (null when success, non-null in case of failure).

Best regards
Last edit: 21 Feb 2019 09:16 by support.
The following user(s) said Thank You: Captain_Dash

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

More
20 Feb 2019 23:53 #7120 by Captain_Dash
Just one more question.

Are there reasons why the errors will not be thrown as an Exception at the write operation or a return value? For us it would be more comfortable to get an immediate response whether all completed successfully or not. I guess there could be some scenarios where this is not desired so you made this decision with good reasons. I am just curious about the reasons and about possible scenarios which could happen to us one day.

Best regards

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

More
20 Feb 2019 23:38 #7119 by Captain_Dash
Hello,

we are still learning how to handle opc ua properly and for a better understanding I need to ask a few more questions. I hope that's ok here.
  1. You would recommend to map the Exceptions or ErrorCode or ErrorMessage always of every Variable and check after every write operation whether there is any Error? Or is it sufficient to do so with just one?
  2. When we call the Write method of the UAClientMapper these mappings (Exception e.g,) will be set while the method runs, so after the method returned we could check immediately without a read operation or waiting for subscriptions to receive?

Best regards

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

More
20 Feb 2019 19:53 #7117 by support
Hello.

It looks like that you are not actually checking the error situation. The Write method on the mapper does not throw an exception the way you expect in your code. Please have a look at this: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...n%20the%20Mapper%20Object.html .

.... and in particular, the last part (D. Mapping source problems) - that is what should concern you.

In short, you need to add another mapping(s) for the same tag, with mapping kind such as Exception, ErrorCode or ErrorMessage, for the Write operation (in Operations =...) or a combination of it with something else. And, during the Write, such mapped properties will be set. For example, if you map using the Exception kind, it will be set to 'null' in case of success, and to some non-null Exception object in case of failure.

Best regards

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

More
20 Feb 2019 15:53 #7113 by Captain_Dash
Hello,

thanks for the quick reply. We will try to contact the vendor of the server.

Would you exclude that a error is on the client site or maybe a bad configuration, timeouts e.g.?
We added some parts of our code below.


When the writing failed, why throws the write operation no exception? What would be best practice to handle this kind of failure to keep the program flow in consistent state, which means to react probably on this error?
 
private OpcUaMapper OpcMapper { get; }
 
public class OpcUaMapper : BindablePropertyBase, IOpcUaMapper, IDisposable
    {
        private readonly EasyUAClient client;
 
        private readonly UAClientMapper clientMapper;
 
            public virtual void Write()
        {
            clientMapper.Write();
        }
    }
 
        [UANode(BrowsePath = ".Command")]
        [UAData(Operations = UADataMappingOperations.ReadAndWrite, Kind = UADataMappingKind.AttributeData)]
        public UAAttributeData<int> Command
        {
            get { return command; }
            set
            {
                SetUaAttributeDataProperty(ref command, value);
            }
        }

Writing is triggered in this way.
try
            {
                Logger.Info($"Writing command '{commandId}' (NodeId: {NodeId}, Thread: {Thread.CurrentThread.ManagedThreadId}).");
 
                Command = commandId;
                OpcMapper.Write();
 
                Logger.Info($"Command written '{commandId}' (NodeId: {NodeId}, Thread: {Thread.CurrentThread.ManagedThreadId}).");
 
            }
            catch (Exception ex)
            {
                Logger.Fatal(ex);
            }
 

Best regards

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

More
20 Feb 2019 15:31 #7111 by support
Helo,

if there a ServiceFault reported by the server, you need to address a question to the server vendor - why is it that they have responded with a server fault? The same applies to the error you listed from the log. At some point, the server responded with "publish error": The server vendor needs to answer why they did that.

Secondly, please also provide the piece of your code that does the Write, and the error handling related to it.

Best regards

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

More
20 Feb 2019 15:04 #7108 by Captain_Dash
Hello.,

we run into a problem while writing variables to the opc server. We write values successfully to a opc multiple times. If there is a pause of 20to 80 seconds between of two write operations, wittnessed that the later operation failed.
The write operation of QuickOpc itself returned without any error/Exception.
We record a trace file and the network connection via Wireshark.
What we saw in the Wireshark file was that there is a ServiceFault message (time: 334.105323) right after the (failed) WriteRequest message (time: 334.104346).

What is the cause of the ServiceFault message?
Why has no exception been thrown during the failed write? For us it's mandatory that we can rely on a successful write operation.

In the logs of our application we found the following exception:
The OPC-UA client session with connect sequence number 5 on endpoint URL "opc.tcp://192.168.xxx.xxx:4840/UADiscovery" has encountered a publish error with code 0x80850000 for subscription ID 0 and sequence number 0. The error might be from the Publish or the Republish service. Further publish errors with this code on this session will not be logged.

What does this exception tell us?

We will send you the log and traces via Email because they are confidential.

Best regards

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

Moderators: support
Time to create page: 0.057 seconds