When adding the xml scheme information to the map file, e.g.

<uamapping xmlns="https://github.com/ChimeraTK/ControlSystemAdapter-OPC-UA-Adapter">
...

checking the map file against the scheme file works, e.g.

xmllint --schema opcua_mapfile.xsd example_mapping.xml  --noout

However when adding the information xmlns=.. to the uamapping node the application does not find any information from the map file any more. This is because xpath that is used when parsing the xml file does not work any more (see e.g. stackoverflow1, stackoverflow2).

Seems like the best option is to introduce a dedicated namespace with a certain prefix. This allows to register that namespace using xpath. A prefix is required by XPath.

Timestamps are currently missing. We could remodel the type to be a UADateTime, by we would be missing the indices (index0 and index1).

If the indices are required, we need to adjust the model to match the current implementation.

The test test_csa_opcua_adapter is hanging in release builds with the following output:

$ ctest -V
UpdateCTestConfiguration  from :/home/mhier/ChimeraTK/build/ControlSystemAdapter-OPC-UA-Adapter-relwithdebinfo/DartConfiguration.tcl
UpdateCTestConfiguration  from :/home/mhier/ChimeraTK/build/ControlSystemAdapter-OPC-UA-Adapter-relwithdebinfo/DartConfiguration.tcl
Test project /home/mhier/ChimeraTK/build/ControlSystemAdapter-OPC-UA-Adapter-relwithdebinfo
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 1
    Start 1: test_csa_opcua_adapter

1: Test command: /home/mhier/ChimeraTK/build/ControlSystemAdapter-OPC-UA-Adapter-relwithdebinfo/tests/test_csa_opcua_adapter
1: Test timeout computed to be: 10000000
1: Running 2 test cases...
1: Enter CSAOPCUATest without any pv
1: TestFixtureEmptySet BEGIN
1: TestFixtureEmptySet END
1: [2022-02-08 13:00:32.057 (UTC+0100)] warn/server	AccessControl: Unconfigured AccessControl. Users have all permissions.
1: [2022-02-08 13:00:32.057 (UTC+0100)] info/server	AccessControl: Anonymous login is enabled
1: [2022-02-08 13:00:32.057 (UTC+0100)] warn/server	Username/Password configured, but no encrypting SecurityPolicy. This can leak credentials on the network.
1: [2022-02-08 13:00:32.057 (UTC+0100)] warn/userland	AcceptAll Certificate Verification. Any remote certificate will be accepted.
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/server	AccessControl: Unconfigured AccessControl. Users have all permissions.
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/server	Username/Password configured, but no encrypting SecurityPolicy. This can leak credentials on the network.
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found 'name: GainPV'. Mapping line number: 88
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found 'name: Array_s15_int8'. Mapping line number: 105
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found 'name: Array_s15_int8'. Mapping line number: 109
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found 'name: Array'. Mapping line number: 113
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found 'name: Array'. Mapping line number: 117
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found. Mapping line number: 144
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found. Mapping line number: 147
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found. Mapping line number: 150
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found. Mapping line number: 153
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found. Mapping line number: 178
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found. Mapping line number: 181
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. SourceName 'name: Gustav' is missing.
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found 'name: uint32S'. Mapping line number: 209
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found. Mapping line number: 213
1: [2022-02-08 13:00:32.058 (UTC+0100)] warn/userland	Warning! Skipping PV mapping. Source PV not found. Mapping line number: 216
1: The following VariableNodes cant be mapped, because they are not member in PV-Manager:
1: int8Array__s15
1: Mein/Name_ist#int16Array
1: Mein/Name_ist#int16Array
1: Mein/Name_ist#int8Array_s15
1: Mein/Name_ist#int8Array_s15
1: Dein/Name/ist/uint8Array_s10
1: int16Array_s15
1: int16Array_s15
1: Dein/Name/ist/int32Scalar
1: Unser/Name/ist_uint8Array_s10
1: int16Array_s15
1: 
1: Mein/Name/ist/uint32Scalar
1: Dein/Name/ist/int32Scalar
1: Dieser/Name/ist/doubleScalar
1: Starting the server worker thread
1: [2022-02-08 13:00:32.059 (UTC+0100)] info/network	TCP network layer listening on opc.tcp://mskmhier:16664/

