search

umati / Dashboard-OPCUA-Client

OPC UA gateway based on open62541 to subscribe to servers implementing umati endorsed companion specification and publish via MQTT to the broker for https://umati.app
Mozilla Public License 2.0
18 stars 9 forks source link

[IJT] Extension Object - ResultManagement #361

Open GoetzGoerisch opened 1 year ago

GoetzGoerisch commented 1 year ago

The current version of the client does not decode the extension object TighteningResultDataType correctly.

UaExpert view which parses the Result variable. Result variable has ResultContent which points to TighteningResultDataType as shown. TighteningResultDataType includes an array of ResultValueDataType, StepResultDataType and TraceDataType Result_Extension_Object

NodeSet reference: https://github.com/OPCFoundation/UA-Nodeset/blob/f411bf96d608c7fc8b306871038ff497d66c484f/IJT/Tightening/Opc.Ua.Ijt.Tightening.NodeSet2.xml#L540-L579

TestServer implementation: https://github.com/umati/UA-for-Industrial-Joining-Technologies/tree/main/OPC_UA_Servers/Release1

Relates to PR #192

GoetzGoerisch commented 1 year ago

@mohitkumaragarwal please extent, if I missed some point. CC: @xenonforlife

mohitkumaragarwal commented 1 year ago

@mohitkumaragarwal please extent, if I missed some point. CC: @xenonforlife

@GoetzGoerisch It looks fine, once we have the support to parse the TighteningResultDataType, we can choose which set of values are needed in the Table format of values and trace graph in the umati Dashboard.

mdornaus commented 1 year ago

There were some tricky issues on retrieving ResultType data anyway. In the Method

std::string DashboardClient::getJson(const std::shared_ptr &pDataSetStorage)

the callback function tries to find a Node in a nodemap of the pDataSetSTorgae. This function checks for Object identity of a shared pointer with the pointer reference. Althoug the ResultVariable node is in the map it does not point to the same object of the pDataSetStorage and compares to false. Therefore the values are not published via MQTT. I currently try to find out why there are different shared pointes because the registering of the ResultVariable Nodes does not differ from the registration of the other nodes.

mdornaus commented 1 year ago

"ResultManagement": { "Results": { "": { "Result": { "$TypeDefinition": "nsu=http://opcfoundation.org/UA/IJT/;i=2001", "properties": { "Classification": 1, "CreationTime": "2023-4-18T10:21:17:753Z", "GeneratorAssetId": "cb4e7c0a-8799-44b-8acdc6b6-9af809e6", "IsPartial": false, "IsSimulated": true, "OperationMode": 2, "ProcessingTimes": { "AcquisitionDuration": 4.6355712953567e-310, "EndTime": "2023-4-18T10:21:17:753Z", "ProcessingDuration": 4.63557126401e-310, "StartTime": "2023-4-18T10:21:17:753Z" }, "ReporterAssetId": "652e22a-17c2-d48-8dea1696-58691935", "ResultContent": { "FailingStepResultId": "56237e30-5555-0-56237e50-5555", "FailureReason": 224, "JointId": "56237e50-5555-0-56306e70-5555", "OverallResultValues": null, "ProgramId": "5636b000-5555-0-56363400-5555", "ProgramVersionId": "56363400-5555-0-562c62e0-5555", "StepResults": null, "Trace": { "ResultId": "31-0-0-561332c8-5555", "StepTraces": null, "TraceId": "56306e70-5555-0-0-0" } }, "ResultEvaluation": 1, "ResultEvaluationCode": 0, "ResultId": "4a8ae87f-c10a-9744-9372b68e-b4d8ad4b", "SequenceNumber": 1002, "Tags": [ { "Name": "VIN", "Value": "EYX12456" }, { "Name": "SOCKET_NUMBER", "Value": "3" } ] }, "value": { "Classification": 224, "CreationTime": "1601-4-19T14:15:0:748Z", "GeneratorAssetId": "563f2e90-5555-0-562790e0-5555", "IsPartial": true, "IsSimulated": true, "OperationMode": 240, "ProcessingTimes": { "AcquisitionDuration": 4.63557129540253e-310, "EndTime": "1601-4-19T14:15:0:748Z", "ProcessingDuration": 4.63557126802813e-310, "StartTime": "1601-4-19T14:15:0:671Z" }, "ReporterAssetId": "563c88c0-5555-0-563f2e90-5555", "ResultEvaluationCode": 1446420432, "ResultId": "4a8ae87f-c10a-9744-9372b68e-b4d8ad4b", "SequenceNumber": 1446990112, "Tags": null } } } } }

