BGLOGIC code that I have found useful

  • So, I've only been using BGLOGIC for a couple months now. In my opinion, this is something that FANUC should teach in their advanced TPP class, because it's extremely useful. If it wasn't for the suggestion of somebody here, I never would have discovered this feature on my own. I guess they expect people to read their manual cover to cover, but there isn't enough coffee in the world to keep me awake if I tried that. I've managed to take a lot of heat off of our PLC programmer, and I've already developed a few routines that I've found almost universally useful.

    So as a way of saying thanks, here are a couple code snippets I thought I'd share.

    One shots are used when you only want something to happen for one scan of the program. This can be used to replace macros that are triggered by inputs. Why would you want to do that? Well, input macros don't work in T1 or T2.

    One Shot Method A
    IF (DI[1] AND !F[2]),F[1]=(ON)
    Now F[1] can be used at any point to test for a one shot condition before the end of the BG program

    One Shot Method B
    IF (DI[1] AND !F[1]),...
    (Repeat above IF instruction when needed before next line)

    One Shot Output Toggle
    This is handy for using a single input (like a push button or sensor) to toggle an output on and off
    IF (DI[1] AND !F[1]),DO[1]=(!DO[1])

    Output Strobe
    We put three color stack lights on our controllers, and I use this routine to make the yellow light flash when I turn on F[1]
    IF (F[1] AND !F[3]),F[2]=PULSE,0.2sec
    IF (F[1] AND !F[2]),F[3]=PULSE,0.2sec
    IF (!F[1]),F[2]=(OFF)
    IF (!F[1]),F[3]=(OFF)

    If anybody wants to add, feel free!

  • Place your Ad here!
  • I work with fanuc M410 ib and i can´t do this instruction with ROBOGUIDE soft where can i download or buy the BGLOGIC?
    And if you can showme pictures that it makes useful with a simulation it will be cool.


  • i use back ground logic alot ansd i dont think you would be able to do it with roboguide because it is mixed logic, (non motion). but then again i have never used roboguide i do all of my programming at the TP. I found it very useful to take the place of karel which i hate!!! soo much easier just to open up your BGlogic progrqam and edit it right there at the TP instead of having to compile and recompile... ect

    Edited once, last by robodog ().

  • ho flat can you clearly explain i am little bit confused about this logic..... :waffen100: thanks in advance :icon_smile:

  • Background Logic programs are scan routine programs that constantly run in the background. They are executed one line at a time, from start to finish, repeatedly. If you know anything about PLC programming, they are very similar to the way those programs are structured and run. You can only use assignment statements in background logic programs. This means that you can not use motion instructions, branching statements (jump, label, call, run, etc...), timers, WAIT instructions or macros.

    So basically you are limited to setting registers, I/O and system variables. And the only conditional statement you can use is the mixed logic IF statement: IF (...)

    All of this is to keep the program simple so that it can be executed quickly. In my experience, if you're dealing with less than 16 inputs and 16 outputs, background logic is a good way to avoid using a PLC in the workcell if you don't have to. Anything more than that would probably be better suited to either the PMC option or a PLC. For me, the primary way I use it is to set up run conditions that must be met before the robot can be operated in automatic.

    A "one shot" is probably the most valuable tool you can use when doing this sort of programming. Remember that this program is repeatedly scanning (looping) in the background. We use a one shot to make something happen for only one scan. For example, let's say we have a button connected to an input (DI[1]). Every time we push the button, we want to add 1 to the value of a register (R[1]).

    IF (DI[1), R[1]=R[1]+1

    The problem with this code though is that the program is repeating every 8ms. Unless you have very quick hands, it's likely that the button will be held down for more than one scan of the program, resulting in more than 1 being added the the register. So to fix it, we have to use a one shot:

    IF (DI[1] AND !F[2]),F[1]=(ON)
    IF (F[1]), R[1]=R[1]+1

    And here's how it works scan by scan:

    First scan with DI[1] on:
    F[1]=(OFF) ;We always turn this flag off at the start of the cycle
    IF (DI[1] AND !F[2]),F[1]=(ON) ;If DI[1] is on, and F[2] is off, we want to turn F[1] on
    F[2]=(DI[1]) ;Now we want to set F[2] to the same state as DI[1]. This means that on the next "scan", the condition in the previous line will not be met.
    IF (F[1]), R[1]=R[1]+1 ;If we've gotten this far, and we see that F[1] is on, that means we know it's the first scan where we've seen DI[1] on

    Second scan with DI[1] on:
    F[1]=(OFF) ;Again, this flag gets turned off to avoid repeating any of those assignments again
    IF (DI[1] AND !F[2]),F[1]=(ON) ;This time around F[2] is on, so this condition is not met, and F[1] stays off
    F[2]=(DI[1]) ;This holds F[2] on until we see DI[1] turn off.
    IF (F[1]), R[1]=R[1]+1 ;This line will not execute

    First scan with DI[1] off:
    IF (DI[1] AND !F[2]),F[1]=(ON) ;DI[1] is off, and F[2] is still on from the last cycle. Condition still not met.
    F[2]=(DI[1]) ;Now F[2] is turned off. The next time DI[1] comes on, the above condition will be met again.
    IF (F[1]), R[1]=R[1]+1

    Basically it all comes down to order of execution. If you put things in the right order, you can do practically anything. Earlier I said that I prefer to use BG Logic with less than 16 inputs and outputs, but I have used it as a cell controller on a system that had 32 inputs and 48 outputs. It controlled everything from the notification lights, an exit conveyor, a couple of pneumatic cylinders, a small printer and another robot. All with background logic. I would have preferred a PLC or even just the PMC option, but the customer beat us up on price and the budget didn't allow it.

    Here's a chunk of code from one of the four BG Logic programs running on that system that uses all sorts of one shots and cascading logic:

    This code basically triggers a printer to print a label, cut the label with a shear, move the cut label with a small slide so that the robot can pick it, and tells the robot that there's a label present. Once the robot picks it, it turns off the label present flag which starts the print cycle again automatically. All of this happens in under a second while the robot is off applying the label. It also has allowances for a manual push button trigger so that the printer can be set up and tested in a maintenance mode. This is the primary reason I used BG Logic instead of a macro. Because BG Logic runs all the time, whether the robot is paused, in automatic, or in teach mode. This means maintenance personnel don't need to mess with the teach pendant as much. From a support standpoint, I prefer that whenever possible.

    Like I said, you can do anything with it.

  • Hello Flatcurve,

    I read your post and really interesting to use it on one of our application. However, i'm having couple of questions. Hope you can guide me through this process.

    1. Is BG Logic written in the TP program?
    2. I would like to accomplish the logic below, could you help with the code how it should be written?

    If input 1 OFF and input 2 OFF don't do anything
    If Input 1 ON and Input 2 OFF then turn on output 1 for 500 milisecond
    If input 1 Off and input 2 On then ouput 1 stay off.
    (They are all Digital I/O)

    Thanks in advance for your help.
    Thank you,

  • Hi Robo1,

    You can setup BGLOGIC from Menu -> Setup -> BGLOGIC where you can choose your BGLOGIC program.

    To accomplish the logic you need:
    IF (DI[1] AND !DI[2]),DO[1]=PULSE,0.5sec. Put this in a TP program and add it's name in setup menu.

  • This will allow you to toggle a digital output from a DCS CPC zone without using safe I/O. obviously by using a single channel output, it is no longer a safety signal but it is useful for protecting equipment.

    : IF ($DCSS_PSTAT.$STATUS_CPC[1]=0),DO[1:Clear Transfer DCS]=(ON) ;
    : IF ($DCSS_PSTAT.$STATUS_CPC[1]=1),DO[1:Clear Transfer DCS]=(OFF) ;

    This will monitor if someone has jogged the robot. i use it for auto recovery. The bit can be cleared by moving to a point in a program, ether in auto or T1.

    : DO[1:Robot Jogged]=($MOR_GRP[1].$JOGGED) ;

  • Very useful post

    I wish to create a user alarm when a certain DI gets on but I am not able to write User alarm in BG logic as I am getting syntax error .
    Please help me guys I am a newbie and wish to learn

    Thanks in advance !!!!! :help:

  • The most simple way to generate one shot is using the PULSE instruction with no time specified.
    In BG Logic, this generates a single scan pulse.
    Note, that in normal (non background) execution this will generate a pulse of default $DEFPULSE duration.

  • The most simple way to generate one shot is using the PULSE instruction with no time specified.
    In BG Logic, this generates a single scan pulse.
    Note, that in normal (non background) execution this will generate a pulse of default $DEFPULSE duration.

    also note that the PULSE command does not work in FAST mode (guaranteed 8msec scan time) so if you need edge detection in a fast bg program, you gotta do it like this:

    F[1]=(DI[1] AND !F[2])

  • Automatically disable/enable UOP when TP is On/Off:
    The instruction must be created as Registers ...=(...), not as Miscellaneous>Parameter Name.
    The background program must be set (in its Detail) to ignore pause conditions.

  • As we're talking about scan time for BGLOGIC program - how fast does BGLOGIC for R-30iB work? I'd like to implement a control system for a simple palletizing application using only BGLOGIC (instead of PMC) and I'm afraid that if the program is too long and complex, there may be situations when i. e. a pulsed signal from a sensor is omitted.

    I see that it's possible to set the scan time for 8msec, but - if I understand correctly - this limits functionality of BGLOGIC, so I'd like to use standard mode...

  • Scan time is still 8msec (12msec on mate controllers) but the amount of items processed per ITP greatly increased in v8 of HandlingTool. (540 vs. 300) An item is data, an operator or an instruction. So the following is a 3 item statement:


    Item 1: F[1]
    Item 2: =
    Item 3: (DI[1])

    My general rule of thumb is to use a PLC if I have more than 32 outputs to control. Obviously there's also considerations for what those outputs are doing. But if you think you might have pulsed inputs shorter than your scan time (x2), you should just use a PLC regardless.

  • Tell if a bit is set in a positive integer value:
    Example: test 4th bit: 2^(4-1)=8

    F[1]=((R[1] DIV 8 MOD 2)>0)

    Example: test 5th bit: 2^(5-1)=16

    F[1]=((R[1] DIV 16 MOD 2)>0)

    To test

    Single-instruction timer:
    125 is for 1 Second ,because 8ms = 1/125 of a second. Test it against your BGLOGIC scan speed.

    R[1]=((R[1]+1)  MOD 125 );
     IF (R[1]=0), stuff to do each interval ;

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

Advertising from our partners