Hello.

Our intent is to release during November 2021. Second half probably.

Best regards

Hello.

LocalizedText is a different story. It is not a structure. It is an OPC UA built-in type.
When QuickOPC-UA API was originally designed, approx. 10 years ago, we intentionally decided to treat LocalizedText as a string (i.e. only the text part; the locale is ignored). This is documented here: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ata%20Types%20in%20OPC-UA.html .

The decision was made because at that time, OPC UA was so new that users wanted to get anything simply working, and we wanted to make it as easy as possible.

LocalizedText does not appear just as a value of some nodes/attributes, but also at other places (browsing etc.).

Looking back, the decision was probably right at that time, but it is causing issues today, because users are getting more experienced and demand more advanced capabilities. Unfortunately, supporting LocalizedText in full would be a larger change, plus it may break some existing programs. We probably *will* change the way the LocalizedText is handled at some point (and it may even be soon), but the decision has not yet been made.

Best regards

Hello.

First, a correction: The current version is 2021.2 actually.
The write-direction conversion of EURange and UAEUInformation will be in QuickOPC 2021.3, which does not have release date set yet - but it will probably by October 2021.

If you really need it sooner, we can try to do it as as bug fix into current 2021.2 version. Let me know if this is needed. In such case, it would probably be ready by end of August, possibly sooner (the only issue is prioritizing with other issues in the vacation season).

Best regards

Hello.
This will need some explanation first.

With simplification, QuickOPC handles data types in OPC UA as follows:
1) UA built-in types are mapped to specific .NET types.
2) Certain other types that have their intrinsic meaning in UA are mapped to .NET classes too - this is the case with UARange and UAEUInformation.
3) Other types are mapped to UAExtensionObject (and usually encoded in binary there).
4) With Complex Data Type extension (Enterprise edition and higher), types that the server exposes using data type dictionary (1.03) or data type definition (1.04) mechanism are decoded/encoded too, and mapped to UAGenericObject.

The problem you are seeing is that the mapping for some of the types under 2) is only implemented in one direction - i.e. not for writing.

Options are:
A) Use the Complex Data Type approach (#4 above) (it is described in the documentation, with examples). It would involve creating a UAGenericObject with the fields that correspond to the fields of the target types.
B ) Manually encode the binary contents of UAExtensionObject (#3 above) and pass it to Write. This is somewhat nasty approach, but the types you mentioned are relatively small, so in the end it would not be so much of work.
C) We can implement the write-direction conversion for these data types (#2 above). We can try to do it as bug fix, but only to the current version - which is 2021.1 at the moment.

It should be noted that UAEUInformation contains localized text fields, and QuickOPC has a limited support for localized texts, so I am not sure how well this aspect will work.

Regards

Hello,
can you tell me which OPC server does support writing of these - and if there is a public demo if it?

Thank you