Besides the pointer comparison issue the result looks pretty good with IJT.

GoetzGoerisch commented 1 year ago

@mohitkumaragarwal please try with the v2.0.0-rc5 gateway.

mohitkumaragarwal commented 1 year ago

@GoetzGoerisch Thank you very much, I will try it and update the status.

Kantiran91 commented 1 year ago

@mohitkumaragarwal Do you have any feedback yet?

mohitkumaragarwal commented 1 year ago

@Kantiran91 Apologies for the delay. I was out of office since 3 weeks and back now. I will check and update you as soon as possible.

mohitkumaragarwal commented 1 year ago

@Kantiran91

I have tried the latest version of the gateway, now, it is NOT showing the Asset Data in the following umati.app:

https://umati.app/all/TighteningSystemType/clientId%3Datlas%7Cixb%3Bnsu%3Dhttp%3A_2F_2Fwww.atlascopco.com_2FTighteningApplication_2F%3Bs%3D_2FObjectsFolder_2FTighteningSystem_5FAtlasCopco

image

With the older version of the gateway, the asset data is visible in another machine as shown below:

https://umati.app/all/TighteningSystemType/clientId%3Datlas%7Cpf8%3Bnsu%3Dhttp%3A_2F_2Fwww.atlascopco.com_2FTighteningApplication_2F%3Bs%3D_2FObjectsFolder_2FTighteningSystem_5FAtlasCopco

mohitkumaragarwal commented 1 year ago

I posted the latest update last week but due to some reason, it was not saved I guess, hence re-checked today and posted again.

Kantiran91 commented 1 year ago

@mohitkumaragarwal The current vesion is enough. The current version fix the problem with the extention object. But the version do not work with the Assets. @mohitkumaragarwal Can you send us a log of atlas ixb client? That could help us to fix it.

@GoetzGoerisch Should we open a new issue or use this issue?

mohitkumaragarwal commented 1 year ago

@Kantiran91

  1. Please find the log file of the Dashboard Client connected to IXB Device which uses the latest version of Gateway (2.0).
  2. Regarding Assets, it was working fine with older versions of the Gateway as given in the other Atlas Copco Devices.
  3. Regarding verification of the Extension Object, I was trying to connect to umati.app (as shown in the image attached), but UNABLE to connect to umati.app using MQTT Explorer (Error: Connection Refused). Earlier it was working, is there any change or Do i need to use any specific credentials for the same?

MQTT_Explorer_Error_Connection_Refused DashboardOpcUaClient-20230530.log

GoetzGoerisch commented 1 year ago

@GoetzGoerisch Should we open a new issue or use this issue?

Yes please.

mohitkumaragarwal commented 1 year ago

@Kantiran91 @GoetzGoerisch Regarding the extension object, I have verified it and the output is same as the following comment: https://github.com/umati/Dashboard-OPCUA-Client/issues/361#issuecomment-1512939146

But, it does NOT parse two sub-nested structures which are needed to get the Trace/Graph samples and other measured values... These two sub-structures contain the actual values from a Tightening System.

image

Kantiran91 commented 1 year ago

d

@Kantiran91

1. Please find the log file of the Dashboard Client connected to IXB Device which uses the latest version of Gateway (2.0).

2. Regarding Assets, **it was working fine with older versions of the Gateway** as given in the other Atlas Copco Devices.

3. Regarding verification of the Extension Object, I was trying to connect to umati.app (as shown in the image attached), but UNABLE to connect to umati.app using MQTT Explorer (**Error: Connection Refused**). Earlier it was working, is  there any change or Do i need to use any specific credentials for the same?

MQTT_Explorer_Error_Connection_Refused DashboardOpcUaClient-20230530.log

Yes - the broker works now with a user authentication. So you need login with your credentials

mohitkumaragarwal commented 1 year ago

d

@Kantiran91

1. Please find the log file of the Dashboard Client connected to IXB Device which uses the latest version of Gateway (2.0).

2. Regarding Assets, **it was working fine with older versions of the Gateway** as given in the other Atlas Copco Devices.

3. Regarding verification of the Extension Object, I was trying to connect to umati.app (as shown in the image attached), but UNABLE to connect to umati.app using MQTT Explorer (**Error: Connection Refused**). Earlier it was working, is  there any change or Do i need to use any specific credentials for the same?

MQTT_Explorer_Error_Connection_Refused DashboardOpcUaClient-20230530.log

