Posts by ClaudiuA

MENU -> I/O -> UOP -> IN/OUT -> CONFIG

I don't remember what number rack the ETHERNET is at.

Uh, as a long time greaser of these puppies, I can only say that you people are overthinking it.

Set the robot in a comfortable position for yourself, release the OUT plug, install the IN grease nipple if there isn't one already - I think R2000 has them already installed, some smaller robots only have plugs -, pump until clean grease pushes out through the outlet. Do not use high pressure for pumping. Use a handpump if possible, otherwise pneumatic set on low pressure. Do not hurry. Do not make a mess or you'll get a lot of stink eyes.

You use VigoGrease REO for all FANUC robots, with a couple of exceptions. 16 Kg Pails generally.

Exercise the robot after you finish greasing +/- 10 degrees on each greased axis before installing back the plugs to get rid of the built up pressure. Some grease will probably push out. Clean it off and install the plugs. Congrats. Your robots will live happily for another year.

Pay close attention to the used grease coming out, especially at the start. Watch for metal shavings. If you notice them, be prepared for a reducer swap somewhere in the future.

Call Program (AR[1]) where AR = value.
AR is an argument register.

Program Math

R[1] = AR[1] + AR[2]

Call Math (1,2)

After that call, your R[1]=3.

I think that's as simple an explanation as possible.

We had this happening twice:
- Faulty cable from controller to TP, but usually gets really random errors.
- Faulty optic fibre cable inside of robot controller. Can't really say which PN off the top of my head, but it was for a R30iA controller. Issue disappeared after changing said cable.

Quote from I3ooI3oo

SMOKE

I can confirm this.
Twice.

Between the fingers, just a direct entry with an offset on Z. Seems like the best solution for whatever it is you're trying to do...

Just don't try to milk the cow with it. She may not like it.

Yep, Romania here. I've worked with quite a few FANUC robots so far and the issues mentioned on this topic are basically news to me. Even the older models of FANUC that I service from time to time - RJ3s mostly - don't have path issues even if the factory where they were installed is on the poorer side.

Quote from bidzej

Guess we need to clarify one thing - many features, that are an option in the US, are standard in (most?) European markets. Like Karel for example, where the only thing you need to do is change $KAREL_ENB to TRUE. Looks like some path related options might also be treated differently.

I don't think I've ever installed a FANUC robot that would behave differently based on set speeds or overrides...and we never ordered any special features aside from what we generally needed. I was actually confused as to why people were having this issue with FANUC, but if it's different for the US than EUROPE, then it makes sense.

Hello.

You could also consider Universal Robots UR3/5 for such an application since it is collaborative and pretty friendly to use.

So yeah, the error does carry over. That saved me some time in rearranging a UR3's joints to see if I can have it up and running again.
If I manage to get some info from UR regarding this particular robot and why this particular error came about, I'll post it here as well. Maybe it helps us all to avoid these kinds of issues in the future as they're the most random that I can think of.

Honestly, not really. If I were doing it, I'd do it the same way as you . UR "wizards" aren't really as reliable as UR would like us to think, so I prefer writing code wherever possible. Just know that those things exist and you could use them if ever you have a more complex trajectory that you want to tie to one single WAYPOINT.

Will you please post if that happens again? I'm curious of this particular error since we've just tackled the issue with an UR3, twice, and I'm dying to see if the error carries over if you switch two joints around.

You can use relative WAYPOINTS in the MOVE specification.

Please see chapter 14.7 in your USER MANUAL that you received with your UR robot, or download it from:

https://s3-eu-west-1.amazonaws…User_Manual_en_Global.pdf

Quote from HawkME

No. If you need a monitor to run all the time then you can use a system monitor instead of a program monitor.

Can you please expand on this? I've never used a system monitor and am curious how and for what you could use it.

Quote from dofrey

I solved the problem. I loaded a backup to ROBOGUIDE and saw, that my space was wrong aligned. I didn't check the user frame good.

Important for someone else having a similar problem: the DI needs to be set and if it is not ON the robot will HOLD when entering the space.

To avoid see attachment.

Uuu, that is nice. Will implement today for an application where I don't need that pesky DI.

Change from INSIDE to OUTSIDE and also define a DI that allows you to access the area.

Ohhhh, that was your problem, actually waiting for the robot to move its hiney back into position while you kept the button pressed . Yeah, that is a pain in general and I had to instruct a lot of clients to just add a read current position instruction to the start of the program.

Hope that helped your problem then.

You can have an INIT program running at the start that would initialize a R[1] to a certain value - number of cycles.
After that, it's as you described. Count every cycle in an R[2] and when the value reaches R[1], call your spraying program.

You're trying to count out cycles for welding or something similar, no?

But yeah, that would definitely work. It's as simple as can be.

Change the joint.

Or, to quote UR:
Possible next steps:
Update the robot SW to newest version
and also
a) Do a Complete rebooting sequence as per section 5.3.7 of service manual
b) Check grounding and shielding for EMC problems

That's all that you're likely to get on the issue as support apart from being asked to change the joint out.