Linking a DO to a BG logic run state

    So, time for the next thing I need help with.

    I have been handed a hardware configuration with a heater controlled by a DO, and a temperature sensor feeding a DI. The robot needs to play the part of a thermostat, regardless of what the robot's status is.

    The complicating factor is that I need to do an AND function -- I need to enable/disable the heater based on a Flag, so my BG program was basically:

    DO[1] = DI[1] AND F[1]

    Which worked fine, right up until I halted the BG program to do some work on a different section of it, while the DO was On. And stayed on, until the heater eventually blew a fuse.

    I thought I could fix this by using a PULSE on the DO instead of a simple output assignment, but even if I do a simple DO=PULSE 1.0Sec command in a BG program, the DO never turns on.

    I could perhaps use a Marker, but I would need to connect the Marker to something (system variable?) that would be tied to the run/halt state of the BG program.

    I know how I could fix this easily in other brands, but I'm wondering what the best solution is on a Fanuc.

  • Go to Best Answer

    The BG was originally a 1-liner, but stopping it caused the blow fuse. What I'm looking for is some kind of insurance against someone manually stopping the BGL.

    I did consider creating a second BG program to monitor the first, but then I'd need a 3rd to monitor the 2nd, and a 4th to monitor the 3rd, and...

    On a KUKA, my usual trick to solve this was to use a short Pulse command inside the background loop. In KRL, this guaranteed that, if the task stopped or hung for any reason, the output would go False soon after. I'll admit, the fact that I couldn't do that with BG really caught me flat-footed.

    Ok, I found it.

    $MIX_BG[1].$STATUS

    the index is which BGlogic program, in this case 1.

    Status: 1= stopped, 2 = running in normal mode, 4 = running in high mode


    Now the question is what do you do with that information? If you want to monitor if it is stopped are you going to do so in another BG Logic program, or Auto Execute program, or maybe a system condition monitor?

    A hardware solution could be a watchdog relay. That type of relay output remains on as long as the input toggles at a certain rate. So you would have to turn the DO on and off in a BG Logic program. If the BG Logic program is stopped, then the relay will turn off.

    I normally check the status of my BG logic tasks in the initialization routine at the beginning of my main programs.

    If the mode of one or more BG logic tasks is stop, the program will be aborted. In this case, I send an error message which tells the operator to start the BG logic task.

    Quote from HawkME

    You could do that with an auto execute program. In system config set either a hot or cold start auto execute program.

    KAREL or TP? I've been experimenting with a TP program in the Auto Execute setting, but it never seems to run. Even if I remove the internal loop structure and just have it set a DO as evidence that it ran once, I don't get the DO.

    I set the boot program to BUSY_LAMP_OFF=1, ABORT_REQUEST and PAUSE_REQUEST=0, and set the Groups to *. No dice.

    I was hoping to avoid using KAREL on this project, but I may be stuck.

    Quote from HawkME

    Now the question is what do you do with that information? If you want to monitor if it is stopped are you going to do so in another BG Logic program, or Auto Execute program, or maybe a system condition monitor?

    Time for my next n00b question: what's a system condition monitor?

    Quote from SkyeFire

    I set the boot program to BUSY_LAMP_OFF=1, ABORT_REQUEST and PAUSE_REQUEST=0, and set the Groups to *. No dice.

    Well, this is interesting. I've done some more experimenting with an Auto Exec TP program, and things are... odd.

    If I put a simple DO=ON into the program, it works -- on reboot, the DO is on. If I put a loop into the program, however, that loop never seems to execute. So I tried:

    Code
    WAIT 10.00 (sec)
DO[623]=ON

LBL[10]
DO[624] = PULSE,1.0sec
WAIT 0.1(sec)
IF (!F[621]), JMP LBL[10]

DO[623]=OFF

    If I turn off DO623, and reboot the robot, DO 623 gets turned on, and stays on, so the first part of the program is running. But it seems like the program aborts when it hits the loop structure -- DO 624 is never coming on.

    It's obviously not just skipping over the loop somehow, as the command to turn DO 623 back off never executes. And flipping F 621 has no effect, either, so it's not just stuck in the loop and failing to fire DO 624.

    Puzzling.

    To help troubleshoot maybe you could put a longer wait such as 10 minutes. After rebooting, check the status of the program Menu->Next->Status. Check if your program is running or aborted.

    Also, use the Message instruction in several places in your code. This will allow you to write out some debug statements to the User screen. That can help to see what part of your code was executed.

    Quote from jmd2777

    To help troubleshoot maybe you could put a longer wait such as 10 minutes. After rebooting, check the status of the program Menu->Next->Status. Check if your program is running or aborted.

    Did that already. The program doesn't show up at all, either running or aborted.

    The test program is in both Hot and Cold start. Which is a bit odd, b/c I only added it to Cold start, but it showed up under both after the first reboot. Strange....

    That is puzzling. I had an older controller that would not start the AutoExec program because the program name was longer than 8 characters. But it showed an error message in the System Log screen that said it could not find the specified program. Have you checked for any errors in the alarm screens?

    I think the controller kills auto exec programs that don't complete after a certain amount of time.

    Edit: Found it:

    Try changing your auto exec program to run your test program.

    Code: Autoexec.tp
    : WAIT 10.00 (sec) ;
: RUN BG_TEST ;

    Another option is a system level monitors that can be setup to run the moment the robot boots. Kind of the same problem though, they can be stopped and started via the status screen. Section 14.11.2 of the HanglingPro Manual goes over them

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

    Quote from Nation

    I think the controller kills auto exec programs that don't complete after a certain amount of time.

    Edit: Found it:


    Try changing your auto exec program to run your test program.

    That's good information to have. I don't think I can tamper with the Hot Start setting on this robot, since it's got a lot of "legacy standard" stuff required by the customer, but this suggests a reason why the startup program got aborted.

    Thing is... I did try having the "boot" program just RUN the background looping program, a couple times, without any luck. I'll have to try that again, a bit more scientifically, with this time limit in mind.

    Quote from Nation

    Another option is a system level monitors that can be setup to run the moment the robot boots. Kind of the same problem though, they can be stopped and started via the status screen. Section 14.11.2 of the HanglingPro Manual goes over them

    Ah! Another avenue to investigate! Thanks!

    Quote from Lemster68

    Big fly in the ointment is when the robot's status is powered off.

    That one at least isn't an issue -- I need the system to fail safe, and killing the robot power will allow all the relays to open, breaking the heater circuit and guaranteeing no thermal runaways.

    Unless the relays mechanically jam closed, but that could happen regardless of what kind of software protections I put in place.

Advertising from our partners