Yes - the broker works now with a user authentication. So you need login with your credentials

Hi, Yes the broker works now with the credentials shared by Götz in the email.

Kantiran91 commented 1 year ago

@mdornaus You had an example of th IJT Server running local? Can you have a look at this two structures?

mohitkumaragarwal commented 1 year ago

@mdornaus You had an example of th IJT Server running local? Can you have a look at this two structures?

@Kantiran91 Just adding the local OPC UA Server Zip file available in case if you would like to use it: https://github.com/umati/UA-for-Industrial-Joining-Technologies/tree/main/OPC_UA_Servers/Release1

Kantiran91 commented 1 year ago

@mdornaus Seems that the StackTrace is an Array in the structure.

Kantiran91 commented 1 year ago

@mdornaus I found out that he jumped over an array element. Let's take about this tomorrow

Kantiran91 commented 1 year ago

I create an PR #489 (is still in WIP) for this.

Kantiran91 commented 11 months ago

@ccvca: Could you please also look at this issue? We think the problem is from the open62541 implementation.

I got an memory leak from valgrind: ==24== 15,053 (16 direct, 15,037 indirect) bytes in 1 blocks are definitely lost in loss record 60 of 61 ==24== at 0x48A9620: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==24== by 0x17BE6E: UA_new (ua_types.c:1242) ==24== by 0x18196E: Variant_decodeBinary (ua_types_encoding_binary.c:1190) ==24== by 0x181E4D: DataValue_decodeBinary (ua_types_encoding_binary.c:1265) ==24== by 0x17F556: Array_decodeBinary (ua_types_encoding_binary.c:497) ==24== by 0x18302B: decodeBinaryStructure (ua_types_encoding_binary.c:1666) ==24== by 0x183648: UA_decodeBinaryInternal (ua_types_encoding_binary.c:1817) ==24== by 0x1873AA: processMSGResponse (ua_client.c:469) ==24== by 0x1876F3: processServiceResponse (ua_client.c:561) ==24== by 0x1B12E7: assembleProcessMessage (ua_securechannel.c:712) ==24== by 0x1B19CA: processChunks (ua_securechannel.c:859) ==24== by 0x1B1E57: UA_SecureChannel_processBuffer (ua_securechannel.c:975)

ccvca commented 11 months ago

You once talk about a sequence of UA_new/UA_delete that cause a memory problem. Can you please share this with me. This valgrind issue is nearly impossible to debug, as it depends on external connections and can't be triggered easily.

ccvca commented 11 months ago

==24== 15,053 (16 direct, 15,037 indirect) bytes in 1 blocks are definitely lost in loss record 60 of 61

This is not related to ResultManagement, as this message also appears without reading a value.

ccvca commented 11 months ago

Is there any open62541-based OPC UA server available?