The Debug build works fine. Both builds are done against the latest master of the dependencies and on Ubuntu 20.04.

Additional variables from Table 2.2

cmake make just failed:

cmake of current masterbranch fails because
/doc/Doxyfile.in
cannot be found.
(I disabled documentation to work around this issue)

A variable will be send as an array if it is an array. Is there a specific reason to treat these separately from the standard variable (if we can encode arrays on the fly)?

Maybe we could just add an "isArray" boolean. That would also match the ProcessVariables C++ attributes, as the MTCA_Variable is essentially only a reflection of that class.

When enabling the tests (cmake options " -DENABLE_UNIT_TESTS=1 -DENABLE_COVERAGE=1"), I get the following compiler errors (on Ubuntu 16.04 / gcc 5.4.0):

Scanning dependencies of target ControlSystem-OPCUA_Sample_Adapter
[ 57%] Building CXX object CMakeFiles/ControlSystem-OPCUA_Sample_Adapter.dir/examples/ControlSystem_OPCUA_Sample_Adapter.cpp.o
[ 60%] Linking CXX executable ControlSystem-OPCUA_Sample_Adapter
[ 60%] Built target ControlSystem-OPCUA_Sample_Adapter
Scanning dependencies of target test_opcua_processvariable
[ 64%] Building CXX object tests/CMakeFiles/test_opcua_processvariable.dir/src/test_opcua_processvariable.cpp.o
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/tests/src/test_opcua_processvariable.cpp: In static member function ‘static void ProcessVariableTest::testEmptySet()’:
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/tests/src/test_opcua_processvariable.cpp:52:190: error: no matching function for call to ‘mtca_processvariable::mtca_processvariable(UA_Server*&, UA_NodeId&, const string&, const string&, const char [1], const char [1], boost::shared_ptr<ChimeraTK::ControlSystemPVManager>&)’
   mtca_processvariable *test = new mtca_processvariable(serverSet->mappedServer, serverSet->baseNodeId, oneProcessVariable->getName(), oneProcessVariable->getName(), "", "", pvSet.csManager);
                                                                                                                                                                                              ^
