Posts by OpaBroesel

okay solved it myself.

I didnt choose the IF Statement with those brackets. With brackets, the JMP after IF is allowed.

Sorry

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.

my logic is now as follows:

i reset the flags bag/sheet needed and pulse the DO"layer ready" after the robot has been in the box.

in my background logic, i ask for

IF DI"layer ready=TRUE AND !Flag THEN

Flag=!Flag

ENDIF

i will test it today thanks for the input

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

addition:

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!

maybe try using different weight setups, different centers of gravity could adjust ACC and deceleration to fit your one sided setups...

meanwhile I figured as much, but thanks for your reply!

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

before.

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

Okay that's already been the answer, thanks. DCS is installed, I just didn't know if I needed both. Thanks

300 mm/sec is pretty slow. What's the speed in one such movement command where the robot generates that fault? And what's the general override while it's executed? Many robots make up to 4000mm/sec so for example if you call a movement with 10 % speed in that command and you run it with 100% override... that's still more than your DCS allows the robot to.

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

thank you!

UOP in and outputs

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

what about going back to older versions? can i simply run the FRVRC770 install .exe while currently sitting at 9.4?

Quote from Eric

You can see that in the purchase order or maybe in the delivery notes.

Do you deburr everything on the same plane? You can measure the exact plane with a 3 point method as BASE.

i did it with three point method.

Everything on the same plane

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

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