Posts by BrainKaput

Yes, the estimated payload is around 10kg.

Thank you for the feedback!

I'm not sure what is what you're looking for and what's the purpose of that?

Anyway, for what you're asking I'd create several J moves around with different rotations in the axis.

Hello guys,

I'm considering the 50E for an application and never had or programed one. Some people told me that the wrist is prone to mechanical failures and that the wrist/gears needs to be replaced every few years (3-4y).

This is very unlike the Fanuc we already own. It seems to me that this feedback from the 50E version comes from an unproper use of the robots with overload, collisions, and poor maintenance.

What is your opinion on this?

Hoses are for pneumatic and signals.

Checked for those terms and that's it. Thank you!

Hello!

I'm searching for solutions that can allow to rotate the end-effector indefinitely without the inconvinent of hose limitation.

A search in the web got to me to swivels by RSP but appart from that i've found nothing else.

I've seen these kind of systems around but don't know where to search.

Need some help here. Any ideas?

Hey guys, update here.

The version of the software allows the no motion PR operate mode, yes, but i was trying to avoid that.

I found out what was actually happening and it was not related to the offset program.

Before the offset is executed i execute a program to comunicate with the plc and this program had 3rd group active.

The robot is executing a program with groups 1 and 2 active, the plc communication had only the 3rd group active. So, each time it was executed the robot stopped groups 1 and 2 motion.

Well, you can't do timers in BG Logic but you can do math. You can do some thing like the following.

BG Logic runs in cycles of 8ms (= 1/125s).

R[x]=R[x]+1/125

If R[x]>0.1 then "your code"

Perhaps you need to add some flag as a condition to run the BG Logic whenever you'll execute it to reset the R[x].

Quote from massula

When You say multitask You are referring to BG Logic?

If so, You need to avoid executing this part of the code every BG LOGIC cycle.

Depending on the controller generation You have, You can try to use IF and JUMP/LABEL statements to execute this piece of the code only when You have a certain DO or FLAG set in the running programs.

BG Logic cannot work with motion.

I was thinking about RUN function but, as far as i know, you cannot put arguments in it.

Also, in order to write the PRs a program needs to have the groups activated. I think the system would block the RUN command if trying to execute the PR_OFFSET program.

Hello!

I'm looking for a way to edit PR values using multitasking.

In this application, we need to use several PRs to be aplied both to the frame and tool to the same point.

E.g.:

P[1] Offset, PR[10] Tool_offset, PR[11]

P[2] Offset, PR[10] Tool_offset, PR[11]

P[1] Offset, PR[12] Tool_offset, PR[13]

P[2] Offset, PR[12] Tool_offset, PR[13]

In order to edit the PRs to the intended coordinate I'm using a simple program with arguments

E.g.:

PR_OFFSET(id_pr ,x, y, z, w, p, r)

;PR[GP1: Ar[1], 1] = Ar[2]

;PR[GP1: Ar[1], 2] = Ar[3]

;PR[GP1: Ar[1], 3] = Ar[4]

;PR[GP1: Ar[1], 4] = Ar[5]

;PR[GP1: Ar[1], 5] = Ar[6]

;PR[GP1: Ar[1], 6] = Ar[7]

So I end up with something like this:

CALL PR_OFFSET(10, 1, 0, 0, 0, 0, 0)
CALL PR_OFFSET(11, 0, 1, 0, 0, 0, 0)

CALL PR_OFFSET(12, 0, 0, 1, 0, 0, 0)

CALL PR_OFFSET(13, 0, 0, 0, 1, 0, 0)

Problem is everytime this code runs, the robot goes to a complete stop for around 1-2sec.

Each time the robot picks a part and executes the main program, this code will be executed more than 20 times, which gives a total of at least 25sec of cycle time wasted.

Any idea on how can I overcome this?

You can not deal with motion in BG Logic (believe me, is for the greater good hehe).

BG Logic, like it says in it's name, is only for logic.

Dynamic Path would be the way.

If not, maybe you could have a sort of measurement before the job, even using the device, and apply the given variation using a pr offset.

But like you said, the device itself should absord the variations, maybe even better than the robot.

Not sure what you're looking for. Maybe you're looking for Macro instructions?

Quote from Srt_424

#4. Change the joint/linear speed to 100% and CNT adjustments gradually.

Regarding this, there are a couple stuff that you should be aware.

