Defining the value for the mandatory property EURange in an AnalogItemType variable

450 views
Skip to first unread message

piova...@gmail.com

unread,
Nov 7, 2017, 10:02:53 AM11/7/17
to open62541

Hi,

I'm a little bit lost trying to create an AnalogItemType variable.

When I create a variable with type AnalogItemType

UA_Server_addVariableNode(server, myIntegerNodeId, parentNodeId,
        parentReferenceNodeId, myIntegerName,
        UA_NODEID_NUMERIC(0, UA_NS0ID_ANALOGITEMTYPE), attr, NULL, NULL);

the server automatically create a property node with type EURange as it is required, since the property is mandatory.
But the EURange has no value and has data type BaseDataType, while I'd expect that it had data type Range.
Has anyone experience in using AnalogItemType variable? How should I set a range value for the property?

Going a little bit deeper, from UaExpert, I can see:


If I look to the type definition in the address space under Types -> Variable Types -> DataItem Type -> AnalogItem Type -> EURange, it seems that the problem is already in the type definition node, which specifies already the BaseDataType as the node Data Type.

Looking to another server based on a different SDK, through UaExpert, we can see, for the type node and the EURange property node of an AmalogItem Type variable (you can see that both type definition and properties nodes have Range as a data type:






Thanks,
Luca

Auto Generated Inline Image 1
Auto Generated Inline Image 2
Auto Generated Inline Image 3

Stefan Profanter

unread,
Nov 7, 2017, 11:01:23 AM11/7/17
to open62541
Hi Luca,
are you using the 0.2 branch or current master?

I just checked with current master and it shows the correct type using UA_ENABLE_FULL_NS0:



BR
Stefan
Auto Generated Inline Image 1

Luca Rodda

unread,
Nov 7, 2017, 11:14:08 AM11/7/17
to open62541
Hi Stefan,

You're right, I downloaded the open62541-0.2.zip file from github: https://github.com/open62541/open62541. Then, I selected UA_ENABLE_GENERATE_NAMESPACE0 in cmake configuration.

It looks that I made the wrong choice. I'll try to use the code from the master branch and I'll keep you updated.

Thanks,
Luca

Luca Rodda

unread,
Nov 7, 2017, 11:40:37 AM11/7/17
to open62541
Sorry Stefan,

I'm just starting with the project. Downloading the zip file from the master branch and using cmake, I'm able to generate the project, until I select UA_ENABLE_FULL_NS0.

When I select UA_ENABLE_FULL_NS0, cmake fails to generate the project, indicating "You probably need to initialize the git submodule for deps/ua-nodeset."

I don't find where to adapt the configuration. Should I turn to use git clone from the very beginning (I planned to do some test on the downloaded code before setting up a repository clone...)?

Ciao,
Luca

On Tuesday, November 7, 2017 at 5:01:23 PM UTC+1, Stefan Profanter wrote:

Stefan Profanter

unread,
Nov 7, 2017, 11:49:21 AM11/7/17
to open62541
After you checked out the repository using git cline, you can initialize the git submodule with:

git submodule init
git submodule update

That should fix it

Julius Pfrommer

unread,
Nov 7, 2017, 12:22:48 PM11/7/17
to open62541
Luca is using the zip download from github but not git itself.
How should he proceed?

Stefan Profanter

unread,
Nov 7, 2017, 3:12:18 PM11/7/17
to open62541
If you are using the zip download then you need to also download the referenced submodules.

The links to those modules can be found here:
https://github.com/open62541/open62541/blob/master/.gitmodules

and the corresponding git commits are listed here:
https://github.com/open62541/open62541/tree/master/deps

In the case of current master it is:
https://github.com/Pro/mdnsd/tree/4cea3adf05cdea4d1149514c55c0eb2f1d857032

https://github.com/OPCFoundation/UA-Nodeset/tree/ddce8bb6a1792916b161a9e3ba3b6b80675e8c1e

Luca Rodda

unread,
Nov 8, 2017, 5:45:57 AM11/8/17
to open62541
Thank you Stefan,

I moved to git cloning approach, because the cmake scripts seem expect a git folder and issue a fatal when the folder (as unpacked from the zip) doesn't contain a .git folder. Then, it didn't make sense to create a git folder from the downloaded zip and I cloned the repository.

Afterwards, I was able to build the project with various option without errors.

Yet, I'm not able to run any example with the libraries generated with the option UA_ENABLE_FULL_NS0. My prototype and the examples included with the library generate a stack overflow exception during the execution of the UA_Server_new(config) function.

You can easily reproduce the behaviour by running even the very first example from the tutorial: tutorial_server_firststeps.exe (as built together with the stack by selecting the cmake option UA_BUILD_EXAMPLES).

Maybe it could be due to the config setup defined by the UA_ServerConfig_new_default(), which defaults to a minimum configuration.

Then, there are two points:
  1. Do you have any hints about an configuration setting appropriate for running the stack with UA_ENABLE_FULL_NS0?
  2. Probably, error management should be enhanced in order to manage properly such errors and avoiding stack exceptions.

For the sake of completeness of information: I'm using VisualStudio 15.4, with the project options as generate by cmake (building for 32 bits debug) and running the application on Windows 10.


Best,

Luca R

Stefan Profanter

unread,
Nov 8, 2017, 8:43:11 AM11/8/17
to open62541
Hi Luca,
the problem is the limited default stack size of Visual Studio generated executables.

Therefore you need to increase the reserved stack size of visual studio project, because initializing full NS0 is heavy on the stack.

See https://github.com/open62541/open62541/issues/1251#issuecomment-336910629 for further details.

Project -> Properties -> Configuration Properties -> Linker -> System -> Stack Reserve Size = 10 000 000

Then it should work.

I also added a corresponding issue here:
https://github.com/open62541/open62541/issues/1326

BR
STefan

Luca Rodda

unread,
Nov 8, 2017, 9:51:35 AM11/8/17
to open62541
Hi Stefan,

you're right. The applications runs with minimum 3MB stack and fails with 1 or 2 MB. I still have some functional problems: I'm using now a 10MB stack as you suggested and, for example, I don't see monitored items' values on the client for variables created according to the v0.2 tutorial examples. It could be due to the various changes from v0.2 to v0.3: I will check with the examples from v0.3 in order to fix the problem.

In any case, it looks that the requirement for such a stack is really much bigger than I would expect (really huge, if you think about porting open62541 v0.3 to an embedded system). I'm afraid that it could become a problem in future developments. I'll think about it...

Thanks,
Luca

Stefan Profanter

unread,
Nov 8, 2017, 10:11:30 AM11/8/17
to open62541
Hi Luca,
this large stack size is only required if you build with the full NS0 (and there are already plans to reduce the required stack size, e.g. see https://github.com/open62541/open62541/issues/1255)

Our stack is one of the few which are really suitable for embedded devices since it is our main focus. In the past me and other core developers and users have ported the stack on different embedded devices. There are also papers describing this step.

In general you will not deploy the full NS0 on such resource limited devices. OPC UA allows you to only add a small subset of the full NS0. I.e. you should adapt the namespace to your needs and you will definitely not need such a stack size.
With optimal settings you can reach a binary size less than 100KB (which also means that the stack does not need to be bigger).

Hope this sheds more light on your questions.

BR
Stefan

Luca Rodda

unread,
Nov 8, 2017, 10:25:04 AM11/8/17
to open62541
Hi Stefan,

Thank you very much, It's pretty clear.

Indeed, this is the approach we're thinking about: we'll only need few data variable types from the full NS0 (maybe, AnalogItem and MultistateDiscrete and little bit more) and we look forward both to your effort for reducing the stack size and to a good tailoring of the namespace on our side. I'm confident that we'll be able to fit with the available resources.

I'm waiting for the kick-off for the porting project and, in the meantime, I'm preparing a functional prototype on Windows for a demo: even a huge stack is not a problem, for now.

When the porting project will start, we'll be able to share progresses.

Thanks again,
Luca
Reply all
Reply to author
Forward
0 new messages