We are planning to implement a delay in the hand feeback shown on the kinarm screen.
I am trying to add a variable transport delay block after the hand feedback block before it is fed to the Procees_video_cmd block.
The amount of time delay should be given to this variable transport delay block and it is mentioned in the trial protocol table for each trial.
But, i am getting the following error and the task automatically cuts off in the middle of execution.
Kindly advise on how to resolve this issue.
“The following error was encountered while connected to the KINARM robots:
The CPU has overloaded on the robot computer. This means your task took too long to perform its work. You may need to find ways to reduce operations per cycle.
Log files will contain more information. Please contact email@example.com for help.”
Also, i would like to add one extra information about the error.
This error occurs only when i try using a variable delay where the amount of time that needs to be delayed is given in the trial protocol block.
When i try using a fixed time delay block where the amount of time delay is mentioned in the simulink itself, this error does not occur. please advise.
It means that your model could not be executed in a single time step. The duration in a time step is either 500 us if using MATLAB R2013a or earlier. If using MATLAB R2015aSP1, a time step is 250 us.
The way to diagnose a CPU overload is to look at the output coming from the Robot Computer (where the model is running). You may have a 2nd screen connected to that computer but if you do not, you will be able to switch the computer monitor to output the Robot Computer by pressing Scroll Lock twice. You can press Scroll Lock twice to switch back to the Dexterit-E Computer Windows screen.
By default, the screen will show the average TET (Task Execution Time – it is the time that your model spends executing for each time step). When the TET is longer than a time step, the CPU overload error is thrown.
You can see the instantaneous TET by using the TET block and connecting it to a xPC/SLRT scope and then viewing it on the Robot Computer screen.
You should check what the TET is when you run with the fixed time delay block. It could be the task already has a high TET and what other calculations you are asking to do are pushing it over the edge. Or maybe the code addition itself has a long computation time and could be made more efficient.
Common things that can cause you to have high TET:
-a lot of channels that interface with hardware (for example, if outputting a lot of analog outputs to a neural recording system)
-operations on large matrices (anything with a 1000+ elements could be problematic)
It is important to realize that Simulink Real-Time models don’t have the vector computing that you may be used in MATLAB. The model is converted to C code before it is compiled and so something innocuous like
ones(1,100) + 5
will involve a for loop with 100 iterations because that is the only way C knows to add 5 to 100 individual memory locations.
Handy ways to reduce TET:
-switch from R2013a and earlier to R2015aSP or later version that we will support in the future. It seems counter intuitive because R2015aSP1 has a smaller time step but it will use more than a single CPU core to execute the model
-you can change the sample time on a block or subsystem so it can execute slower than the rest of the model. For example, if you have some complicated calculations to do with visuals, you may be okay with running slower than 2 kHz or 4 kHz because the subject display itself is only refreshing at 60 Hz. You can change the sample time by right clicking a block/subsystem and selecting Block Parameters and changing the value in Sample Time (the default is usually -1, which means same as the model)
-changing from Row Major to Column Major vector indexing. This is a bit esoteric but you get more efficient compiled code if you use column vectors instead of row vectors
These are the general pointers about dealing with CPU overload. Let me know if that helps you out.