IRC5 command execution speed

memphiss

   Does there is some where in RAPID manual or somebody knows the execution speed of RAPID non-movement command for IRC5? For example, how many minisecond it takes IRC5 to finish command "set di_01,1;", how many minisecond for "TDisplay 'test screen display'",...etc

    My reason is, for IRC5, we can define robot speed, no problem. But for main program flow chart, if we have many condition selections like IF-ELSE-END IF but condition never meets: does it make sense that we can comment these lines so that to save cycle time?

 

memphiss

   My start point is I met with frequent alarm " 40231    Too high CPU load ", also communications with PLC seems slow. So I would like to reduce too many TDsiplay, too many not useful IF selection, and other others...

   Will it helps? 

aNoRSWE

Hi,

I'm not sure about the specifics, but in general I don't think commenting "IF-ELSE" statements will do any good, these are simple boolesc evaluations. However, you may have other kinds of code that can be optimized, like loops and heavy stringoperations, especially if you have several parallell tasks doing these things.

One thing however that may give high cpu-load, is if the main loop in any of the tasks executes "empty" without actually doing anything (i.e when no conditions are met). In this case, you should have a "WaitTime 0.1" or similar statement, or this can give you problems.

Magnus Larsson

The problem with non-waiting RAPID instructions, e.g., logical instructions, I/O set operations etc, is that if you have a lot of them, especially in loops, they would take up all available CPU time and prevent lower priority os-tasks from running. For example the os-tasks that handle the communication with external devices like the FlexPendant and PC's.

To prevent that, there is an automatic mechanism that slows the RAPID execution down if necessary. It is this mechanism that issues the "Too High CPU load" warning if it has to engage above a certain level (the warning is rephrased to "High program execution load" in coming releases). The breaking is very moderate, so the lower priority tasks may take a performance hit anyway.

The non-waiting instructions or the automatic breaking shall in general not affect the cycle time since the motion performance is not affected, unless you start getting "Corner Path Failure" or other Motion warnings/errors.

However, if you for example have a RAPID backround task that does unnecessary stuff like looping empty or checking conditions with high frequency, it will affect performance of your other RAPID tasks since they are slowed down also. 

By using, e.g., the WaitXX-instructions or interrupts instead of looping, or inserting "WaitTime 0.1;" or similar (where suitable for your application), your RAPID program "yields" execution time better used elsewhere.