I've stumbled around a bit trying to create a bitbake file that can build a quasar project, without a lot of success. Is there documentation or reference material on this anywhere?

The default generated AddressSpace implementation of UaVariant-type CacheVariables prevents clients from writing back arrays matching the current datatype, since the valueRank is always set to -1 for non-array types (including UaVariant), despite the server being allowed/able to write in an array-type variant value.

A suggested fix would be setting the valueRank for UaVariant CacheVariables to -3 (which in the open62541 implementation corresponds to scalar or 1D-array; see open62541 docs - Information Modelling) when generating the AddressSpace class. A possible implementation would be the addition of the following two lines to AddressSpace/templates/designToClassBody.jinja:

141         {# configure valueRank and arrayDimensions #}
142         {% if cv.array|length>0 %}
143           m_{{cv.get('name')}}->setValueRank( 1 ); // 1D-array
144           {
145             UaUInt32Array arrayDimensions;
146             arrayDimensions.create(1);
147             m_{{cv.get('name')}}->setArrayDimensions(arrayDimensions);
148           }
149 +       {% elif cv.get('dataType') == 'UaVariant' %}
150 +         m_{{cv.get('name')}}->setValueRank( -3 ); // scalar or 1D-array
151         {% else %}
152           m_{{cv.get('name')}}->setValueRank( -1 ); // scalar
153         {% endif %}

Hi All,

I have a problem with logging (using the Boost rotating logfile flavour of logging) with a specific server.

During investigating a problem with this server, I see no other option but to log extremely verbosely, wait for the error to occur then dig around in the resulting giant logfiles. The boost rotating logfile size is hardcoded to 10*5MB files - 50MB total, and due to the verbosity of what I need to log this is insufficient, it only gives me about the last 5 minutes of log output before the oldest logs are deleted.

Short term of course, I locally change the hardcoded value. Longer term, the rotating log file count and size should be made configurable, that raises questions too…

1. Where should the configuration entries go?
   a. In the StandardMetaData.Log element somewhere gets my vote
2. How to homogenize log configuration for UaTrace and boost? (I know ATLAS prefers UaTrace based logging – already configurable via ServerConfig.xml)
   a. UaTrace configuration appears to be file count and log entry count.
   b. Boost logfile configuration (in the C++ code) is by file count and log file size.
   c. To me the boost approach makes sense; presumably system administrators would be happier to know the precise potential log footprint on disk (i.e. size * count), the UaTrace (log entry * count) seems more vague; how many bytes will a log entry be?
3. Should the log disk footprint (logfile count + size) be modifiable at runtime?
   a. I think not, increasing the footprint is probably fine, reducing it could be more complicated – quasar would discard existing logs. One data entry mistake and possibly useful log information is gone. I think it should be specifiable only at startup - in the config.xml.

So, this looks a lot like further support (and questions) for the internal ticket (OPCUA-686). Any thoughts/comments?

Cheers,
Ben

it should be set_build_config instead I believe.