FANUC programming, Sensor stutter problem

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.

I would assume you would just pick an unused Register, and dedicate it for use as a counter.

WAIT command in a BGL program should only affect that BGL.

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.

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.

Yes, or to look at it the other way around, each second will increase your register value by 125.

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:

/PROG  TEST_BG_TMR

   1:  R[1:DO[1] TMR]=0    ;
   2:  R[2:DO[2] TMR]=0    ;
   3:  R[3:DO[3] TMR]=0    ;
   4:   ;
   5:  DO[1]=ON ;
   6:  WAIT   1.00(sec) ;
   7:  DO[1]=OFF ;
   8:   ;
   9:  DO[2]=ON ;
  10:  WAIT   2.00(sec) ;
  11:  DO[2]=OFF ;
  12:   ;
  13:  DO[3]=ON ;
  14:  WAIT   4.00(sec) ;
  15:  DO[3]=OFF ;
  16:   ;

BG Logic:

   1:  IF (DO[1]) THEN ;
   2:  R[1:DO[1] TMR]=R[1:DO[1] TMR]+1    ;
   3:  ENDIF ;
   4:   ;
   5:  IF (DO[2]) THEN ;
   6:  R[2:DO[2] TMR]=R[2:DO[2] TMR]+1    ;
   7:  ENDIF ;
   8:   ;
   9:  IF (DO[3]) THEN ;
  10:  R[3:DO[3] TMR]=R[3:DO[3] TMR]+1    ;
  11:  ENDIF ;

Result:

Quote from pdl

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.

Quote from pdl

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:

Code

/PROG  TEST_BG_TMR

   1:  R[1:DO[1] TMR]=0    ;
   2:  R[2:DO[2] TMR]=0    ;
   3:  R[3:DO[3] TMR]=0    ;
   4:   ;
   5:  DO[1]=ON ;
   6:  WAIT   1.00(sec) ;
   7:  DO[1]=OFF ;
   8:   ;
   9:  DO[2]=ON ;
  10:  WAIT   2.00(sec) ;
  11:  DO[2]=OFF ;
  12:   ;
  13:  DO[3]=ON ;
  14:  WAIT   4.00(sec) ;
  15:  DO[3]=OFF ;
  16:   ;

Display More

BG Logic:

Code

   1:  IF (DO[1]) THEN ;
   2:  R[1:DO[1] TMR]=R[1:DO[1] TMR]+1    ;
   3:  ENDIF ;
   4:   ;
   5:  IF (DO[2]) THEN ;
   6:  R[2:DO[2] TMR]=R[2:DO[2] TMR]+1    ;
   7:  ENDIF ;
   8:   ;
   9:  IF (DO[3]) THEN ;
  10:  R[3:DO[3] TMR]=R[3:DO[3] TMR]+1    ;
  11:  ENDIF ;

Display More

Result:

Display More

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.

You can delete lines 6-9, they don't do anything. Otherwise looks good!

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