Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Getting feedback from a writeAttribute(value)
November 2, 2015
10:16, EET
Avatar
danielfb
New Member
Members
Forum Posts: 1
Member Since:
November 2, 2015
sp_UserOfflineSmall Offline

I have a doubt about the correct handling of orders sent to OPC UA servers.

The use case is very simple. Let’s say we have a simple machine with two possible states: 0 and 1 represented by the variable ‘state’. At the start this machine is in state 0 (state=0) but we want to change its state to 1 (state=1). As we plan to have a very simple OPC UA server, we don’t want to use methods at this moment, instead just we want to use ‘writeAttribute(value)’ calls to change the value of the variable ‘state’. The thing is that when we change the state to ‘1’, the machine will take some time to perform this change and here is where my doubts start. I have many ideas to implement this and I want to know what the standard behavior in OPC UA is.

From my point of view one option would be to have in the server two variables, current_state (read) and ordered_state (read + write). From the client I could change the ‘ordered_state’ to trigger the server and wait in the client until the ‘current_state’ is equals to the ‘ordered_state’ meaning my order was fulfilled. A good point is that this process can be followed by all clients subscribed to ‘ordered_state’ and ‘current_state’.

Another option would be to have in the server just one a variable ‘state’ and keep the sent state in the client. Then I would wait until the sent value in the client is equals to the ‘state’ value in the server. Doing this other clients would not know that someone has sent an order. Instead I could use maybe the ‘quality’ status to indicate that the value in the server is being changed. (Would this be an abuse of the quality attribute?)

A third option would be just blocking in the server the setAttribute call until the new value received is active. If it cannot be implemented within a reasonable time I would throw an exception to return the control to the client. If another client calls setAttribtue while one call is being executed I would just throw an exception.

All three options seems valid to me, but I would like to know what is the standard way of handling this case by existing OPC UA servers in the real world.

Thanks in advance.
Dani.

November 2, 2015
16:39, EET
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 1009
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

I think the option to use two variables is the best alternative.

OPC UA does not support that strategy in general, since the methods are the proper way to do it. To have the state as a variable and then use the method to change the state.

But I think this kind of strategy has been used more traditionally with PLCs and OPC DA servers.

With one variable, you end up easily in uncertain situations – you will need to get some feedback that the “order” has been accepted.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 518

Currently Online:
18 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 135

pramanj: 86

Francesco Zambon: 81

rocket science: 77

ibrahim: 75

Sabari: 62

kapsl: 57

gjevremovic: 49

Xavier: 43

fred: 41

Member Stats:

Guest Posters: 0

Members: 679

Moderators: 16

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1467

Posts: 6259

Newest Members:

elviralangwell4, Donnavek, Eddiefauth, DonaldPooma, fidelduke938316, Jan-Pfizer, DavidROunc, fen.pang@woodside.com, aytule

Moderators: Jouni Aro: 1009, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 983, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 26, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 321, Lusetti: 0, Ari-Pekka Soikkeli: 5

Administrators: admin: 1