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.

× The OpcCmd utility (console application) is a program that allows performing various OPC operations from the command line. It can act as a generic OPC UA PubSub subscriber, and be used for evaluation, experiments, and testing.

Value Type Name seems to be not correct ?

More
17 Aug 2023 14:28 #12026 by support
Hello.

The timestamps are incorrect (invalid) in the PubSub Wireshark trace too. It must be a problem in your mockup. Here is a message from your Wireshark capture:



It says "Timestamp: Not representable".

The bytes we are talking about are highlighted: 1F 99 68 38 5a D7 dd 64 . This means a number of 0x64ddd75a3868991F = 7,268,202,156,139,256,000, which represents cca 23047 years, which must be even added do the epoch (base date) of 1601, so the total is clearly way ahead in the far future.

From the OPC UA spec (reference.opcfoundation.org/Core/Part6/v104/docs/5.2.2.5 ):

A DateTime value shall be encoded as a 64-bit signed integer (see Clause 5.2.2.2) which represents the number of 100 nanosecond intervals since January 1, 1601 (UTC).


Our subscriber's behavior is then exactly in compliance with the spec, because this date is transformed to latest representable date upon decoding, as the spec says:

A date/time is decoded as the latest time that can be represented on the platform if either
The encoded value is the maximum value for an Int64,
The encoded value represents a time later than the latest time that can be represented with the DevelopmentPlatform’s encoding.

Best regards
Attachments:
The following user(s) said Thank You: Gunter

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

More
17 Aug 2023 13:27 #12025 by Gunter

Regarding the timestamp: Which software is your OPC UA Publisher?

It's an own written mockup and not finished.
Do you think the wrong timestamps came from the mockup although i can see correct ones in the wireshark trace ??

So i tried again with your Demo Publisher, with UDP and ETH and both variants show correct timestamps in the OPC comandline Tool.
I think i should compare the different ws traces, there must be something different..
Thank you for your support. It helps me a lot. :-)

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

More
17 Aug 2023 09:47 #12023 by support
Hello.

For obtaining the data type of a node, in client-server model, each data node has a DataType attribute, which you can read. It return a Node Id of the data type. The OPC specification has predefined a list of such datatypes, plus there can be custom datatypes. The ones that are in the specification are availablee in QuickOPC in the OpcLabs.EasyOpc.UA.AddressSpace.Standard.UADataTypeIds class, so you can compare to that.

In PubSub, the dataset metadata (if you have access to it, e.g. through the PubSub configuration made available form the OPC UA publisher) - contains the data type Id for each field in the dataset.

The timeouts at the startup are kind of "normal", because the code that sets up everything takes time to ramp up, but the check for message timeout runs independently of that and sees that no message has come in time. In general, in a system like Windows, we cannot guarantee execution time of the threads, and even later down the road, under heavier CPU loads, timeout may occur. You are right that delta frames are not in use (and they should cause timeout anyway).

Regarding the timestamp: Which software is your OPC UA Publisher?

Best regards
The following user(s) said Thank You: Gunter

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

More
17 Aug 2023 06:40 - 17 Aug 2023 09:48 #12022 by Gunter
Good morning,

if you need to determine data types of entities in OCP UA, there are other ways to do it,


What would your recommendation to check variables for correct type and format ?

And for the time display problem i did a wire-shark capture in the attachments.

This are the result from OPC command line tool:



I am also wondering about the 2 timeouts before messages are recived.
I already read: kb.opclabs.com/OPC_UA_PubSub_Common_Traps_And_Pitfalls
But as far as i understand we don't send Delta Frames. So could there be any other reason for this delay ?
Attachments:
Last edit: 17 Aug 2023 09:48 by support.

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

More
16 Aug 2023 12:50 - 17 Aug 2023 09:48 #12009 by support
Hello.

As to the UInt32 in OPC UA being represented as Int64 in QuickOPC, this is by design. Please read: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ata%20Types%20in%20OPC-UA.html .

if you need to determine data types of entities in OCP UA, there are other ways to do it, it should not be done by looking at the actual values anyway.

If you need UInt32 value for processing, you can convert Int64 back to it easily.

As to the timestamp in PubSub, it is impossible to tell whether the subscriber is correct or not, with the information available. Can you get a Wireshark capture?

Best regards
Last edit: 17 Aug 2023 09:48 by support.

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

More
16 Aug 2023 12:44 #12008 by Gunter
Read value with OpcCmd:

uaclient read opc.tcp://192.168.10.2:4840/Objects "ns=2;i=1001"

Reading...
Result (value): 608 {Int64} @2023-08-16T14:05:29.586 @@2023-08-16T14:05:29.586; Good
├─ServerTimestampLocal = 16.08.2023 16:05:29
├─SourceTimestampLocal = 16.08.2023 16:05:29
├─StatusCode = Good
└─StatusInfo = Normal
Command finished: read|r (0,5 seconds).

Value (608) is okay but the type (Int64) not. (is in real: UInt32)
Timestamp also OK

Same in Wireshark:

OpcUa Service : Encodeable Object
TypeId : ExpandedNodeId
ReadResponse
ResponseHeader: ResponseHeader
Results: Array of DataValue
ArraySize: 1
[0]: DataValue
EncodingMask: 0x0d, has value, has source timestamp, has server timestamp
Value: Variant
Variant Type: UInt32 (0x07)
UInt32: 2078
SourceTimestamp: Aug 16, 2023 15:51:02.756122000 Mitteleuropäische Sommerzeit
ServerTimestamp: Aug 16, 2023 15:51:02.756123000 Mitteleuropäische Sommerzeit
DiagnosticInfos: Array of DiagnosticInfo
ArraySize: 0

And the same variable readed over PubSub subscription:

[4]: Success; 9999-12-31 23:59:59.999,999,900,00; Good; Data; publisher=[UInt16]1, group=1, writer=1, origin=A2B2F6B86619, mapping=Uadp, fields: 2
Field data (sequence): 2 element(s)
╒══╤═══════════════════════╤═════════╤══════╤═════╤═════╕
│[]│Source │Server │Status│Value│Value│
│ │Timestamp │Timestamp│Code │Type │ │
│ │Local │Local │ │Name │ │
╞══╪═══════════════════════╪═════════╪══════╪═════╪═════╡
│#0│9999-12-31 23:59:59.999│ │Good │Int64│348 │
│#1│9999-12-31 23:59:59.999│ │Good │Int64│517 │
╘══╧═══════════════════════╧═════════╧══════╧═════╧═════╛

here also correct value but a wrong type and additional a wrong time stamp.
Are these config problems or bugs ?
Best regards
Gunter

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

Moderators: support
Time to create page: 0.070 seconds