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
Losses at transfer for updateValue calls
September 9, 2021
12:34, EEST
Avatar
Peter.Eser
Member
Members
Forum Posts: 7
Member Since:
September 9, 2021
sp_UserOfflineSmall Offline

Hello,
I try to transfer values over a subscription from a CacheVariable on the server WITHOUT loosing a value from updateValue!
Both server and client are Prosys Java OPCUA (3.2.0-690).

On the server I have a CacheVariable and updateValue() is called at the moment just with a counter counting up.

On the client I subscribe to the variable with
dataChangeFilter.setTrigger(DataChangeTrigger.StatusValueTimestamp);
monitoredDataItem.setSamplingInterval(1);
monitoredDataItem.setQueueSize(1000);
I get onDataChange Events in the MonitoredDataItemListener and they are correct, but not for all updateValue() calls on the server side.
Some values of the counter in between are missing.

Thanks for any hint, Peter

September 9, 2021
15:15, EEST
Avatar
Matti Siponen
Moderator
Members

Moderators
Forum Posts: 319
Member Since:
February 11, 2020
sp_UserOfflineSmall Offline

Hello,

The missing values could be caused by either the updateValue being called more than once during a sampling interval or the queue is overflowing and either the oldest or the latest value is discarded. For example, if you were to call updateValue once every 1 millisecond and the publishing interval of the Subscription the MonitoredItem belongs to is 1 second, then it would be possible that in some cycles there are more than 1000 samples and the queue overflows. If the publishing interval is longer than 1 second, then the queue would be even more likely to overflow if new values are generated with high frequency.

Is there any clear trend to the missing values? If they’re consecutive, a queue overflowing would cause that. If they’re not consecutive, updateValue being called more than once per sampling interval would cause that.

September 9, 2021
16:25, EEST
Avatar
Peter.Eser
Member
Members
Forum Posts: 7
Member Since:
September 9, 2021
sp_UserOfflineSmall Offline

Hello Matti,
many thanks for reply!
The updateValue calls are not that fast, but they come in bursts, so e.g. 20 updates fast and then nothing for several seconds.
Overall I would say they cannot overwhelm a queue of 1000. From such a burst of 20 values about 5 are present at the client, some values in between, not all the first ones or all the last ones.
Is the function call updateValue and the sampling really uncorrelated, so that my thread updates the CacheVariable and an other thread in the SDK does the sampling?
If yes, is there a better way to do it, to not loose values?
The background is: the variable is not like a temperature probe, but each value I try to update is a measured value for a different workpiece.

Thanks, Peter

September 10, 2021
10:08, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 982
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hi,

The way the SDK handles “sampling”, is that whenever the value of a node changes we calculate (based on the DataValue’s SourceTimestamp) to which sampling interval that value belongs to. We only take one of the values per sampling interval.

If you have set the value without specifying the source timestamp that would be taken to current time, thus more than one value can easily be within the same interval.

If you do not care about the timestamp-order in which the values are received, you can set uaServer.getSubscriptionManager().setMinSamplingInterval(0.0). Then you can use sampling interval of 0 in the client side. NOTE, this requires at least SDK version 4.5.2. In earlier the only way is to ensure the sourcetimestamps are at least samplinginterval apart for each value.

Also, what is your PublishingInterval in the Subscription? That is the cycle the queue will empty thus it must be large enough to cover all changes to happen during that. Also, there should be some extra space since timings are not exact.

September 10, 2021
13:08, EEST
Avatar
Peter.Eser
Member
Members
Forum Posts: 7
Member Since:
September 9, 2021
sp_UserOfflineSmall Offline

Hello Bjarne,

many thanks for your reply and I think I’m a big step further, altough some further tests are necessary.
The source timestamp becomes set and it is a real source time stamp delivered from the measurement unit,
so the time can and does really differ from the OPCUA server timestamp.

Nevertheless it is a ms timestamp and differs for each value the measurement unit delivers, so if the sampling
interval is 1 it should sample every value, which is not the case, but —>

Yes, I don’t have the uaServer.getSubscriptionManager().setMinSamplingInterval(0.0) call in my current version,
but I set up a NodeManagerAdapter now and what I see is that MonitoredDataItem.getSamplingInterval() is 1 even when
I set it to 0 in the client. But I can override it in the NodeManagerAdapter MonitoredDataItem.setSamplingInterval(0) and then it works!! Every updateValue is at the client now.

I will do further tests, but for now I have a solution. Perhaps you have an idea if that is a supported feature or not, I don’t understand why the setSamplingInterval(0) of the client is modified to 1 on the server, makes no sense on the first view.

Just to answer your question PublishingInterval in the Subscription is 1000, but QueueSize is also 1000 and I’m far from 1000 values per second.
I have bursts of values whth about 5ms diference in sourcetime, but under 100 values per second.
Nevertheless I will half that to 500. My client is only a testclient, I will have to argue with our customers about the settings in their client…

Regards and many thanks to your outstanding help also to Matti,
Peter

September 10, 2021
13:50, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 982
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Good if that works.

The parameters set in client side are just requests to the server side. The servers are allowed to revise them, thus it changed 0 to the minimum which there is 1.

Note that this also means it depends entirely on the server side which is the supported minimum, i.e. you cannot expect other servers to support 0.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 518

Currently Online:
10 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 135

pramanj: 86

Francesco Zambon: 81

rocket science: 75

ibrahim: 75

Sabari: 62

kapsl: 57

gjevremovic: 49

Xavier: 43

fred: 41

Member Stats:

Guest Posters: 0

Members: 708

Moderators: 16

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1465

Posts: 6252

Newest Members:

christi10l, ahamad1, Flores Frederick, ellenmoss, harriettscherer, shanonhumphreys, KupimotoblokfuB, tamhollander5, paulinafcf, bridgette18l

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

Administrators: admin: 1