Posts by droth

When you try to run after an ABORT, are you using START (UI6) or PROD_START (UI18)? This whole process has always been a little confusing to me. The way they describe things in the UOP part of the manual seems to contradict what is said in the SYSTEM CONFIG part of the manual, but it almost certainly has to do with the way you have those UOP signals configured - the CSTOPI, START, and PROD_START. Sorry I can't be of more help. Hopefully someone else can tell you exactly what you need to do...

Start type is OTHER. Yes, I ABORT with much frequency. These particular robots are a little different than what I am used to, and I'm guessing that has to do with the Control Reliable deal. When I switch from T1/T2 to AUTO or vice versa, the TP typically tells me I am either entering or leaving INTERLOCK mode. I'm not sure what that means, so if anyone can clarify, that would be good. But I've always just pressed OK and proceeded to do what I was trying to do. INTERLOCK mode has not seemed to have any bearing on what I have been trying to accomplish.

So, like I said, the program I want to run is selected. I can see it listed at the top left corner of the TP. But as soon as I hit START, first I often get a SYST-079 Startup Check Failed, which is a little odd because as far as I can tell, all of the startup checks have been disabled. But hitting RESET and issuing another START takes care of that. Once the START is issued, the program we used all last week appears on the pendant, replacing what I just selected and begins to run.

If background edit is an option on this old controller, we do not have it. I'm not sure I've ever done any background editing on any of our robots. There is no background logic or condition monitors or any other obvious reason for this robot to do this. I mean, we literally just bought this robot, refurbished, placed it in a new work cell, and ran our first order last week with no major issues. We had another job to run this week, so we wrote a new program, hit START, and it goes right back to the first program we put on it.

Now, this robot came from the same place we've bought most of our robots from, and I've never gotten one that had any signs of previous ownership (i.e. old programs, configurations, etc.) They always come wiped clean and ready to integrate into whatever application we choose. We've done power cycles on the machine with RESTORE SELECTED PROGRAM disabled - so I am forced to SELECT the program I want to run, but it continues to jump out of the selected program and back to the old one from last week. It is the weirdest thing...

Setting up a new work cell, UOP for starting. Everything was working fine last week. There is no auto-exec for hot or cold start, I've disabled RESTORE SELECTED PROGRAM, yet when I SELECT a different program and hit start, robot jumps back to the last program we were running.

Unfortunately, I have to go put out a fire elsewhere so that's as detailed as I can be at the moment. Robot is a Control Reliable M-16iA/R-J3iB. My start button is mapped to PRODUCTION START...

Any thoughts?

SYSTEM configuration setup... CSTOPI for ABORT or Abort all programs by CSTOPI. I think the correct path is MENUS>NEXT>SYSTEM, (Type) Configuration.

To be clear. I think the HOLD signal is a normally on condition. It is when that signal is interrupted that the alarm will occur, hence the broken wire keeping the robot in the HOLD state.

And if you turn your outputs on from the TP, do the appropriate numbers light up on the cards? If so, you should be configured correctly.

In the pictures, DI[01] appears to be on. Does the I/O screen on your TP agree with this? If so, your inputs are probably already configured correctly. Your inputs should be rack 1, slot 1, starting point 1. Your outputs should be rack 1, slot 2, starting point 1. Unless your digital I/O has already been mapped to user I/O, you shouldn't need to do any mapping. But if that were the case, more outputs would be on and you would be seeing UOP alarms.

I agree with HawkMe, though. Auto_config. If that doesn't work for some reason, force it to auto configure; power down, remove the I/O cards, cycle power on and off again, and put the cards back in.

Pretty much the same process, regardless of controller. Line up the witness marks. Remaster. Calibrate. You've apparently found the SYSTEM screen with mastering options. You want zero mastering.

Well, we turned it off Friday, and I just went down to check. The robot powered up normally and the battery alarms are gone. That was really weird.

I had to go back down there and look, but there is no pulse coder alarm. I have had to reset the pulse coders when changing batteries on R-J3s. I think it is a function key on the alarms history screen. This R-J2 Mate doesn't even have an alarms history screen, so I'm not sure where I would reset PCA anyway.

I can still jog and I can still run a program, so I haven't lost anything. Yet. And the SRVO-065 is just a warning, as I understand. With any luck, I can cycle power without losing positional data, and if I still get the alarm, well, I guess I'll just leave it on all weekend....

I'm replacing batteries this week. This morning, I powered up a LR Mate with R-J2 Mate Controller. I opened the battery case and got the expected SRVO-065 on all 5 axes. I put fresh batteries in, button it back up, and hit RESET. Still, I have SRVO-065 on all 5 axes. I tried the old batteries again, but could not clear the alarms.

I'm contemplating putting the new batteries back in and just cycling power and hoping for the best.

Has anyone ran into this before?

Oddly, the cable on I/O interface JD1B was connected to JRS8 on the operator's interface board instead of JD1A on the CPU. This robot was purchased used, so the previous owner must have had it plugged in there for a reason, but it did not work for model-A I/O. If anyone knows why it would have been connected this way, I'd be interested to know.

I've also been getting SRVO-043 on this robot right after boot. We just got these 2 identical robots, so I've swapped about everything I could possibly swap between the two trying to isolate the problem; amplifiers, redundant ESTOP boards, regenerative resistors, even the actual arms. The fault stays with the controller regardless. Going to send it off after the holidays unless, by chance, someone here has seen this before and has a solution...

I want to add to the great advice! When checking RP1 and RM1 robot cables, make sure that none of your pins or sockets have slipped out of the connector. This happened to me once a while back, and took me a long time to track down...

Working with an M-16iA and R-J3. What would prevent this controller from auto-configuration of the I/O? The appropriate variable is set to TRUE, but with every power cycle, if I delete all the assignments, the configuration lists digital inputs and digital outputs from 1-512 unassigned. Or, if I try to manually configure, it will maintain what I've entered after cycling power but say the configuration is invalid.

As a side note, it takes an abnormally long amount of time for the controller to create the I/O tables at startup... if I try to view the I/O menu too quickly, it says something to the effect of 'menus not created, try again.'

I feel like I've been through a similar situation once before, but cannot recall for the life of me what the issue was. And initial attempts at searching under the new format have been fruitless, so I apologize if this has been addressed here already (as I am sure it has been).

The offending board is an I/O PSU UNIT type A05B-2401-C31

Just in case anyone had ANY input on the subject...

Mainly, I'm looking for CRP17 connections. It is a rectangular 12-pin that connects to a board on the cabinet door. Not the main board with the safety circuitry, but another board, lower on the door.

Does anybody have any wiring diagrams or schematics for the Control Reliable R-J3 cabinet? I would be most grateful.

droth at winamaccoilspring dot com

What, if any, advantages are there to buying software for offline programming/simulation in absence of complex paths? We just received our 12th and 13th robots, so we have a few, but they are all pretty ordinary machine tending applications - no high precision, no extravagant motion...

And does anyone have any experience with Octopuz? Seems like a pretty versatile package and I'm going to guess it is quite a bit cheaper than Roboguide, but again, is offline programming software something I am even going to use very much or very often?

Your input is appreciated.

Oops, my bad. That is why you resume where the cursor was instead of starting the program over. It's Monday. I'll catch up eventually.

Correct me if I am wrong, but simply recording the position where the robot stopped won't help you return to the same place in the program. You will be able to return to the same physical location, but you'll need to somehow record which line of the main program you were on when the robot was interrupted.