Traceback (most recent call last):
  File "/home/lxam/UmatiClient_ResultManagement/Sample-Server/installDeps/share/open62541/tools/generate_datatypes.py", line 95, in <module>
    parser.create_types()
  File "/home/lxam/UmatiClient_ResultManagement/Sample-Server/installDeps/share/open62541/tools/nodeset_compiler/type_parser.py", line 384, in create_types
    self.parse_types()
  File "/home/lxam/UmatiClient_ResultManagement/Sample-Server/installDeps/share/open62541/tools/nodeset_compiler/type_parser.py", line 426, in parse_types
    self.parseTypeDefinitions(self.outname, f)
  File "/home/lxam/UmatiClient_ResultManagement/Sample-Server/installDeps/share/open62541/tools/nodeset_compiler/type_parser.py", line 328, in parseTypeDefinitions
    raise RuntimeError("Infinite loop detected or type not found while processing types " +
RuntimeError: Infinite loop detected or type not found while processing types TighteningTraceDataType: unknonwn subtype ['tns:StepTraceDataType']. If the unknown subtype is 'Bit', then maybe a struct with optional fields is defined wrong in the .bsd-file. If not, maybe you need to import additional types with the --import flag. E.g. '--import=UA_TYPES#/path/to/deps/ua-nodeset/Schema/Opc.Ua.Types.bsd'
gmake[5]: *** [CMakeFiles/ua_gen_ijt.dir/build.make:103: ../../src_generated/types_IJT_generated.c] Fehler 1
gmake[4]: *** [CMakeFiles/Makefile2:902: CMakeFiles/ua_gen_ijt.dir/all] Fehler 2
gmake[3]: *** [Makefile:160: all] Fehler 2
gmake[2]: *** [CMakeFiles/Sample-Server.dir/build.make:133: Sample-Server-prefix/src/Sample-Server-stamp/Sample-Server-build] Fehler 2
gmake[1]: *** [CMakeFiles/Makefile2:107: CMakeFiles/Sample-Server.dir/all] Fehler 2
gmake: *** [Makefile:103: all] Fehler 2

Extended CMakeLists.txt of the sample server

ua_generate_nodeset_and_datatypes(
    NAME "IJT"
    FILE_NS "${UA_NODESET_DIR}/IJT/Tightening/Opc.Ua.Ijt.Tightening.NodeSet2.xml"
    FILE_CSV "${UA_NODESET_DIR}/IJT/Tightening/NodeIds.csv"
    FILE_BSD "${UA_NODESET_DIR}/IJT/Tightening/Opc.Ua.Ijt.Tightening.NodeSet2.bsd"
    NAMESPACE_MAP "9:http://opcfoundation.org/UA/IJT/"
    TARGET_PREFIX "${PROJECT_NAME}"
    OUTPUT_DIR "${SAMPLESERVER_GENERATED_NODESET_AND_DATATYPES_OUTPUT_DIR}"
    DEPENDS di
            machinery
)
message(ERROR "HEADERS ${UA_NODESET_IJT_HEADERS}")
message(ERROR "SOURCES ${UA_NODESET_IJT_SOURCES}")
message(ERROR "TYPE HEADERS ${UA_TYPES_IJT_HEADERS}")
message(ERROR "TYPE SOURCES ${UA_TYPES_IJT_SOURCES}")
add_library(ua_gen_ijt
            #"${SAMPLESERVER_GENERATED_NODESET_AND_DATATYPES_OUTPUT_DIR}/ijt_nodeids.h"
            ${UA_NODESET_IJT_HEADERS}
            ${UA_NODESET_IJT_SOURCES}
            ${UA_TYPES_IJT_HEADERS}
            ${UA_TYPES_IJT_SOURCES}
)
target_link_libraries(
    ua_gen_ijt
    PUBLIC ua_gen_di
           ua_gen_machinery
)
Kantiran91 commented 11 months ago

@xenonforlife Do you know any open62541 based implementation?

ccvca commented 11 months ago

This application isolates the problem: https://github.com/umati/Dashboard-OPCUA-Client/blob/e79574a08fe7c4f9bd9e0ffa15563984991da942/TestResultType.cpp (Branch https://github.com/umati/Dashboard-OPCUA-Client/pull/new/debug_IjtResultType)

GoetzGoerisch commented 11 months ago

@xenonforlife and @mohitkumaragarwal The code generation is not working for open62541 Currently we cannot figure out if this is due to a NodeSet issue or a open62541 issue. Do you have any knowledge about a open62541 sample server using your nodeset?

Can we try to debug this together as a quality assurance measure for the whole community.

mohitkumaragarwal commented 11 months ago

@GoetzGoerisch Yes sure, I agree to the suggesstion and we can debug together. We can plan a specific time common for all of us.

Kantiran91 commented 2 months ago

New trie with current commit (d465dc765e66ae3d52c5aab84fd17a6ea791e1a1) and IJT Version 2: nable to resolve DataType:http://opcfoundation.org/UA/Machinery/Result/ BaseResultTransferOptionsDataType showcasedeployment-gateway-1 | 2024-04-18 13:43:21,332 [DashboardOpcUaClient] ERROR virtual void Umati::OpcUa::OpcUaClient::buildCustomDataTypes():224 Error occured searching for ns1:ProcessingTimesDataType: map::at showcasedeployment-gateway-1 | 2024-04-18 13:43:21,332 [DashboardOpcUaClient] ERROR virtual void Umati::OpcUa::OpcUaClient::buildCustomDataTypes():224 Error occured searching for ns1:ResultEvaluationEnum: map::at showcasedeployment-gateway-1 | 2024-04-18 13:43:21,332 [DashboardOpcUaClient] ERROR virtual void Umati::OpcUa::OpcUaClient::buildCustomDataTypes():224 Error occured searching for ns1:ResultEvaluationEnum: map::at showcasedeployment-gateway-1 | 2024-04-18 13:43:21,332 [DashboardOpcUaClient] ERROR virtual void Umati::OpcUa::OpcUaClient::buildCustomDataTypes():224 Error occured searching for ns1:ResultEvaluationEnum: map::at