Hi,

Hmm.. it could maybe use more documentation..

Anyway, you will also need to additionally create the client side classes as well, easiest by target ‘client_all’. This will create a class ClientInformationModel, and then you will call UaClient.registerModel(ClientInformationModel.MODEL). Then you can read and write the generated structures as if they were normal Structures (i.e. you do not need to make any serializers etc. yourself, the SDK will take care of that). Registering the model is explained in the Client tutorial chapter 18, however it could maybe be explained bit better.

The reason why there are separate targets: common, client_base, client_impl, server_base, server_impl is because you might have separate modules for common, client and server code which means only that part must be generated for that module. Additionally client and server targets are split in two to allow editing the ‘impl’ part while majority of the generated code is in the ‘base’ part, therefore the edited code can be put to version control and the ‘base’ part be generated as part of the build. Note that both ‘base’ and ‘impl’ needs to be present for compiling as they extend each others (‘impl’ extends ‘base’, ‘base’ extends supertype ‘impl’; this somewhat emulates C# partial classes. There is also combination targets to avoid specifying all targets one by one if you have a simpler workflow, these are explained in the Codegenerator Manual.

P.S. as an additional note for server side developers reading this, there is an additiona target server_model, that can be used to copy the NodeSet XML, it is separated because in normally the folders for code and resources are separated (e.g. in maven projects), therefore a separate output folder might be needed.

Hi

At this point I suggest you read the tutorials and look at the SampleConsoleClient. However we are aware that this area of the SDK needs improvement.

At the end of the Client tutorial at section 18.4. there is few notes:
1. “Calling the getter for component values will internally get the node from the
AddressSpaceand get the value from it. It does not directly make a read call to the
server, unless the node is not present in the AddressSpace’s NodeCache. You need to
use read()methods in the UaClientif you need the latest values.”

2. “Calling the setter for component values sets the value to the local node, i.e. it is not
written to the server. You need to use write()methods in the UaClient to write the
value to the server.”

So technically the answer to “Is it possible to write the structure at once using generated code” is: Not possible with generated code due to the point 2. above. But you can write it via UaClient object normally. And the answer to “do I have to encode an ExtensionObject on my own.” is: No, the SDK does that for you when you read/write the Structures. Please see the following code:

Hi,

The cache is the client side representation of the address space as graph of nodes (obtainable via AddressSpace.getCache()). It is equivalent to NodeManagerTable/NodeManagers in the server side. It is a cache, as the address space of a database-backed server could be more that can be fit into memory. In general it reduces the number of calls the client has to make to the server.

If we take the UaNode/generated interfaces at it’s “raw”est form, it works as intended, i.e. the setXXX sets things to the UaNode, getXXX gets things from the UaNode. On the server side this causes no issues. However on the client side it is a bit more complex. The way it currently works is that the setValue methods are called by the SDK internally when the node is get from the AddressSpace.getNode. Also if you have the nodes already, you could set a newer value manually.

If you have the client UaNode of a variable, it can be cast to UaVariableImpl, which has readValue; reads a new value from the server (and calls setValue internally) and writeValue; writes the value to the server (and calls setValue internally, assuming the call did not fail).

P.S. In general we have some rough ideas on improving this a lot, but they require time, experimenting and most likely API changes, and we try to avoid making big changes.