Posts by OpaBroesel

    Hi, i am working with two team robots, R-1000 iA 80 F. Version 7.70.

    I try to create something in BG logic but am always being stopped by the system errors.

    The program should, according to R7 value, set one of two outputs to a default minimum.

    Line 4 in the picture is working, while Line 6 creates an error when i try to run the BG program.

    LBL 4 is at the end of the program, LBL 2 in the middle.

    Screenshot 2023-06-27 134709.png

    Can anyone tell me why ?

    When i try to call sub programs i run into the same error. It wouldn´t allow calls or some jumps.

    how do you like this :

    If Bag Robot has palletized and counts up layercount register, then pulse DO & Flag[Bag needed]= OFF

    -> Cb Robot BG Logic: if signal from BH Robot=TRUE, then Flag[layer needed] =!Flag[layer needed]

    If layer robot has palletized, then pulse DO & Flag[layer needed] = OFF

    -> Bag robot BG Logic: if signal from layer robot=TRUE, then Flag[bag needed]=!Flag[bag needed]

    When pallet is reset or counter =0, then Bag Robot DO pulse, to trigger:

    -> Cb Robot BG Logic: if signal from BH Robot=TRUE, then Flag[layer needed] =!Flag[layer needed]

    use the Flags bag/layer needed to enter box area or wait for that flag


    the bag robot sends his layer value to the layer robot after he´s done palletizing with one layer. The layer robot uses the group input to calc his target height.

    R[Z height]=GI[layer counter]*R[part height]

    it´s possible that the boxes are moved to the side, in the middle of a cycle and i have to meet starting conditions again (layer on the bottom) while the group input still sends the layer from the last palletized layer. It´s only actualized when the bag robot has been working...

    First it has been like, no layer on the bottom. That´s why i programmed it like this. now they changed everything and i have to meet those crazy conditions

    Hello all,

    I have a problem with two robots. ARC Mate 120iD/35, further known as bag robot and one ARC Mate 100iD , the layer robot.

    The task is to palletize bags in a box, whenever the counter of bags is so far that a layer counter is calced one up, the other robot should insert an intermediate layer, but also at the very beginning once under all coming bags.

    Intelligence is on the robots, PLC is not controlling anything.

    The Layer robot deposits his layer first, turns on his signal "ready for bag" then comes the bag (1 or 2 bags per layer, depending on type) robot, on his way to the box, he turns off the permission for the layer robot. He turns it on again, when actual layer is fully palletized. after that, everything works perfect.

    My problem is to allow the one robot to enter before the process begins, and find solutions for all coming cases.

    Currently I have it so that the intermediate layer robot in the initialization switches the signal for the bag robot off, so that he does not palletize first, and the bag robot switches the signal for the layer robot on, so that the layer robot can deposit at the bottom first.

    The problem now is that the layer robot moves infinitely often to the first position, if for some reason the bag robot is too slow, because the signal for the layer robot is only switched off when it is on its way into the box.

    I need some way to control that and can´t find a solution because, if i use a counter value, i match that condition once and never after.

    Next issue - i have to solve it tomorrow :-/

    Thanks for all of you who took their time to read and maybe give some input!

    thanks for the addition kwakisaki

    in my still limited experience i forgot to mention that explicitely!

    It should be unlikely that DCS config is the reason for that issue cause it has run before.

    Get an ASCII backup from a time where program still ran, and then do a ASCII backup from now, where it causes that issue.

    Install WinMerge or a comparable program and compare both, new with old code. Could give you a hint of where to apply changes

    when the robot has run before, one could assume, there has been a change to a movement command like the original command could have been something like :

    L P[1: "point-name"] 4000mm/sec FINE or CONT

    where it was

    L P[1: "point-name"] 300mm/sec FINE or CONT


    I think you need to find either the faulty command or you need one trained programmer to adjust your DCS values. There are more options to limit the speed in DCS so maybe there is just a wrong configured option

    Hi all,

    I need to set up Fanuc robots via Ethernet IP, including safety. Now that I know that should be the rack 36 slot 10 (or 11?), do I need to configure these DI/DOs or are they always ready to operate? When PLC sends true or false, will it be recognized without configuring some byte via rack 36 slot 11/10?

    Greetings and many thanks to all

    Hi all,

    i`m using one arc mate 100 iD, one arc mate 120iD and one R-2000iC with Software version v9.4.

    My issue is to do a correct handshake with PLC after the following situation:

    i have written a gripper macro for switching IO`s depending on arguments.

    In my case, i am waiting for vacuum=on with a timeout.

    If the timeout happens, i`m sending a user alarm.

    My understanding is that in this situation, i need:

    1.Fault reset from PLC
    2.CSTOPI =TRUE from PLC to send my program cursor to Main program line 1 (see config screenshot attached)

    3.Program start with UI[18] Prod start

    my PLC mate wants to do a proper handshake to prevent the operator to toggle the command, that contains CSTOPI and fault reset signals, like a maniac.

    It should do something like acknowledge that fault has been reset ( i guess i could use UO[6] = off for that ) and Programreset has been executed and Robot is ready for execution again.

    Will any background logic be stopped with a CSTOPI=TRUE?

    Any suggestions how to accomplish that in a proper way or rather, is there a signal that is ON when all these things have happened?

    Thanks for your time :)

    Thanks for your help, friends!
    I have solved the issue! The tool i have is twisted in itself!

    Hard to measure, but in an application where every 1/100 mm is important, its absolutely necessary.

    Happy to see that my code is actually working :D

    AND: no exact robots here! A shame...

    can i see that somewhere, like i can see which option packages are installed?

    Mentionable: the position where the robot needs to deburr that piece, is nearly stretched. its 1000mm away in y and 300 in x from it´s origin