1st, the joints have a max deg/sec speed, which means in linear motion there's always one joint that is the limiting factor if you're using high speeds or rotation movements. You can check this if you go to alarms and Motion Log, you'll notice there will be some alarms regarding motion limits. This said, if the robot is already in the speed limit, it doesn't matter if the speed is 1000 mm/s and you change it to 2000 mm/s, since it will maintain a linear movement at the limit speed.

2nd, sometimes, increasing speed is not worth it. What i mean is, it all depends on the situation but all things considered you won't get much improvement at small distances. That increasing speeds will also increase the load and fatigue in your robot. So, be nice to your lad and keep speeds as low as possible

(regarding fatigue, at higher distances you do use of ACC point option)

3nd, the motion controller of your robot calculates optimal trajectory better than we do. Keeping this in mind, usually the less points the better.

It seems some sort of fluid. You sure the metal is properly cleaned before welding?

I assume you're welding with a robot. Did you check for leaks, etc,..?

Quote from Okami

Trust me, the joint vs cart represent is one of the most important things here.

I saw how a gripper crashed against a pillar due to this config.

Oh, yes, absolutely. I'm just saying that this is the method I would use.

He should check the pr has joint coordinates.

Anyway, what he intends to do is run the same point with different UTool. Therefore, if the PR is saved as joint coordinates the robot would always move to the same position.

So,

Quote from pdl

EPeters1 is almost correct. While his method would work if you change a system variable, by default, P[x] points are stored with a User and Tool frame. If you try to move to them with the wrong frames selected, you will get an fault (frame type mismatch). There is a system variable to skip the frame type check, but it is advisable to keep it set to its default value.

Instead of using P[x] points, you would use Position Registers PR[x]. Position Registers are not stored with a user or tool frame. They are also global, i.e. they can be accessed from any program, not just the program they were created in. Also, each element of a position register is addressable, meaning you can modify any of the XYZWPR individually.

In theory, this plan will work to only use one taught position register, but it will only work if your individual tool frames are taught accurately enough to deal with any non-compliance that your fixture may have.

Looks like hermann beat me to it while I was typing

This is a good solution and I believe says it all.

Save the position as a PR and be sure each tool is accurate for what you intend to do.

You sould have no issues.

Quote from HawkME

I believe there is a UO signal that does what you are asking for. Set home = true on each ref pos, then monitor UO 7.

You will have to test and verify.

I tested it. Apparently, and unfortunatly, it only works with Ref Pos #1 even if you say the position is a valid home. So it doesn't actually fit what I'm looking for.

Anyway, thank you all for the suggestions

Rotating table but the table only has 2 positions with a window in the middle so there's the need to control the joint position (Its a grinding and polishing robot cell). So, the Z option is not viable.

The cells are identical in size, robot, table. Only the table motor and control is changed.

What I said, it means that in each robot i can have different setups for different products but the rotative table remains the same.

The different home positions will be related to path optimization, since the grinding units that are going to be used for that particular product will be different, or to the gripper itself (one of them is almost 2m wide). I try to start and finish each routine in home.

Just for the record. Currently, everything is working fine as it is. I'm just trying to improve the code

Quote from kwakisaki

Having several home positions and just using one signal to tell the PLC the robot is home is not something I would personally recommend.

As far as the PLC is concerned the robot is at home, but which home?

If the PLC is mastering the process, ie selecting programs for the robot to execute, then I thought a unique signal for each ref pos is a must have for error checking/confirmation before executing the program.

All depends on how your using the PLC I suppose to determine which would be a better solution.

In this particular case, I have two different situations (different robot cells).

First one, a robot cell with rotating table not servocontrolled. The PLC controlls the rotation of the table.

Second one, the rotation is servocontrolled by the robot.

The cells are similar.

I need to control the robot position in order to avoid crashing the table in the robot.

When it is the plc controlling the rotation I activate a DO (ref pos) when at home as a condition to rotate table. When it's the robot I'm using a similar logic, I activate DOs for each position and rotate if any is active.

So, in any case, I only need a DO communicating to the PLC/ to rotate.

Besides this, it would be useful for some alarm in HMI for when someone tries to activate table without the robot being in a proper position.

Quote from hermann

You can use BG logic to sum up all seperate DO to one DO.

Yes, but I thought that given the option to activate a ref pos as home there would be some sort of configuration that would allow a simpler solution.

Hello guys,

In the same robot cell i need to set more than one setup and therefore i have more than one home positions.

In ref position you can only set each with a unique DO otherwise you'll have conflict.

I found nothing in the system configurations related to this particular thing.

Who can I have the same DO for all of my home positions? E.g.: to communicate with the plc, saying that the robot is at home.

Thanks!