Hello Allan and welcome to the forums!

We are looking into using OPC UA with devices, such as motion controllers.

What is the standard way for an OPC UA client to tell the OPC UA server for a motional controller to move?
Would you set an OPC UA variable that is defined for that purpose in the server?
Or would you call an OPC UA method in the server?

Generally speaking Methods are normally the best way to model actions. Compared to setting variables, they have the advantage of grouping input parameters, output parameters and the explicit action into one neat package.

As I understand it, both setting variables and calling methods will block the client until the server is done.
Is it standard for the OPC UA server to block until the hardware has completed the action?
Or would the server normally complete the variable setting or method call immediately and send an event when the hardware is ready?

How do you decide when to use an OPC variable and when to use a method?

One feature that I would like to test is how to abort or cancel a command. I know that an OPC UA “ProgramNode” has abort and cancel features.
Is that what you would use if you wanted to be able to abort a command? Are there any examples of this?

You can also perform asynchronous calls in our SDK, it all depends on your application and its needs. Method calls will only return when the action is complete, and this is why they shouldn’t be used for long-running actions. Sending an event once the command has been carried out is one option, another is showing the status in a variable. Methods such as those defined in ProgramType can be used to for example cancel commands, but this is application level logic and depends on your system and how it should behave.

What about concurrent access from multiple threads?
Can a UaClient instance be used from multiple threads? Can multiple variable settings or methods be active in the server at one time?
What happens if multiple threads try to set the same variable or call the same method at the same time?
Are these accesses queued up and executed sequentially? Are OPC UA servers multi-threaded?
How would you implement the OPC UA server to allow a latter setting of a variable to cancel the previous one, if it is still in progress?

So many questions…

The server side in our Java SDK is multi-threaded and depending on your system you may need to come up with a concurrency strategy. If you’re just setting the value of a variable, then just doing another Write to overwrite the previous value should be OK. If you have some long-running process which you’ve activated via some method, you could have another method cancelling the process.

It depends on the amount of information you want to provide of the status. If it’s a simple state like in a state machine, a good option is to define a custom Enum type enumerating all the possible states and expose a variable that has the state. If there are multiple properties, an event would be appropiate. You can also use both and leave it up to the client application how it wishes to receive information about state changes.

Of course the method call itself has output parameters, that can be used to convey some information that the server can immediately provide.

UA information models provide guidelines on how to model your system, but in the end the best way depends on the exact requirements of the system. We also provide professional services where we can help you model your application domain into UA Information Models.

A few seconds may not be a problem but at some point there are going to be timeouts and of course many simultaneous calls will take up server resources. Modelling your method calls so they return immediately (of course you may want to check input parameters, check current state etc. and do other things to ensure the validity of the method call) ensures you can use the same style regardless of the actual method execution taking one second or one hour. callAsync can help on the client side, but not with server resource consumption and timeouts.

Evaluation edition only includes documentation for the SDK layer, with the full versions also providing documentation for Java stack. In most cases, you should be fine with the SDK layer docs. Do you have some special case where you’d need information from the stack documentation?