In file included from /home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_uaadapter.h:34:0,
                 from /home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/tests/src/test_opcua_processvariable.cpp:1:
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_processvariable.h:51:2: note: candidate: mtca_processvariable::mtca_processvariable(UA_Server*, UA_NodeId, std::__cxx11::string, std::__cxx11::string, std::__cxx11::string, std::__cxx11::string, boost::shared_ptr<ChimeraTK::ControlSystemPVManager>, boost::shared_ptr<ChimeraTK::ControlSystemSynchronizationUtility>)
  mtca_processvariable(UA_Server *server, UA_NodeId basenodeid, string namePV, string nameNew, string engineeringUnit, string description, boost::shared_ptr<ControlSystemPVManager> csManager, boost::shared_ptr<Co
  ^
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_processvariable.h:51:2: note:   candidate expects 8 arguments, 7 provided
In file included from /home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_uaadapter.h:34:0,
                 from /home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/tests/src/test_opcua_processvariable.cpp:1:
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_processvariable.h:50:2: note: candidate: mtca_processvariable::mtca_processvariable(UA_Server*, UA_NodeId, std::__cxx11::string, boost::shared_ptr<ChimeraTK::ControlSystemPVManager>, boost::shared_ptr<ChimeraTK::ControlSystemSynchronizationUtility>)
  mtca_processvariable(UA_Server *server, UA_NodeId basenodeid, string namePV, boost::shared_ptr<ControlSystemPVManager> csManager, boost::shared_ptr<ControlSystemSynchronizationUtility> syncCsUtility);
  ^
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_processvariable.h:50:2: note:   candidate expects 5 arguments, 7 provided
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_processvariable.h:37:7: note: candidate: mtca_processvariable::mtca_processvariable(const mtca_processvariable&)
 class mtca_processvariable : ua_mapped_class {
       ^
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_processvariable.h:37:7: note:   candidate expects 1 argument, 7 provided
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/tests/src/test_opcua_processvariable.cpp: In static member function ‘static void ProcessVariableTest::testClientSide()’:
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/tests/src/test_opcua_processvariable.cpp:189:140: error: no matching function for call to ‘mtca_processvariable::mtca_processvariable(UA_Server*&, UA_NodeId&, const string&, boost::shared_ptr<ChimeraTK::ControlSystemPVManager>&)’
   varList.push_back(new mtca_processvariable(serverSet->mappedServer, serverSet->baseNodeId, oneProcessVariable->getName(), pvSet.csManager)); 
                                                                                                                                            ^
In file included from /home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_uaadapter.h:34:0,
                 from /home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/tests/src/test_opcua_processvariable.cpp:1:
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_processvariable.h:51:2: note: candidate: mtca_processvariable::mtca_processvariable(UA_Server*, UA_NodeId, std::__cxx11::string, std::__cxx11::string, std::__cxx11::string, std::__cxx11::string, boost::shared_ptr<ChimeraTK::ControlSystemPVManager>, boost::shared_ptr<ChimeraTK::ControlSystemSynchronizationUtility>)
  mtca_processvariable(UA_Server *server, UA_NodeId basenodeid, string namePV, string nameNew, string engineeringUnit, string description, boost::shared_ptr<ControlSystemPVManager> csManager, boost::shared_ptr<Co
  ^
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_processvariable.h:51:2: note:   candidate expects 8 arguments, 4 provided
In file included from /home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_uaadapter.h:34:0,
                 from /home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/tests/src/test_opcua_processvariable.cpp:1:
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_processvariable.h:50:2: note: candidate: mtca_processvariable::mtca_processvariable(UA_Server*, UA_NodeId, std::__cxx11::string, boost::shared_ptr<ChimeraTK::ControlSystemPVManager>, boost::shared_ptr<ChimeraTK::ControlSystemSynchronizationUtility>)
  mtca_processvariable(UA_Server *server, UA_NodeId basenodeid, string namePV, boost::shared_ptr<ControlSystemPVManager> csManager, boost::shared_ptr<ControlSystemSynchronizationUtility> syncCsUtility);
  ^
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_processvariable.h:50:2: note:   candidate expects 5 arguments, 4 provided
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_processvariable.h:37:7: note: candidate: mtca_processvariable::mtca_processvariable(const mtca_processvariable&)
 class mtca_processvariable : ua_mapped_class {
       ^
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/include/mtca_processvariable.h:37:7: note:   candidate expects 1 argument, 4 provided
tests/CMakeFiles/test_opcua_processvariable.dir/build.make:62: recipe for target 'tests/CMakeFiles/test_opcua_processvariable.dir/src/test_opcua_processvariable.cpp.o' failed
make[2]: *** [tests/CMakeFiles/test_opcua_processvariable.dir/src/test_opcua_processvariable.cpp.o] Error 1
CMakeFiles/Makefile2:393: recipe for target 'tests/CMakeFiles/test_opcua_processvariable.dir/all' failed
make[1]: *** [tests/CMakeFiles/test_opcua_processvariable.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

Configuration of the unsecure Endpoint is wrongly implemented, or at least misleading.

Following config line does not provide the unsecure endpoint, other than expected:
<security unsecure="true" certificate="certs/server_cert.der" privatekey="certs/server_key.der" trustlist="certs/trust" blocklist="certs/blocklists" issuerlist="certs/issuer"/>

However, if you leave out the 'unsecure' attribute, it does provide the unsecure endpoint, which is not necessarily what you intend:
<security certificate="certs/server_cert.der" privatekey="certs/server_key.der" trustlist="certs/trust" blocklist="certs/blocklists" issuerlist="certs/issuer"/>

The object model can not reflect constants ATM. This should be fixed by handling constants in the adapter's initialization.

Testing brought up some things that might be changed in a future version of the adapter and should be mentioned here for later reference:

Variable Mapping

config section

• "/" in the rootFolder could be used as folder seperator
• not defining rootFolder automatically creates root folder "mtcaModule", in this case no folder should be created

additionalNodes section

• multiple additionalNodes sections are ignored without warning/error
• it is not possible to build a hierarchie (maybe a "folder" element could be introduced)
• it should be possible to insert additional nodes into subfolders alongside with actual process nodes thus adding integration meta data
• it is possible to generate additional nodes with dublicate browse path

application section

• it is possible to generate nodes with same browse path and content
• it is possible to generate nodes with same browse path and different content
• both does not make sense for ChimeraTK

Node ID

• String-Node-ID generation has to be revised, some clients display String-Node-IDs as variable names in their configuration. Using the original CTK application variable name bypasses mapping in such a case.

There is currently no automatic conversion for Void to something understood by OPC-UA, so those variables are skipped.

Would be nice to have them handled as well in some way, though probably not strictly necessary.

Cannot proxy unknown type ChimeraTK::Void for variable Devices/APPUIO/deviceBecameFunctional
Cannot proxy unknown type ChimeraTK::Void for variable manual/trigger

After fixing a function signature the adapter compiles. However it fails at runtime.
The issue is at

Hi all,

given #4 , we might end up with a lot of variables in the PVManager, a large amount of which might be device registers proxied by the API. This is not really a problem on our side, but we are (as per request) currently just exposing a long flat list of variables.

Conceptually, I would like to "split" the variables into categories. This only affects the presentation layer of OPC UA in terms of displaying the variable contents. I basically see two ways this can be done:

• Declare variables as "Application Relevant" in an XML config file and put everything else in another folder (preferred)
• Give Variable types a "type"-indicator (e.g. hardware, application, global constant, remote) that we can evaluate at runtime

Thoughts?

Best regards,

Chris

During out latest test we saw server crashes that are most likely caused by the OPC-UA-Adapter. So far we have not investigated how to trigger such a crash.

I hope the following traces give you an idea what happened and they have the same source.

crash_backtrace1.txt
crash_backtrace2.txt

.

The tests seem to be failing spuriously from time to time, maybe due to a race condition. I noticed this on Jenkins, where the probability of one out of the 6 builds has failed is quite high. I can also reproduce this on my Ubuntu 16.04 desktop machine by running make test in a while loop until it fails. It seems to be always the test_opcua_processvariable which fails. The error message of the failure is the following:

[05/16/2017 15:52:15.639] warning/network       Connection to opc.tcp://localhost:16663 failed. Error: 107: Transport endpoint is not connected
Failed to connect to serveropc.tcp://localhost:16663
/home/mhier/ChimeraTK/sources/ControlSystemAdapter-OPC-UA-Adapter/tests/src/test_opcua_processvariable.cpp(389): error in "ProcessVariableTest::testClientSide": check false failed
[05/16/2017 15:52:15.639] info/network  TCP network layer listening on opc.tcp://mskpcx19821:16663
[05/16/2017 15:52:15.639] info/network  Shutting down the TCP network layer with 0 open connection(s)

*** 1 failure detected in test suite "Master Test Suite"

Maybe this has something to do with a TCP port collision? On Jenkins, always two builds are running on the same node at the same time, and the probability of failure seems to be much higher. I can add a lock to protect against running two tests simultaneously on the same node. Still this does not explains why it also fails on my desktop machine where I did not run the tests in parallel.

I've been not able to build tag v1.1. Make failed with several errors:

cmake_and_make_outputs.txt

It seems there is a thread running after shutdown:

Thread 2 (Thread 0x7ffff190b700 (LWP 240)):
#0 0x00007ffff7f97c35 in UA_Server_run_shutdown (server=0x0) at /scratch/source/src/open62541.c:18583
#1 0x00007ffff7f78d3d in ua_uaadapter::workerThread() (this=0x8acc70) at /scratch/source/src/ua_adapter.cpp:210
#2 0x00007ffff7f45226 in ipc_managed_object_callWorker(ipc_managed_object*) (theClass=0x8accc0) at /scratch/source/src/ipc_managed_object.cpp:27
#3 0x00007ffff7f4596e in std::__invoke_impl<void, void ()(ipc_managed_object), ipc_managed_object*>(std::__invoke_other, void (&&)(ipc_managed_object), ipc_managed_object*&&)
(__f=@0x966b20: 0x7ffff7f45206 <ipc_managed_object_callWorker(ipc_managed_object*)>, __args#0=@0x966b18: 0x8accc0) at /usr/include/c++/8/bits/invoke.h:60
#4 0x00007ffff7f456f6 in std::__invoke<void ()(ipc_managed_object), ipc_managed_object*>(void (&&)(ipc_managed_object), ipc_managed_object*&&)
(__fn=@0x966b20: 0x7ffff7f45206 <ipc_managed_object_callWorker(ipc_managed_object*)>, __args#0=@0x966b18: 0x8accc0) at /usr/include/c++/8/bits/invoke.h:95
#5 0x00007ffff7f45f39 in std::thread::_Invoker<std::tuple<void ()(ipc_managed_object), ipc_managed_object*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) (this=0x966b18) at /usr/include/c++/8/thread:244
#6 0x00007ffff7f45ef4 in std::thread::_Invoker<std::tuple<void ()(ipc_managed_object), ipc_managed_object*> >::operator()() (this=0x966b18) at /usr/include/c++/8/thread:253
#7 0x00007ffff7f45ed8 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void ()(ipc_managed_object), ipc_managed_object*> > >::_M_run() (this=0x966b10) at /usr/include/c++/8/thread:196
#8 0x00007ffff2e8a0bf in () at /usr/lib64/libstdc++.so.6
#9 0x00007ffff794d554 in start_thread () at /lib64/libpthread.so.0
#10 0x00007ffff276dccf in clone () at /lib64/libc.so.6

The variable class can currently not return arrays (just scalars). The proxies will need to be adjusted.

Yet another type of server crash was observed recently. Two completely different ChimeraTK servers crashed with almost the same backtrace pointing to the OPC-UA adapter. One of the crashed was connected to entering a small value (1e-5) in a client panel of the server.

crash_backtrace.txt

The last function called in the OPC-UA adapter is: ua_readproxy_ua_processvariable_getValue_string
Since this function takes as argument a numeric range the crash might be linked to setting a small value for a process variable. On the other hand we could not reproduce the crash by setting again the same value....

There seem to be situations during server start up where OPC UA communication is started before adress space is fully populated.

In tests a client waiting for the server connected at once after starting the demo server but only some of the nodes have been working. Restarting the client fixed the problem.

The issue might also depend on system load. The worst scenario (many "missing" nodes) occured when starting the server application directly after starting the Ubuntu host - system was still loading.

The item data type read by LabVIEW has been allways "0" in tag v1.0:

With tag v1.1 it changed to the value "24":

Maybe that tells you something!?

Tests with the current LLRF-Server show a mapping error:
Variables to map:

mapping entry:

result:

amplitude node occurs in the desired folder and additionally in the folder.

The issue might be associated with the leading "/" in the variable name.

singal handlers should not use non-reentrant functions such as operators on cout or complex C++ operations, see http://en.cppreference.com/w/cpp/utility/program/signal and https://linux.die.net/man/2/signal.

It would be better to just set the std::atomic in the handler and do all the complex things (cout, stopping the adapter etc.) after the while loop in the main function.

This looks a bit like #31.:

#0  0x00007f778c1b1478 in malloc_consolidate (av=av@entry=0x7f7760000020) at malloc.c:4175
#1  0x00007f778c1b4cde in _int_malloc (av=av@entry=0x7f7760000020, bytes=bytes@entry=131072) at malloc.c:3450
#2  0x00007f778c1b7184 in __GI___libc_malloc (bytes=131072) at malloc.c:2913
#3  0x00007f778caa9e78 in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007f778faf1a43 in __gnu_cxx::new_allocator::allocate (this=0x7f777a7fbb10, __n=16384) at /usr/include/c++/5/ext/new_allocator.h:104
#5  std::allocator_traits >::allocate (__a=..., __n=16384) at /usr/include/c++/5/bits/alloc_traits.h:491
#6  std::_Vector_base >::_M_allocate (this=0x7f777a7fbb10, __n=16384) at /usr/include/c++/5/bits/stl_vector.h:170
#7  std::vector >::_M_allocate_and_copy<__gnu_cxx::__normal_iterator > > > (this=0x7f777a7fbb10, __last=..., __first=..., __n=16384) at /usr/include/c++/5/bits/stl_vector.h:1224
#8  std::vector >::operator= (this=this@entry=0x7f777a7fbb10, __x=...) at /usr/include/c++/5/bits/vector.tcc:195
#9  0x00007f778fae9f82 in ua_processvariable::getValue_Array_double (this=this@entry=0x987f9a0) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/ua_processvariable.cpp:219
#10 0x00007f778faea1cd in ua_readproxy_ua_processvariable_getValue_Array_double (handle=0x987f9a0, nodeid=..., includeSourceTimeStamp=, range=, value=0x7f777a7fbc40)
    at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/ua_processvariable.cpp:218
#11 0x00007f778fb18570 in readValueAttributeFromDataSource (rangeptr=0x0, timestamps=UA_TIMESTAMPSTORETURN_SOURCE, v=0x7f777a7fbc40, vn=0x9884188) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/open62541.c:20487
#12 readValueAttributeComplete (server=, v=0x7f777a7fbc40, indexRange=0x7f777a7fbcc0, timestamps=UA_TIMESTAMPSTORETURN_SOURCE, vn=0x9884188) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/open62541.c:20513
#13 Service_Read_single (server=, session=, timestamps=UA_TIMESTAMPSTORETURN_SOURCE, id=0x7f777a7fbca0, v=0x7f777a7fbc40) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/open62541.c:20784
#14 0x00007f778fb18dda in UA_MoniteredItem_SampleCallback (server=0x7c7f180, monitoredItem=0x7f7760004cc0) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/open62541.c:23641
#15 0x00007f778fb2500b in processRepeatedJobs (dispatched=, current=13836136266325, server=0x7c7f180) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/open62541.c:18175
#16 UA_Server_run_iterate (server=0x7c7f180, waitInternal=waitInternal@entry=true) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/open62541.c:18521
#17 0x00007f778faf7322 in ua_uaadapter::workerThread (this=0x7c7ed70) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/ua_adapter.cpp:207
#18 0x00007f778fad7bd6 in ipc_managed_object_callWorker (theClass=) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/ipc_managed_object.cpp:27
#19 0x00007f778cad4c80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#20 0x00007f778e42c6ba in start_thread (arg=0x7f777a7fc700) at pthread_create.c:333
#21 0x00007f778c23a41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

But this time the problem is not in ua_readproxy_ua_processvariable_getValue_string but in ua_readproxy_ua_processvariable_getValue_Array_double.

Clients (for me UA Expert) connect and disconnect permanently with opcua server. Also the "Server"-node is not displayed in "Objects"-folder, maybe there is a relation. We will fix it asap.

Yesterday two of the servers crashed. We had problems with one of our UALinks that manages communication between ProfiNet and OPCUA. Maybe the issue was caused by that problem. Two different types of ChimeraTK servers crashed so the cause was definitely the OPC-UA adapter. On the other hand only 4 out of 7 crashed.

#0  0x00007fe8eaaa1428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007fe8eaaa302a in __GI_abort () at abort.c:89
#2  0x00007fe8eaae37ea in __libc_message (do_abort=2, fmt=fmt@entry=0x7fe8eabfced8 "*** Error in '%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007fe8eaaea9dc in malloc_printerr (ar_ptr=0x7fe8c0000020, ptr=0x7fe8c0054000, str=0x7fe8eabf9c75 "corrupted size vs. prev_size", action=) at malloc.c:5006
#4  malloc_consolidate (av=av@entry=0x7fe8c0000020) at malloc.c:4183
#5  0x00007fe8eaaedcde in _int_malloc (av=av@entry=0x7fe8c0000020, bytes=bytes@entry=65535) at malloc.c:3450
#6  0x00007fe8eaaf0184 in __GI___libc_malloc (bytes=bytes@entry=65535) at malloc.c:2913
#7  0x00007fe8ee43dcb4 in UA_ByteString_allocBuffer (bs=0x7fe8d9335bd0, length=65535) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/open62541.c:4946
#8  0x00007fe8ee4438c1 in UA_SecureChannel_sendBinaryMessage (channel=0x7fe8c001ae90, requestId=1600325, content=content@entry=0x7fe8c026c900, contentType=contentType@entry=0x7fe8ee682a00 )
    at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/open62541.c:15356
#9  0x00007fe8ee45281a in UA_Subscription_publishCallback (server=0x864f150, sub=0x7fe8c0013c00) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/open62541.c:24020
#10 0x00007fe8ee45e00b in processRepeatedJobs (dispatched=, current=12812888767592, server=0x864f150) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/open62541.c:18175
#11 UA_Server_run_iterate (server=0x864f150, waitInternal=waitInternal@entry=true) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/open62541.c:18521
#12 0x00007fe8ee430322 in ua_uaadapter::workerThread (this=0x8644f00) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/ua_adapter.cpp:207
#13 0x00007fe8ee410bd6 in ipc_managed_object_callWorker (theClass=) at /build/libchimeratk-controlsystemadapter-opcuaadapter-01.09xenial1.00/src/ipc_managed_object.cpp:27
#14 0x00007fe8eb40dc80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#15 0x00007fe8ecd656ba in start_thread (arg=0x7fe8d9336700) at pthread_create.c:333
#16 0x00007fe8eab7341d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

I 'm not 100% sure, but the crash might have happened when the UALink was disconnected. Which means a client disappeared without closing the session and cleaning up anything.

UaExpert shows no datatype in the attributes window for nodes in the folder ServerStatus.

Here node "Server.ServerStatus.CurrentTime" as an example:

The type is not really missing. When dragging the node into the "Data Access View", "DateTime" is displayed in the corresponding column.

As a comparison you can see here the attributes of the same node from the UaCpp-Server with correctly displayed data type:

One of our industrial OPC UA clients (IBH Link UA) refuses to read the "CurrentTime"-Node due to the "missing" data type.

UaExpert sees all Root/Objects/Server - nodes twice in the DemoServer (Tag v1.0) adress space:

Is that wanted behaviour?

Since most features are now up and running, we should begin "Freezing" our project into the ChimeraTK Build System. To that End:

• Remove the dependency projects (DeviceAccess, ControlSystemCore)
  • Build a parent project that does not require system-wide installation of all components for a build (not part of ChimeraTK, use own repo)
• Modify the open62541 build for static linkage

That way, we will be able to compile the project as a ChimeraTK component and be on our way for the final release.

CMake Error at CMakeLists.txt:88 (add_subdirectory):
The source directory

/home/msk_jenkins/workspace/ChimeraTK_OPC_UA_Adapter/buildhosts/Ubuntu1404/tests

does not contain a CMakeLists.txt file.

The file tests/test_mtca_processscalar.cpp is missing in the repository. Currently it does not compile.

Just tested Subscription with LabVIEW

Very roughly the code, to subscribe to UA server Nodes in LabVIEW looks like this:

It is working until LabVIEW unsubscribes ("Delete Monitored Nodes.vi" and "Delete Subscriptions.vi") from the server. In this case the server crashes (see last lines in picture below).

I just discovered that the OPC-UA adapter crashes when receiving two times a SIGINT signal in series. I did not investigate the reason for the crash. Maybe you could have a look.

At some point the client panels lost connection to our server. This is detected by reading the CurrentTime of the ServerStatus provided by every OPC-UA server. After this event it was not possible to connect to the server any more by any client (we tried different clients, i.e. UA Expert and LabView). The server was still working. Looking at the Server process, one thread showed a very high cpu load (130%) compared to all other threads of the server. We stopped that thread and the backtrace is shown below.
stacktrace-server-hanging.txt

Maybe this connected to the problem reported here #28
At the time the connection was lost a client reading many variables was connected to the server, which included long data arrays. The problem occurred multiple times and could be solved only by restarting the server.