Hello,
I'm running Raspi 3.5.16.0 SL multicore with OPC-UA server functionality enabled. The image is equipped with preempt patch and fulfills all requirements for 2ms prio-task cycle time (jitter max 300 µs).
I defined 2 task groups, see picture attached. Hoping the OPC-UA functionality gets assigned to my Non-RT-Tasks group.
However, when an OPC-UA-client connects to my server, Max-Jitter explodes up to 5 ms. I suppose the OPC-server runs in also my IEC-Tasks group. How can i check or define the task, that executes my OPC-UA server?
In this document (https://www.codesys.com/news-events/publications/article/with-the-power-of-many-cores-codesys-multicore-on-a-welding-system.html) you are talking of implicit generated tasks. For VISU_TASK this happens in my project. For OPC-UA I can't find any info.
additional info: same problem with codesys 3.5.16.30 and raspi sl mc 4.0.0.0
Not only Jitter is affected, but the whole max task cycle time increases from 600 µs to 12 ms with the latest version.
the problem occurs when adding/browsing a large (>1 MB) structure with ua-expert.
I'm not surprised by the increase of the cycle time, I'm just wondering why it affects my highest-prio IEC-Tasks, while the system is running multicore and opc-ua should be using a different core.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With SP16 there was multicore introduced for OPC UA. By default it works across all cores.
You can limit the number of cores it uses with this setting in the CODESYSControl_User.cfg file, where 1 is the number of cores you want to use. Setting it to 0 or less will use all available cores:
[OPCUAServer]NumOfWorkerTasks=1
I am not 100% sure though, which core it will run in.
Are you using an RT-preempt patch? Normally the lower priority OPC UA task should be interrupted. It is possible though, that some semaphore is used so that while it reads a function block, it cannot be interrupted. You will have to test this.
There is a setting if you right click the Device > Properties > Options. Called "Access variables in sync with IEC Tasks". If ticked, the OPC UA stuff waits for a time when no IEC tasks are running, and then does its thing. It doesn't let the IEC tasks run until it is finished. The setting has a big warning about jitter on it, so check what it's value is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I'm running Raspi 3.5.16.0 SL multicore with OPC-UA server functionality enabled. The image is equipped with preempt patch and fulfills all requirements for 2ms prio-task cycle time (jitter max 300 µs).
I defined 2 task groups, see picture attached. Hoping the OPC-UA functionality gets assigned to my Non-RT-Tasks group.
However, when an OPC-UA-client connects to my server, Max-Jitter explodes up to 5 ms. I suppose the OPC-server runs in also my IEC-Tasks group. How can i check or define the task, that executes my OPC-UA server?
In this document (https://www.codesys.com/news-events/publications/article/with-the-power-of-many-cores-codesys-multicore-on-a-welding-system.html) you are talking of implicit generated tasks. For VISU_TASK this happens in my project. For OPC-UA I can't find any info.
Last edit: SEW1 2020-12-09
additional info: same problem with codesys 3.5.16.30 and raspi sl mc 4.0.0.0
Not only Jitter is affected, but the whole max task cycle time increases from 600 µs to 12 ms with the latest version.
the problem occurs when adding/browsing a large (>1 MB) structure with ua-expert.
I'm not surprised by the increase of the cycle time, I'm just wondering why it affects my highest-prio IEC-Tasks, while the system is running multicore and opc-ua should be using a different core.
You can limit the number of cores it uses with this setting in the CODESYSControl_User.cfg file, where 1 is the number of cores you want to use. Setting it to 0 or less will use all available cores:
I am not 100% sure though, which core it will run in.
Are you using an RT-preempt patch? Normally the lower priority OPC UA task should be interrupted. It is possible though, that some semaphore is used so that while it reads a function block, it cannot be interrupted. You will have to test this.
There is a setting if you right click the Device > Properties > Options. Called "Access variables in sync with IEC Tasks". If ticked, the OPC UA stuff waits for a time when no IEC tasks are running, and then does its thing. It doesn't let the IEC tasks run until it is finished. The setting has a big warning about jitter on it, so check what it's value is.