How to Run a Background Input Checker Program?

    Good morning,


    I have a R30iA Fanuc Controller with a main routine running 24/7. Recently, we have added a new machine to the cell, so this machine is outputting a "cycle complete" signal; however, it is not latched in the machine program. I need to look at this input in order for the robot to know when to enter the machine and pick the part.


    I need directions on how to latch this input through the robot teach pendant program; So for example, whenever that cycle complete signal comes on, I want the robot to latch this bit internally, and then at the start of the routine, it will reset that latched bit.


    Thanks,

    Currently looking through three different choices: BG Logic, Flags, and Data Registers. I feel a few of these options may help me with the task at hand, but I'm doing more research on these right now.

    Use a BG logic program to turn on a Flag if the input is on. The BG Logic will always be running in the background, even after a power cycle. Your regular TP program can turn the flag back off at the start of the routine.

    Yes, now I am using BG Logic, but I'm getting a intp-443. The website says "There is an operator or data that cannot be used in Mixed Logic. Mixed Logic statements are those that have parentheses." ??? The only thing I have with parentheses is F[1] = (on). Can I not use "on" ?

    You can't jump up, only down. BG logic programs automatically loop so no need to jump up.


    You don't need to use any jumps at all. Your code can simply be:


    If (DI[17]), F[1]=on
    If (DI[18]), F[2]=on

    Edited once, last by HawkME ().

    HawkME Thanks, is there a guide available for how to code in Boolean? I've studied Boolean Algebra, but the symbols seem different. I could not find any good guides through Google.
    Out of curiosity, can one switch from Boolean to just regular logic inside the BG code as well?

    There's very little difference in the syntax. Each item in parentheses evaluates to True or false, with on=true and off=false.


    You can use any normal operator:
    ! (Not)
    And
    Or
    =
    <> (not equal)
    <
    >


    And you can group logical items in parentheses.


    (DI[1]=on) works the same as simply (DI[1]), you can use either syntax, they both evaluate to True.


    Just forget about jump labels and you will be fine. They can be used to jump downward but even that is unnecessary with the properly written logic.


    Sent from my SM-G930V using Tapatalk

    Quote from alive15


    Yes, now I am using BG Logic, but I'm getting a intp-443. The website says "There is an operator or data that cannot be used in Mixed Logic. Mixed Logic statements are those that have parentheses." ??? The only thing I have with parentheses is F[1] = (on). Can I not use "on" ?



    That error, INTP-443 is referring to the fact that you don't have parenthesis in the IF statement. It is not referring to the Flags.
    I believe your version (or no version so far) permits any IF statement that is not "Mixed Logic" meaning you HAVE to use the parentheses with the IF statement, like:
    IF (DI[17]), F[1]=(ON)
    or something more complex like
    IF (!(DI[17] AND DI[18]) OR (DI[19] AND !DI[20])),JMP LBL[10]
    or
    IF (GI[1]>0 AND !(DI[1] OR DI[2])), DO[1]=ON ;



    So, HawkME's code is the only IF statement syntax that is permissible in a Background Logic program. (Even though regular TP will use either Mixed Logic, or the plain IF DI[17]=ON,JMP LBL[1] )


    Well, the newest systems permit the new IF () THEN ; ELSE ; ENDIF ;, but R30iA wouldn't have that.


    Like HawkME said, Background Logic automatically loops, so you treat it like writing ladder or structured text programs in a PLC. You can have a single IF (logic) statement, and that's all. It will loop as fast as it can, which is 4ms at best, or 8ms by default, I think on newish robots. Not sure if R30iA is that fast, or double those timings. If you have too much code in a program, or maybe certain instructions as well, you will not be able to go to the higher rate.


    The rate matters if you are doing anything complex because the only way to do timing for on-delay or similar is to have a Register act as a counter with a line that increments it every pass through the code. If you know that 250 counts is 1 second, then you can check if the register exceeds your desired timing value. But if the Background Logic rate changes from 4ms to 8ms due to adding code or someone setting the rate to Normal, then your timings will suddenly be twice as long.


    Anyway, there are some gotchas for BG Logic, like non-Mixed Logic IF statements, TIMER, and JMP up, etc.

    - Jay

    HawkME Thanks for all the information, I will definitely use these in the future. The code you gave works with the teach pendant and robot controller in e-stop.


    Jaycephus Thank you for your explanation; I'm only switching on and off one flag through BG logic, checking for a machine ready signal. The robot can wait a few more ms before it's safe and clear to go in.


    Btw, Are you saying the data registers and flags can be used as timers? I didn't know you can do that. How would I figure out the loop rate? Is there an information tab on the teach pendant that automatically updates to tell you the loop rate speed based off the amount of code you have or do you have to make some educated guesses? I am interested to learn more about implementing timers into my robot logic if ever need be.


    Thank you,

    The default (Normal speed) rate might be mentioned at the top of the BG Logic page. Not sure how that looks on a R30iA. It might be 8ms. If so, then 125 counts should, approximately, equal a second. If your timing is actually 16ms, then 63 counts would be about 1 second. Or you might be able to run in High speed mode on a given program like yours, and your timing would be 250 counts per second.


    I use a line like:
    IF(DI[1]),R[1:DwellTimeCnt1]=R[1:DwellTimeCnt1]+1 ; (increment R[1] while DI[1] is on)
    IF (!DI[1:MonitoredInput]),R[1:DwellTimeCnt1]=0 ; (reset R[1] when DI[1] is off)


    Then check for dwell being done:
    IF (R[1:DwellTimeCnt1]>R[2:DwellDuration]),F[1]=(ON) ; (trigger something when dwell or de-bounce is done)


    Then once some event happens, F[1] needs to be reset. The event could be another dwell timer acting as a conveyor-move watchdog timer, or a timer for retracting a pneumatic cylinder that doesn't have a retract sensor, etc. Or DI[1] goes low. Depends on the system.


    IF (<monitored event>),F[1]=(OFF) ;


    Now you can tweak R[2] value on the fly to get your de-bounce timer tweaked in.

    - Jay

    Edited once, last by Jaycephus ().

Advertising from our partners