I think he means he is getting a frame mismatch when attempting to move from PR[x] to a different taught position, P[x].
Posts by droth
-
-
Struggling with the Model B i/o in an R-J2. I've replaced the interface (BIF04A) module as well as the basic (BMD88A1) and extension (BMD88P1) modules. All the appropriate LEDs are green. Still getting the PRIO-100 fault at start up - Model B Comm Error, and it won't clear.
First question - when I let the controller auto-configure the i/o, it starts with outputs 1-8 on rack 1, slot 1, starting point 1, and the inputs 1-8 on rack 1, slot 1, starting point 9. But with these modules, I should have 16 in and 16 out, I think... right? So why won't it auto-configure 9-16 in or out? And is that the correct order? It essentially means that my outputs are A0-A7 and C0-C7 while my inputs would be B0-B7 and D0-D7, correct?
Other than that, I read in another thread that PRIO-100 is indicative of lack of power or lack of communication. My green LEDs lead me to believe otherwise.
Has anyone had similar experience with these i/o modules? Any ideas on configuration? I'm nearing the point of ordering a model A rack, something I am much more familiar with...
-
Well, we agreed on a simple compromise. I wired the valve that fires his gripper through a normally closed push button that I mounted on the EE junction box. Like I said in the original post, much simpler than I was making it out to be.
-
Not a KAREL guy at all, but does the group mask for one or both need to be changed to *,*,*,*?
-
Good Morning, Friend, I am well. How are you? I do a lot more lurking than posting on the forum lately as it has been a while since we've brought in any new robots. Still gathering plenty of useful tips from the community to improve upon the implementations I've done.
We did add an M-6 to one of our oldest robotic cells (the S-10/RH that had the software dump which brought me to the forum in the first place!) to throw finished springs into a belt oven, and the operator is trying to cope with the cutting edge technology that is R-J3iB...
Anyway, to clarify, there is no motion taking place while he is teaching. He just wants to be able to toggle his gripper with a push button while in teach mode, instead of flipping between TP screens. He also wanted this option to work while in AUTO in case of collision, but now that I think about it, is probably not necessary.
Regardless, teach mode is where the problem lies. I can assign MACROS to push button DIs, and that will work all day while in AUTO, but a MACRO will not run in teach. I think you're right. I probably need to run through the EE connector and use RI to trigger my RO. Although, if what macru suggested works, I might try that first. Do MANUAL FUNCTIONS work in teach? I've never used MANUAL FUNCTIONS and just assumed it was another fancy screen for assigning MACROs.
Thanks all, for the replies. I'll let you know how things turned out...
-
Not real clear what you are asking here. For what it's worth, a CALL statement leaves the current program, runs the called program, then returns to where it left off in the initial program. A RUN statement executes a second program in parallel to the program that gave the RUN command, otherwise known as multitasking.
I think.
-
I am working with an older R-J3iB, pre-BGLogic, controller, and my operator needs (wants) the ability to open and close his gripper at the touch of a push-button that is to be located near where the work is being done. Only problem is, he needs to be able to toggle his gripper whether he is in AUTO or teach mode. He might need to open and close his gripper 15-20 times over the course of a setup, so flipping back and forth between the TP screens for I/O and editing becomes quite the hassle...
So anyway, if I assign macros to a couple of digital inputs it works like a charm. In AUTO. But not in teach mode. This must be much simpler than I am making it. What am I missing? How do I toggle my gripper in AUTO and teach without BGLogic?
-
I use macros for some of my more elaborate EOAT setups. Multiple actuators with 2 or 3 brief WAIT instructions. Pack it all into one MACRO so each time I need to pick up or drop off, it is one line to call the appropriate MACRO instead of 5 of 6 lines of code.
Other than that, I agree, BGLogic is way more useful.
-
I don't know if you will have to change that UOP auto assignment. When you disable UI signals, that might go away... Anyway, UOP is exactly what you thought, User Operator Panel I/O. These are the signals that you would use to control your robot with something other than the robot controller, like if it was part of a cell controlled by a PLC (programmable logic controller). There are certain UOP signals that must be held on if you are controlling your robot with another device. It won't run in AUTO right now because it is looking for those signals and they aren't there.
It sounds like you just want the robot to run in AUTO, independent of any other equipment. In that case, UOP should be disabled.
-
Line 7 of your configuration: Enable UI signals... Set that to false.
-
I went through online HandlingTool Ops. It was extremely basic. A decent introduction to Fanuc handling robots to someone who needs an introduction. 5 years later, I am considering classroom training in either HandlingTool or Electrical Maintenance. Can anyone comment on either of these? More introductory level stuff?
I've handled maybe a half-dozen integrations of used robots in my current job; from choosing the arm, wiring/handshaking, programming, tool design and manufacture, etc. I'm "The Robot Guy" here and I am mostly self-taught. I say this because although I've learned a lot (thanks to many on this forum), I realize there is much I do not know and things I could do better or differently. But I have no desire to sit through 4 days of class in beautiful, sunny, Rochester Hills, Michigan if I'm not likely to learn anything new. Plus, I've still not touched anything more modern than an R-J3iB (although I'd think a lot of the electronics would be relevant to the different gens?).
-
I believe you can set the length of WAIT timeout in system config settings... MENU --> NEXT --> SYSTEM --> TYPE --> CONFIG
-
OK, this has me intrigued. I've enabled HPD torque variables. Where or how do I monitor? Maybe a background program that writes those values to registers?
-
That's it, thanks!
-
Seems I just read a thread about this the other day, but I can't find it for the life of me. Is there a system variable that enables I/O comments to be visible in a TP program? I am away from my manuals today, so if someone can help me out with this, I would appreciate it!
-
FWIW... I have a couple of RH S-10s here. Their EPROMs are v2.0 and my software is 2.23. I'm guessing yours will work. You'll probably need KFloppy to load, maybe a terminal emulator. Search this forum for 'RH software load' or something like that. This forum managed to get me through this before.
-
Doesn't matter if my primary machine is only making 450 parts an hour.
-
Calibration was carried out, yes. Does a R-2000iA have an odd mastering posture? I just assumed that J2 is vertical and J3 is perpendicular to J2...
Ah. Something just occurred to me. And if this is correct, I'm going to feel really, really dumb. Unfortunately, I have to travel 15 minutes to another facility to check this robot out. I'll let you know what I find...
-
It is an R-2000iA/R-J3iB. The robot sat for several months, waiting for deployment. Aside from a simple 'exercise' program I ran on it on occasion, the robot is new to us and should be in good working condition. I do not recall this weird movement the last time it was running. Unfortunately, I do not have the master counts, and yes I tried mastering all 6 axes, on 2 separate occasions.
I don't see any active, configured frames, and I'm not sure what you are asking, Tony, but the TCP was my first indicator that something weird was going on. If I try to jog along the Z axis in WORLD coordinates, I get crazy rotation on my TCP. In fact, maybe the tool rotation is all I am seeing and the 'drifting' along X and Y is all in my imagination. I've done more remastering than I care to admit, always using the witness marks on the robot. I've never had a robot react this poorly to mastering, which leads me to wonder if there is something else I might be missing...
-
Is there any other explanation for not traveling straight while jogging in WORLD frame besides bad mastering? I had a couple pins slip in one of the main connectors to the robot and it wiped out my count on axes 1 and 2. I mastered to the witness marks and again with a machinist's level, but when I start driving in WORLD frame, I get weird rotation on my TCP and it appears to be drifting in directions it should not be...