BG Logic on a R-30iA Controller

    I need your professional input. We run R-30iA, R-30iB & R-30iB+ controllers in house.


    On the R-30iB+ I was able to successfully run a BG Logic that I wrote that essentially prevents our operators from resetting a Collision Detect Alarm. I tried implying this same logic on the R-30iA controller but received a Invalid Mixed Logic error. I've learned that you apparently cannot run UALM's inside BG Logic. With that said, I have below the logic I wrote. I setup Collision Guard to trigger an Output once a Collision has been detected. Once that DO is ON, it will turn on one more DO. I then run an IF statement that checks if the 2nd DO is ON. Our controllers are setup where someone has to be logged in to turn ON or OFF any I/O's. Would anyone have any alternative suggestions as to how I can approach this using a different method? Any help would be greatly appreciated.


    IF (DO[99]=ON), DO [100]=(ON)


    IF (DO[100]=ON), JMP LBL [1]


    JMP LBL [2]
    LBL [1]
    UALM [13]
    LBL [2]

    Use a condition monitor or auto-execute program. There have been other posts on these topics that you can search for on the forum, or read the sections in the manual. I believe the example in the manual shows exactly what you are trying to do using a condition monitor.


    If after that you are still stuck then reply back.


    Sent from my SM-G930V using Tapatalk

    Sergei - I currently run a simple background logic on our R-30-iA's at the moment with no errors. There is no user alarms though.


    HawkME - We have never ran a Monitor Condition before. Forgive me for this brainless question, how would I go about setting this up? I see the option under instruction. When I select it, there is no list available. Don't make fun of me too much for not knowing this :beerchug:

    If you have a PLC working with the robot then I would actually just have the PLC drop the hold signal. But if you need a robot only solution then you can read my response below.


    If you want this to run all the time then you can use a Type 2 System monitor. You have to enable this setting this system variable $TPP_MON.$global_mt=2. The system monitor runs in the background similar to a BG Logic program, but it will call an action program when an event occurs. The Action program can have your UALM logic in it.


    A type 2 system monitor will only be stopped if a controlled start occurs, then you have to restart it from the Status menu. Normal cold or hot starts will not affect it. The monitor is paused when the trigger occurs, which should be reset by the action program. Another option is to use a Program monitor, which is started and stopped in your main program using the Monitor and End monitor program.


    You then create the condition and Action programs:


    Cond.tp (set sub type to condition and group mask to ***** in the program detail screen)
    : When DO[100]=On, Call Action;


    Action.tp (set group mask to *****)
    : LBL[1]
    : UALM[13];
    : IF DO[100] = On, JMP LBL[1]
    : Monitor Cond; (this resets the monitor)

    HawkME,


    I'm currently not at our building with the R-30iA's at the moment. However, I attempted this method at our building running R-30iB.


    $TTP_MON.$global_mt is write protected on our controllers. With that said, I changed this value to a 2 under CONTROLLED START. Went back into COLD START, created my TP program, changed the Group Mask to *****. When I go to set the sub type to CONDITION, I receive an error. (TPIF-071 Cannot Change Sub Type) is there any reason why this would be happening? I'll attach a reference picture for you to clarify.

    Yes, that happens when you have code in that program that are not allow for a condition monitor. The condition monitor needs to be a completely blank, new program. Then you can change the sub-type to "cond". Then you can go in and add your "When" logic.


    Maybe you confused the action program with the condition program. The action program should be of sub-type "none"

    You're absolutely right, that worked!


    Another question to add on to your breakdown. So, I setup Collision Guard to trigger DO99 once a collision had occurred. Our controllers are setup where a technician has to be logged in, in order to turn on or off any type of I/O. I know that once you reset a collision, DO99 will turn off on it's own. So I want to run an IF statement that triggers DO100 once it sees that DO99 is off. That's when our technicians will log in, in order to turn off DO100. Would the RSR be the most ideal place to run this condition? Would this be the correct way to write this logic?


    Collision_Condition.tp
    IF DO[99]=ON, Call Collision_Recovery


    Collision_Recovery.tp
    LBL[1]
    DO[100]=ON
    UALM[13]
    IF DO[100]=ON, JMP LBL[1]

    Close. Your collision condition is "When DO[99]=on..." not "If DO[99]=on...".


    Also, you need to add 1 more line of code at the end of collision recover.
    : MONITOR COLLISION_CONDITION


    That monitor instruction will reset the condition monitor. If you don't have that, then it will only work once and never again, unless manually started in the Status>Condition menu. You will initially need to manually start this, then it should be good from then on. Or if you chose to do a program type monitor then you will start it with the Monitor instruction at the beginning of your main program.

Advertising from our partners