The function block GETCURTASKINDEX determines the task index of the task in which it is currently called.
To differentiate whether the current call occurs in the real-time context or from a cyclic PLC task, see the documentation for the GETCURTASKINDEXEX function. For example, the automatic call of FB_init methods during initialization does not occur from a cyclic PLC task.
I never asked myself how many tasks CODESYS can handle in parallel. I am sure the ammount of tasks is hardware dependent and thus platform dependent. Our function therefore must return a BYTE which therefore can contain MORE then [1,2,3 or 4] because CODESYS can probably hit up to 100 tasks!!!! (maybe even more!) depending on the hardware. Anyway, the code should return the CURRENT TASK INDEX as BYTE.
A trick would be to see if there is some struct available which holds this exact info.
Another trick would be to rotate tasks, asking in a ring for every next task and figure out if we are running like 1,2,3,4 or even more tasks by housekeeping of several counters.
Maybe even a simpler solution to this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A good trick would be to ask for all tasks their info (Task_Info) and then count the ammount of Tasks and return the index of our current task in relation to all tasks.
I am testing this concept now with 8 separate tasks in a single controller
RPi 3B+ supports 100 Tasks.
Control WIn Supports 100 Tasks.
Any other hardware supports probably less then 100 Tasks
The ringbuffer should therfore be 100 or less
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We should study the context "WHY" we should return this GetCurTaskIndex in the original sorcecode. Maybe that will provide more clue's on the original problem instead of carbon copy the function.
Original code FB_TestSuite suggests we need search the currenttask for duplicate tests.
In the original TwinCAT3 code, some implicit structures are initialised by the following code;
GetCurrentTaskIndex(); // Gets the task index of where this function block instance is being run in 67 68 (* Check if the test name already exists. Make sure there are no other tests with the same name already 69 added for this test suite *) 70 71 CycleCount := TwinCAT_SystemInfoVarList._TaskInfo[GetCurrentTaskIndex.index].CycleCount;
Ergo => We have a handle to our OWN task via the following simple code which contains the cyclecount, etc etc as a replacement for _TaskInfo
VAR pOwnTask : RTS_IEC_HANDLE := 0; pResult : RTS_IEC_HANDLE := 0; pOwnTaskInfo : POINTER TO CmpIecTask.Task_Info2;END_VAR
Maybe a solution via system library "CmpIecTask"
Yes:
https://help.codesys.com/webapp/IecTaskGetCurrent;product=CmpIecTask;version=3.5.9.0
You can use than IecTaskGetDesc() to get information about the task and to get the pointer to application where the task is running.
I never asked myself how many tasks CODESYS can handle in parallel. I am sure the ammount of tasks is hardware dependent and thus platform dependent. Our function therefore must return a BYTE which therefore can contain MORE then [1,2,3 or 4] because CODESYS can probably hit up to 100 tasks!!!! (maybe even more!) depending on the hardware. Anyway, the code should return the CURRENT TASK INDEX as BYTE.
A trick would be to see if there is some struct available which holds this exact info.
Another trick would be to rotate tasks, asking in a ring for every next task and figure out if we are running like 1,2,3,4 or even more tasks by housekeeping of several counters.
Maybe even a simpler solution to this?
A good trick would be to ask for all tasks their info (Task_Info) and then count the ammount of Tasks and return the index of our current task in relation to all tasks.
I am testing this concept now with 8 separate tasks in a single controller
RPi 3B+ supports 100 Tasks.
Control WIn Supports 100 Tasks.
Any other hardware supports probably less then 100 Tasks
The ringbuffer should therfore be 100 or less
Why not use a list to save all the Task_Info.
https://help.codesys.com/webapp/PLNKp05jt2j8jYyFvPtWuGse7Qc%2FList;product=ElementCollections;version=3.5.14.0
We should study the context "WHY" we should return this GetCurTaskIndex in the original sorcecode. Maybe that will provide more clue's on the original problem instead of carbon copy the function.
Original code FB_TestSuite suggests we need search the currenttask for duplicate tests.
In the original TwinCAT3 code, some implicit structures are initialised by the following code;
Ergo => We have a handle to our OWN task via the following simple code which contains the cyclecount, etc etc as a replacement for _TaskInfo
With the following code;
After some codereviewing I see that we have to provide a cyclecount..
I have a solution for this but I am not entirely satisfied with it as I had to "hack" it in via a cyclical call so this needs some optimisation.