FORUM CTRLX AUTOMATION
ctrlX World Partner Apps for ctrlX AUTOMATION
Dear Community User! We have started the migration process.
This community is now in READ ONLY mode.
Read more: Important
information on the platform change.
07-01-2024 02:46 PM - edited 07-01-2024 02:59 PM
Hello,
we are currently running a CtrlX Core X3 with latest version 2.6.
Further the OPC-UA Client is used to receive data as an input.
Sometimes it seems that the OPC Client state seems to be connected, but the data nodes cannot be received correctly.
Since we are working with subscriptions to these data nodes (within Node-Red App) a lot of DL_INVALID_ADDRESS messages appear in the logs. The whole debugging within node-red is just flooded with these messages since the "Data Layer Subscripe" fails.
For the subscription the following parameters are used:
As a result the memory of the core inceases until the yellow LED flashes and no remote connection (web) is possible anymore. The only solution is rebooting the device manually by unplugging the power cable.
Probably the yellow flashing LED is caused by the memory which just runs out.
In the system performance it can be seen that the memory used by node-red is nearly 866MB.
There is no free memory at all.
As a first "workaround" we changed the values of the node-red subscription node to 10 seconds from 500 milliseconds.
But in general the question would be, if there is any other solution or possibility to avoid this kind of problem? Even if we set the values to "default" the log messages appear within seconds and effect the memory.
Thanks for you support,
Markus
Solved! Go to Solution.
07-01-2024 03:20 PM
Hi @leonberger-m ,
It looks like you have two seperate problems.
Would it be possible to share the Node-RED flow? I am unsure where this memory leak would be originating if you are using the default limited debug logs and aren't creating many local variables.
The error DL_INVALID_ADDRESS is emitted from the subscription nodes if the path that is set in the node configuration or via msg.path doesn't point to an existing datalayer node. Can you try subscribing to some of the system metric nodes and see if the error persists? I don't think this error is an issue with Node-RED and rather with the OPC UA client or the server you are subscribing too. Can you share any more information about the OPC UA client/server setup?
07-01-2024 04:25 PM
Hi @Sgilk ,
thanks for your quick response.
Regarding 1.
Within Node-Red we are using some quite simple parameter mapping flows.
The data is received from OPC-UA source (by subscription) and forwarded to a KVD node.
In all cases the DL_INVALID_ADDRESS appears since the whole data node of the OPC UA source is currently not available (SPS switched off).
I also attached the example to the reply.
Regarding 2.
Yes that's right. The source nodes are currently not available since the OPC-UA server (source) is sometimes not available. Since the IOT CtrlX device runs separately this situation could happen. If I refer to a existing node or the configured OPC-UA server resource is running the error disappears and everything runs fine.
07-02-2024 07:14 AM
Please update node-red-contrib-ctrlx-automation to version 1.9.6 there could be already some solution be included. See Connect real ctrlX CORE via proxy to the Internet.
07-03-2024 02:20 PM
Hello,
we have updated the node-red-contrib-ctrlx-automation to the current available version 1.9.6.
After that we have reset the parameters back to "default" to verify what happens.
In case the data layer node is not available (e.g. machine is powered off) the DL_INVALID_ADDRESS messages are created quite often.
But it seems that the logfile is not flooded completely even if we are using the "default values".
So we are going to monitor this issue to verfiy after some hours of runtime that the memory does not increase more and more for the node-red app. The current memory usage is shown in the picture:
Regards,
Markus
07-04-2024 08:04 AM
Hello @CodeShepherd
it really seems that version 1.9.6 fixes the node-red subscpription issue since the memory doesn't increase any more even if the default values for the subscription node timings are used. That's great!
But this morning the memory issue is still present since the KVD allocates the whole memory.
So only a restart helps to avoid running into the memory issue (yellow led, no response from core).
Could you please take a look into the system report we generated yesterday to verify what is going wrong with the key value database?
Therefore I opened up another forum topic.
Key Value Database (KVD) full memory allocation - Bosch Shared (boschrexroth.com)
Thanks and regards.