Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Matthias Max
@bitflower
Hadn't heard of Wireshark - great tip. I will definitely try this.
Andreas Heine
@AndreasHeine
wireshark saved me multiple times in the past you can filter the packages by opcua protocol ;)
Matthias Max
@bitflower
Yes, that's my assumption. So the plan is to "scan" the OPC UA namespace and see what is really coming from the server with Wireshark?
Sounds dope :-D
First thing in the morning. If I'm close to giving up I'll give you a call :-D
Thanks and I will report back ;-)
Etienne
@erossignon
@bitflower what is the server you're trying to connect to ? it is possible that the event change is trigger becaue the timestamp of the value is only changing. The server shall be in charge of not sending unecessary data monitoring event.
Etienne
@erossignon
@josepsolerpla The client send a requested sampling interval to the server , this is a proposal from the client to the server.
The server then may decide to adjust the value to a more suitable one for itself and can increase or decrease the value. It will send a revisedSamplingInterval back to the client. The 1000 is the revised sampling interval send by the server. see https://reference.opcfoundation.org/v104/Core/docs/Part4/5.12.2/ and https://reference.opcfoundation.org/v104/Core/docs/Part4/7.16/ for more details.
The interval that defines the fastest rate at which the MonitoredItem(s) should be accessed and evaluated. This interval is defined in milliseconds.
The value 0 indicates that the Server should use the fastest practical rate.
The value -1 indicates that the default sampling interval defined by the publishing interval of the Subscription is requested. A different sampling interval is used if the publishing interval is not a supported sampling interval. Any negative number is interpreted as -1. The sampling interval is not changed if the publishing interval is changed by a subsequent call to the ModifySubscription Service.
The Server uses this parameter to assign the MonitoredItems to a sampling interval that it supports.
The assigned interval is provided in the revisedSamplingInterval parameter. The Server shall always return a revisedSamplingInterval that is equal or higher than the requested samplingInterval. If the requested samplingInterval is higher than the maximum sampling interval supported by the Server, the maximum sampling interval is returned.
Matthias Max
@bitflower
@erossignon Yes, that is my assumption. But as far as I can see from the Prosys behaviour the timestamp doesn't change. The setting in Prosys are as follow:
Bildschirmfoto 2020-12-15 um 09.50.01.png
Bildschirmfoto 2020-12-15 um 09.50.13.png
I tried to set everything the same in my node-opcua setup to exclude any config mistakes of mine. Still with node-opcua I get these 3 minute updates.
I will trace with Wireshark today to get a better undersdtanding of what's happening.
Andreas Heine
@AndreasHeine
@bitflower which firmware is on the s7-1500?
Matthias Max
@bitflower
@AndreasHeine Would this be it?
image.png
image.png
Matthias Max
@bitflower
These are my observations with WireShark:
First with Prosys only, it only receives actual values changes correctly
prosys_wireshark.gif
And this is with node-opcua: it receives an update all 3 minutes without a value change:
prosys_wireshark_node.gif
Andreas Heine
@AndreasHeine
thats strange... can you compare thr create subscription / create monitored item req/res !? there must be some parameter different!
Etienne
@erossignon
@bitflower i am noticing that each packet have a different subscription id. It should be the same. Can you share your code for review ? There must be something wrong with the way you're creating subscription.
I would like to get a viee on the create subscription transaction . Can you share the wireshark capture in private ?
Matthias Max
@bitflower
I think you are both on to something here... Investigating.
Sure, I will share in DM.
Matthias Max
@bitflower
Close to having it solved. This is executed every 3 min from MY code:
image.png
Matthias Max
@bitflower
Here's my code (remove a few bits that are related to my backend)
https://gist.github.com/bitflower/77529de473246498d3a5c4fab5f31f34
Matthias Max
@bitflower
"Create" calls resulting from my code:
Bildschirmfoto 2020-12-16 um 21.34.55.png
Bildschirmfoto 2020-12-16 um 21.36.01.png
"Create" calls from Prosys:
Bildschirmfoto 2020-12-16 um 21.37.33.png
Bildschirmfoto 2020-12-16 um 21.38.24.png
The 2 differ in "MaxNotificationsPerPublish" and "Priority"
Matthias Max
@bitflower
Aha, just found something "faulty" (and sorry for spamming this channel):
image.png
Matthias Max
@bitflower
I haven thousands of them every few milliseconds.
Matthias Max
@bitflower
It seems that after roughly 3 min my process crashes and restarts which causes my impression of the "automatic 3 min event"
Matthias Max
@bitflower
I just found a whole other suspect in the OpenSecureChannelResposnse which might be my root cause:
Bildschirmfoto 2020-12-16 um 22.53.33.png
Could this be related to all my issues? On the other hand I can read values successfully. It's not that my whole connection isn't "certified" or so.
Andreas Heine
@AndreasHeine
if you have SecurityPolicy.None and MessageSecurityMode.None the cert does not matter
Matthias Max
@bitflower
image.png
Yep, Prosys has the <MISSING> there too.
I'm trying the most simple example this morning to exclude any of my logic faults.
Matthias Max
@bitflower
Hi @all, just wanted to let you know that my issue is solved. I had set a "requestedSessionTimeout" to 5000 somewhere deep in my code and that caused the sessions to fail. They usually are around 60000.... Thanks so much all for taking the time to get back to me and try to help!