Cyclic flag usage with WAIT FOR instruction

    • New

    Hi there, I'm quite new with kuka programming, forgive me if I'm asking for too simple issue.
    I'm having trouble understanding an approach to a Cyclic Flag and WAITFOR instruction in offline program I'm reworking.

    Is there any possible reason programmers keep using $IN instead of just assigned $CYCFLAG in WAITFOR/IF statements?
    Compare those two parts of the code, would the second one work identical?

    Code
    (...)
;$IN[97] = TRUE - (Release to work area)
$CYCFLAG[2]=$IN[97]

WAIT FOR  ( $IN[97] OR $TIMER_FLAG[1] ) 

IF ($IN[97]==TRUE) THEN
  GOTO LblEnd
ENDIF
(...)
    Code
    (...)
;$IN[97] = TRUE - (Release to work area)
$CYCFLAG[2]=$IN[97]

WAIT FOR  ( $CYCFLAG[2] OR $TIMER_FLAG[1] ) 

IF ($CYCFLAG[2]) THEN
 GOTO LblEnd
ENDIF
(...)

  • MOM May 10, 2025 at 1:43 PM

    Approved the thread.
    • New

    IIRC, the message would be different, but the effect should be the same. This is, the message would say "Waiting for $CYCFLAG[2]" instead of $IN[97].

    $CYCFLAG[2]=$IN[97]
    WAIT FOR ( $IN[97] OR $TIMER_FLAG[1] )
    WAIT FOR ( $CYCFLAG[2] OR $TIMER_FLAG[1] )

    Generally no one bothers with $CYCFLAGs because there's nothing really to be gained from using them, outside of certain specific situations. The first one I can thing of is Interrupts -- Interrupts do not support Boolean Algebra, so if you want an Interrupt to trigger on a complex signal combination, using something like $CYCFLAG[1]=($IN[1] AND ($IN[2] OR NOT $IN[3]) AND ($IN[4] EXOR $IN[5]), you can do that and then have the Interrupt triggerd by the $CYCFLAG.

    The automatically generated WAIT FOR messages are convenient, but simplistic. When I got into complex wait situations, I got into the habit of simply using a REPEAT loop with my own Status message, and erasing the message upon the Loop exit.

Advertising from our partners