- Posts: 69
- Thank you received: 0
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.
Data Type Compliance
- Captain_Dash
- Topic Author
- Offline
- Platinum Member
-
Less
More
25 Oct 2018 07:35 #6795
by Captain_Dash
Replied by Captain_Dash on topic Data Type Compliance
Thanks for the more detailed explanation. We will find a way around this for the moment.
When this could be fixed in a future version it would be great.
Best regards
When this could be fixed in a future version it would be great.
Best regards
Please Log in or Create an account to join the conversation.
24 Oct 2018 18:32 #6794
by support
Replied by support on topic Data Type Compliance
The whole matter is quite complicated, and I had to do some internal analysis. Hopefully I got it right. My conclusion is that yes, whenever you need to do both read and write and use the same property for it, and the type in UA is not CLS-compliant, it cannot currently be done with UAAttribute<TValue>, you need to use UAAttribute.
A short explanation, if at all possible, is like this: Use of UAAttribute<TValue> requires you (if we are talking about the Value attribute of UA node) to specify its type using ValueType property in the [UAData] mapping attribute. For reading, this type needs to match what you obtain through read - already passed through our conversion to CLS compliant types. Unfortunately, that also means that we will be converting to THAT type while writing. This is a conflict - we will need to untangle these two somehow.
Best regards
A short explanation, if at all possible, is like this: Use of UAAttribute<TValue> requires you (if we are talking about the Value attribute of UA node) to specify its type using ValueType property in the [UAData] mapping attribute. For reading, this type needs to match what you obtain through read - already passed through our conversion to CLS compliant types. Unfortunately, that also means that we will be converting to THAT type while writing. This is a conflict - we will need to untangle these two somehow.
Best regards
The following user(s) said Thank You: Captain_Dash
Please Log in or Create an account to join the conversation.
- Captain_Dash
- Topic Author
- Offline
- Platinum Member
-
Less
More
- Posts: 69
- Thank you received: 0
23 Oct 2018 15:56 #6791
by Captain_Dash
Replied by Captain_Dash on topic Data Type Compliance
Ok, just for my personal clarifications.
Basically we have 3 options here:
1. Use a smaller type on UA and client site (UINT16, int32)
2. Use signed type (Int32, long)
3. Use non generic UAAttributeData and need to cast later at runtime.
When you say
Does this include all use cases where the type on the UA server is unsigned and not CLS Compliant? Because this would eliminate option 1. I think we already used this option on a other code part. Maybe I misunderstood something.
Best Regards
Basically we have 3 options here:
1. Use a smaller type on UA and client site (UINT16, int32)
2. Use signed type (Int32, long)
3. Use non generic UAAttributeData and need to cast later at runtime.
When you say
...when there is this difference between the data type needed inside UA (UInt32), and the type we are using on API surface (Int64/long), you cannot currently do it with generic UAAttributeData<TValue>;...
Does this include all use cases where the type on the UA server is unsigned and not CLS Compliant? Because this would eliminate option 1. I think we already used this option on a other code part. Maybe I misunderstood something.
Best Regards
Please Log in or Create an account to join the conversation.
23 Oct 2018 15:31 - 23 Oct 2018 15:31 #6790
by support
Replied by support on topic Data Type Compliance
Hello.
I am sad to report that when there is this difference between the data type needed inside UA (UInt32), and the type we are using on API surface (Int64/long), you cannot currently do it with generic UAAttributeData<TValue>; you need to use simple UAAttributeData instead (leading to 'object'-typed values).
I will make a note and check to see whether we can improve it in future version.
Best regards
I am sad to report that when there is this difference between the data type needed inside UA (UInt32), and the type we are using on API surface (Int64/long), you cannot currently do it with generic UAAttributeData<TValue>; you need to use simple UAAttributeData instead (leading to 'object'-typed values).
I will make a note and check to see whether we can improve it in future version.
Best regards
Last edit: 23 Oct 2018 15:31 by support.
Please Log in or Create an account to join the conversation.
- Captain_Dash
- Topic Author
- Offline
- Platinum Member
-
Less
More
- Posts: 69
- Thank you received: 0
23 Oct 2018 11:36 #6786
by Captain_Dash
Replied by Captain_Dash on topic Data Type Compliance
We are using the live mapping feature. The mapped variable is declared in following manner
Depending on the generic type in type UAAttributeData, we can either read or write, but not both at the same time.
Are there any other details you need to know?
[UANode(BrowsePath = ".Mode")]
[UAData(Operations = UADataMappingOperations.All, Kind = UADataMappingKind.AttributeData)]
[UAMonitoring(SamplingInterval = 250)]
[UASubscription(PublishingInterval = 500)]
public UAAttributeData<long> Mode
{
get { return mode; }
set
{
this.SetUaAttritbuteDataProperty(ref mode, value);
}
}Depending on the generic type in type UAAttributeData, we can either read or write, but not both at the same time.
Are there any other details you need to know?
Please Log in or Create an account to join the conversation.
23 Oct 2018 10:40 #6784
by support
Replied by support on topic Data Type Compliance
Hello,
please be more specific about how you use that variable. You wrote "when we map" - does that mean that you are using the Live Mapping feature of QuickOPC? Or are these just Reads and Writes on the EasyUAClient object?
Regards
please be more specific about how you use that variable. You wrote "when we map" - does that mean that you are using the Live Mapping feature of QuickOPC? Or are these just Reads and Writes on the EasyUAClient object?
Regards
Please Log in or Create an account to join the conversation.
- Captain_Dash
- Topic Author
- Offline
- Platinum Member
-
Less
More
- Posts: 69
- Thank you received: 0
23 Oct 2018 08:39 - 23 Oct 2018 08:47 #6782
by Captain_Dash
Data Type Compliance was created by Captain_Dash
Hello,
we run into a problem with a reading and writing of a variable. On server side (Codesys) the data type is UDINT
Data Type Lower Limit Upper Limit Memory
UDINT 0 4294967295 32 bit
So basically should this be the UINT32 type from the table on this page:
QuickOPC CLS Compliant Types
When we map this type on client side as long we have the problem, that we can read the variable, but are not able to write any value to the server.
When we map this type on client side as uint are we able to write values to the server but are unable to read values from the server.
Is there a way to do both reading and writing?
we run into a problem with a reading and writing of a variable. On server side (Codesys) the data type is UDINT
Data Type Lower Limit Upper Limit Memory
UDINT 0 4294967295 32 bit
So basically should this be the UINT32 type from the table on this page:
QuickOPC CLS Compliant Types
When we map this type on client side as long we have the problem, that we can read the variable, but are not able to write any value to the server.
When we map this type on client side as uint are we able to write values to the server but are unable to read values from the server.
Is there a way to do both reading and writing?
Last edit: 23 Oct 2018 08:47 by Captain_Dash. Reason: send to soon
Please Log in or Create an account to join the conversation.
Moderators: support
Time to create page: 0.074 seconds