support other internal servers (open62541 for example) about opcua-modeler HOT 10 CLOSED

first attempt with ctypes lead to a coredump. Any suggestions?

 from ctypes import cdll

  if __name__ == "__main__":
       libua = cdll.LoadLibrary("./libopen62541.so")
      config = libua.UA_ServerConfig_standard
       nl = libua.UA_ServerNetworkLayerTCP(libua.UA_ConnectionConfig_standard, 16664)

coredump here

from opcua-modeler.

open62541 only uses python for code generation from XML, there is no python wrapper as far as I know.
Starting the server externally shouldn't be a problem because you can use custom signals (e.g. SIGUSR1) and catch that in the open62541 implementation to shut it down properly.
I think that's the easiest solution.

I never worked with ctypes.
Also note that the current release RC1 has some problems with undefined stuff if you use the example code. I suggesst using the 0.2 branch.

And: your mention of jprf is wrong, the correct one would be jpfr ;)

from opcua-modeler.

I think that's the easiest solution

Sounds boring ;-) we'll make styles worth

On Sun, Nov 13, 2016, 12:51 Stefan Profanter [email protected]
wrote:

open62541 only uses python for code generation from XML, there is no
python wrapper as far as I know.
Starting the server externally shouldn't be a problem because you can use
custom signals (e.g. SIGUSR1) and catch that in the open62541
implementation to shut it down properly.
I think that's the easiest solution.

I never worked with ctypes.
Also note that the current release RC1 has some problems with undefined
stuff if you use the example code. I suggesst using the 0.2 branch.

And: your mention of jprf is wrong, the correct one would be jpfr ;)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#24 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACcfzljfI3hJMLuplA_Jpx5m09DF6Y3uks5q9vncgaJpZM4KwoVP
.

from opcua-modeler.

Styles -> ctypes . stupid auto correction..

On Sun, Nov 13, 2016, 17:57 Olivier Roulet-Dubonnet <
[email protected]> wrote:

I think that's the easiest solution

Sounds boring ;-) we'll make styles worth

On Sun, Nov 13, 2016, 12:51 Stefan Profanter [email protected]
wrote:

open62541 only uses python for code generation from XML, there is no
python wrapper as far as I know.
Starting the server externally shouldn't be a problem because you can use
custom signals (e.g. SIGUSR1) and catch that in the open62541
implementation to shut it down properly.
I think that's the easiest solution.

I never worked with ctypes.
Also note that the current release RC1 has some problems with undefined
stuff if you use the example code. I suggesst using the 0.2 branch.

And: your mention of jprf is wrong, the correct one would be jpfr ;)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#24 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACcfzljfI3hJMLuplA_Jpx5m09DF6Y3uks5q9vncgaJpZM4KwoVP
.

from opcua-modeler.

@Pro looks like I get a crash when calling things which are plugins... Are the plugins automatically loaded? Can i force loading?

from opcua-modeler.

It depends how you build the library... There are various compile switches in CMake. I think you need to analyze the core dumps further to see where exactly it fails.

from opcua-modeler.

OK. ctypes works fine. It was a stupid typo on my side. but there are a lot of boring structs to expose, and possible fragility since structs are mined with so #ifdef that change structs at compile time. I am considering looking at cython

from opcua-modeler.

I wrote a wrapper for open62541 and lua(jit).
That what quite a nice experience. It's like 2k lines of C-code to expose the OPC UA type system to native lua. However, that code will stay internal.

ua = require("libua")

-- define a callback method
function hello_world(object_id, arg1)
    return "Hello " .. arg1.value
end

-- initialize the server with a port number
server = ua.Server(4842)

-- add a method node
string_arg = ua.types.Argument()
string_arg.dataType = ua.types.String.typeId
string_arg.valueRank = -1 -- argument is scalar
input_args = { string_arg } -- list of arguments
output_args = { string_arg }
attr = ua.types.MethodAttributes()
attr.displayName = ua.types.LocalizedText("", "Hello World")
attr.executable = true
browsename = ua.types.QualifiedName(1, "hello_world")
nodeid = ua.types.NodeId(1, "helloworld")
parent = ua.nodeIds.Objects
parent_reference = ua.nodeIds.HasComponent
server:addMethodNode(nodeid, parent, parent_reference,
    browsename, attr, hello_world,
    input_args, output_args)

server:run()

open62541 uses the generated data types quite a lot in the public API.
From my experience with the lua wrapper, it is better to write generic type handling functions that take the datatype description (the UA_DataType) as an additional input. For example by having python "objects" that contain a pointer to the C-data as well as the datatype struct.
Otherwise, there will be many thousands of lines of code just to get from Python to C-representations.

from opcua-modeler.

Overall, it might even be easier to write a smallish C-extension for Python.
https://docs.python.org/3/extending/building.html

from opcua-modeler.

Done using cython

from opcua-modeler.