FANUC programming, Sensor stutter problem

  • Hello everybody,

    our handling system has a vacuum gripper with 2 sensors to check if the part fell accidentally from the gripper.

    Currently i am checking these sensors with a monitor program.

    -> Monitor Program CHECK_PART:

    1: WHEN RI[3] = Off OR RI[4] = Off, CALL PART_LOST

    2: END

    -> PART_LOST Program:

    1: UALM[1]

    2: ABORT

    3: END

    Now my problem is following:

    We have very thin and light products which start to shake a bit while the robot is moving through the cell.

    The sensor starts to stutter a bit ON/OFF...

    Is it possible to give the monitor program a condition that the RI[3] or RI[4] have to be off for a minimum period of time?

    Or does anyone else have a better solution for this?

    Is there something like a timer i can activate for example 0.3 seconds and after this period of time i can set an output?

    We already tried to fix this problem by changing the sensors but it doesnt work...

    I would appreciate any help.

    Thanks in advance and Greetings


  • I think that the Condition program used by a Monitor can only be a basic comparison. So I don't think you make the condition have a minimum period of time.

    You could use Background Logic to increment a counter when RI[3] = OFF. If the RI comes back on, reset the counter. If the counter reaches a threshold then turn on a FLAG.

    Your Condition Program for your Monitor can watch for the FLAG.

  • ok but would i do it like this?:


    1: FOR R[99]=0 TO 3

    2: WAIT 0.1(sec)

    3: R[99]=R[99]+1

    so i get a 0.3 sec delay?

    Or would the WAIT instruction in my BGL make the robot stop moving for 0.3 sec?

  • Okay so i programmed this, but apparently i cant use a wait command in a BGL.

    What do i do now?

    1: IF (RI[3]=OFF OR RI[4]=OFF) THEN


    3: LBL[1]

    4: WAIT .10(sec)

    5: R[99]=R[99]+1

    6: IF (RI[3]=ON AND RI[4]=ON) THEN

    7: JMP LBL[2]

    8: ENDIF


    10: IF (R[99]=3) THEN

    11: F[1]=(ON)

    12: JMP LBL[3]

    13: ENDIF


    15: JMP LBL[1]


    17: LBL[2]

    18: F[1]=(OFF)

    19: R[99]=0

    20: ENDIF


    22: LBL[3]

    23: R[99]=0


  • Yeah, you have to re-think the logic to put it in a Background program.

    For example:

    !Increment counter if either input is OFF

    IF (DI[103]=OFF OR DI[104 ]=OFF),R[99]=(R[99]+1) ;

    !If both inputs are ON, reset the counter

    IF (DI[103]=ON AND DI[104 ]=ON),R[99]=(0) ;

    !If both inputs are ON, reset the FLAG

    IF (DI[103]=ON AND DI[104 ]=ON),F[55]=(OFF) ;

    !If the counter exceeds a threshold, turn on the FLAG

    IF (R[99]>100),F[55]=(ON) ;

    You would need to set the counter threshold to a value that works for your application. The counter will increment on each BG_Logic scan which is usually every 8 milliseconds.

    Also, you may be able to use an IF THEN in BG_Logic, but I'm not sure it is available in all software versions.

  • I just tested this in RoboGuide, it looks like the RoboGuide BG Logic in Fast mode cycles at 4 mSec. I.E. 1 second equals a register increment of 250. This was on an R-30iB+ virtual controller which makes sense, as one of the biggest changes to the "plus" controller was dropping the ITP to 4 mSec.

    You'll want to test this on the actual controller for real world numbers.

    TP Code:

    BG Logic:


  • Take in mind that BG logic in fast mode will run at a constant 8ms loop and your problem of no timers in BG will solve itself.

    Be a bit careful with this, after playing around with loops, JMP\LBLs, and condition statements it appears the scan rate of both the HIGH and Normal priority BG logic programs is variable based on execution time. Fanuc will set the scan rate to an interval greater than the total execution time of all BGLOGIC programs, and it appears to keep all BGLOGIC programs at the same scan rate, but it can and will change the scan rate during runtime.

    I was able to get the scan rate to vary from 8msec up to 120ms by changing the state of a flag, and executing more logic (400 lines increasing a register by 1) whenever the flag was true.

    If all you plan on using it for is a sensor debounce then this shouldn't really matter much however, in a time-sensitive process, I wouldn't count on the scan rate to remain constant if there is any conditional branching in my BG logic.

  • For your situation it shouldn't really be a problem. If you do ever need a scan independent timer, you can use $FASTCLOCK. I believe it ticks every 2ms.

    i will keep that in mind.

    Here is my Code which seems to work:

    I check DO45 in my Monitor Program.

    1: IF (RI[3]=OFF OR RI[4]=OFF) THEN



    4: R[99]=R[99]+1


    6: IF (RI[3]=ON AND RI[4]=ON) THEN

    7: R[99]=0

    8: DO[45:PartLost]=(OFF)

    9: ENDIF


    11: IF (R[99]>=150) THEN

    12: DO[45:PartLost]=(ON)

    13: R[99]=0

    14: ENDIF

    15: ELSE

    16: DO[45:PartLost]=(OFF)

    17: R[99]=0

    18: ENDIF



  • I would just debounce the signal. Since if the signal is good then any previous off signal can be ignored.

    IF RI[3] = OFF , R[99] = R[99] + 1

    IF RI[4] = OFF , R[99] = R[99] + 1

    IF RI[3] =ON AND RI[4] = ON , R[99] = 0

    IF R[99] = 50 , CALL PART_LOST

  • oh well yeah that looks easier.

    Anyways both works i guess.

    Thank you

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now