Log In
Register
Forum
Topic RSS
12:34, EEST
September 9, 2021
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
15:15, EEST
Moderators
February 11, 2020
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.
16:25, EEST
September 9, 2021
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
10:08, EEST
April 3, 2012
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.
13:08, EEST
September 9, 2021
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
13:50, EEST
April 3, 2012
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.
Most Users Ever Online: 1919
Currently Online:
18 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 735
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1523
Posts: 6449
Newest Members:
rust, christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCib, dalenegettinger, howardkennerley, Thomassnism, biancacraft16Moderators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1026, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1
