Main paradox -Calling Main from a Subroutine in RAPID – How Long Can It Run?

    Hello everyone,

    I recently came across an interesting RAPID program where MAIN is called from a subroutine, which made me curious about how long this approach can run. In the usual structure, a robot completes a subroutine and returns to the routine that originally called it. But in this example, it seems like the subroutine rountine1 calls MAIN again, creating a sort of loop between the two routines. Here’s a simplified version of the code I saw:

    PROC Main()
      WaitTime 0.5;
      rountine1;
    ENDPROC

    PROC rountine1()
      WaitTime 0.5;
      Main;
    ENDPROC

    My main questions are:

    1. Is this a valid approach in RAPID? I wonder if continuously calling MAIN from rountine1 could lead to stack overflow or memory issues over time.
    2. Will the robot “remember” to start from MAIN after hours of running this loop? In other words, how does the robot manage memory and subroutine calls over an extended period?

    Would love to hear any insights or experiences on this topic! Thanks in advance.

    Wow, yeah, that's... bad programming. Unless there's some outside signal forcing an abort-to-main or something similar.

    It would be easy to duplicate this scenario and find out how deep the call stack goes. Just create two PROCs like that which contain nothing but the calls to each other. Add an Integer variable that gets incremented every call. Then run it, and see what the integer ends up as (obviously you'll need to ensure it's 0 before starting, and declare statically in the Module level variables).

    Worked on a program where an engineer set up recursive calling of main in an error handler of an IRC5 controller. It worked initially, but after around a dozen uses it would have an overflow error that just needed pptomain to be performed manually to clear. Solved this problem by using the ExitCycle command in the error handler instead. I wonder if the amount of commands in the program has a large effect on the number of times it can recursively call?

    Quote from bull_boxer454

    I wonder if the amount of commands in the program has a large effect on the number of times it can recursively call?

    I can't speak specifically to how ABB handles it. But in the general cases I'm aware of, the program size is generally irrelevant. It's the stack size that is the limiting factor, and that's generally hard-coded to a specific number of programs, regardless of program size.

    On KUKAbots, for example, the stack size these days is 15 IIRC. So the call stack can only be 15 programs deep. Doesn't matter if it's recursive A->B->A->B, or Program 1 calling Program 2 calling... down to 15. Any execution thread can only store "backtrack" information for X programs.

Advertising from our partners