Posts by droth

They are short-arm, 10S's. My payload is minimal. Collision sensor and a small gripper. I'll have to check that variable when I go back there Monday. Thanks.

I have a pair of M-10iA robots in the work cell we are building. One of them has an R-30iA and the other has an R-30iB. They are wall-mounted opposite of each other and doing identical tasks. All is well except for linear motion on the R-30iA. All of the linear moves are painstakingly slow with this robot, regardless of programmed speed or override. It almost appears to me as if the acceleration and deceleration rates are set extremely low for linear moves, also, if that is even possible. You can plainly see the robot ramping up to speed and then sort of coasting to a stop when making linear moves. It does this in AUTO as well as when I step through the program in T2.

I'm not doing anything fancy with acceleration or any other motion modifiers. All 4 of the linear moves in my programs are set to 2400mm/sec with FINE termination. I attempted to adjust the override speed to 100% just before my linear moves and then back down to 50% for the joint moves but this has very little effect. The linear moves are still WAY slower than they should be and much slower than the robot on the other side of the cell.

These robots were bought refurbished from a trusted vendor. These controllers would have been wiped clean when we bought them. There are no background tasks running or anything like that. Is anyone aware of a variable or configuration item that might cause this? I'm stumped.

Seems to me that the whole issue is due to the EOAT/hardware being used.

Unless I misunderstand, it sounds like you have 2 boxes gripped and you want to drop box 1 but you cannot do so without also dropping box 2; in other words, G2 only works if G1 is ON or gripping. Is that accurate? If not different hardware, it seems like there should be an electrical or plumbing solution to your problem.

If my understanding is correct, I do not see how software/programming can possibly resolve things, but I was wrong once before, so I'm going to keep an eye on this thread. Maybe I'll learn something new!

Greetings fellow robotters. I am getting ready to start a project that includes a pair of M-10iA/10S arms that are to be wall mounted (perpendicular to the floor). This will be a first for me personally, so I am wondering if there are any initial setup or configuration items that I need to pay particular attention to. Any other pro tips and/or advice is most welcome and much appreciated...

Have not used one of these in a long time, but this ought to be what you are looking for...

Sounds to me like the mastering is not quite right. Try re-mastering.

Hey Hawk, I have a short-arm M-10 and R-30iA here and I am trying out Circular motion for the first time. I do not have the Circular Arc motion type available to me. Basically, I am trying to teach this thing to play cornhole for my company's big anniversary party this summer.

I am happy with the path I've taught, but the arm moves through the C points SOOOOO slowly. I have several speed modifiers available to me, including mm/sec, MAX_SPEED, etc.

Oddly, I have found that entering an extremely small MSEC value gives me much faster circular motion than MAX_SPEED does, however it is still not nearly as quick as I want it to be and nowhere NEAR the speed of every other move in my program.

Is there something I'm missing here? Would posture and/or orientation be limiting my speed (and if so, how?)? Do you have any tips for achieving super fast circular motion or am I better off teaching a bunch of short linear segments with CNT100 termination?

*IMSTP, *HOLD, and *SFSPD are all normally OFF signals that must be held ON. Your PLC needs to hold these 3 UOP input signals ON to run in AUTO.

See User Operator Panel (UOP) I/O Setup in HandlingTool manual for more details.

Yeah, just add a line to your program that increments a data register after every time you fire that output. It doesn't even have to run in the background, necessarily, unless you prefer it to.

DO[X] = ON

R[x] = R[x] + 1

You can zero it out at the end of the program or do so manually whenever...

Not sure why you got the snarky replies. This is not new technology that is only available on certain models. Can do this with pretty much any Fanuc robot from R-J2 on...

I may have an old manual here somewhere, but it is a hard copy. We had/have a couple of GMF S-10s, and believe it or not, one of them is still alive and kicking and is critical to one of our most productive work cells.

Let me do some digging to see if I can find it...

Oooh, yeah, sorry, I can't help you there. Not familiar with those.

What do you mean by "schedules?" Kind of sounds like a programming thing more than a system variable. In that case, code would be helpful...

We used to have an old R-J and an old RH here. Seems like I had to hold the USER1 and USER2 buttons on the controller while it boots to get a controlled start on one of them. Cannot remember which...

Looks like you have dead batteries. Replace the 4 batteries in the robot base, under power, reset pulse coder alarms, and remaster. You can search the forum for more detailed instructions if you need them.

Check out User I/O or UOP in the HandlingTool manual. Or search this forum. I am sure there is an existing thread that can give you a pretty thorough explanation.

Not repeatable after remaster? Might want to remaster again. Points are not likely going to be exactly where they were, but I think it should be repeatable.

I would say remaster until things are repeatable and then touch up points and/or frames. But you might wait until someone more confident than myself chimes in...

If you bridge the correct terminals and replace any blown fuses you should be golden. What do you mean both are receiving 24V? I thought you reconnected the bridges?

I thought with the dual chain safety circuits, one was 24V and the other was 0V...

Did you blow the 3.2A fuse on the servo amp?

SRVO 230 is Chain 1 Abnormal 24V. SRVO-237 is Cannot Reset Chain Failure.

Power Cycle is about your only option.

This sounds to me like you are using the wrong start signal. I think you want to use UI18/Production Start instead of UI8, which I think acts more like a Resume signal.

In my experience, you don't need anything until you actually do need it. I've probably done 10-12 machine/cell tending integrations for my employer. Maybe 2 of them utilize a user frame. I have not heard a convincing argument as to why I should automatically teach a bunch of different frames of reference when creating a new work cell. If you think it will be useful to your application, teach it. If not, why bother?

I get these alarms quite often on older, R-J3 controls. Most of the time they are easily resettable just by pushing and releasing the pendant ESTOP button and issuing a reset, but sometimes we have to go into the system configuration menu (line 29, I think) to get it to clear.

Basically, the dual chains of the ESTOP circuitry are not opening and/or closing within the expected timeframe. It can (and in our case, does) happen for no apparent reason. I have even been able to generate this alarm by turning the AUTO/T1/T2 key switch too slowly or feathering the dead man switch while in teach mode. You could try rewiring your ESTOP circuitry and replacing buttons or switches, but my experience is that some controllers are just a little more susceptible to chain failure than others for whatever reason. There are 2 or 3 different ways to reset a chain fault, and I would recommend teaching them all to whoever is responsible for keeping the robot running.