Posts by djogf412

wow... this is pretty stupid.

How are poorly designed EOATs and bad PLC logic a reflection of ABB robots?

I work with IRB 6400s, and have had plenty of issues, but it is always peripheral equipment/circuitry. The only part that has been (mostly) solid is the robot itself..

I have had to replace an upper arm cable and some cabinet components, but it was due to environmental conditions of the work space, not the robot design.

I almost feel like this article is saying "News Flash! Maintenance technicians are having to fix things!" smh

Yes, I can do that if it will work.

That's part of the reason I was asking here, the manual didn't make it very clear.

Basically I want my already existing DO to be "locked out" from being ON, unless the run chain is ok.

I need to set up an interrupt (not a trap routine) for a piece of external equipment in a robot cell (IRB 6400 / S4 controller).

I need to have an already existing DO turn OFF if the run chain breaks during execution. I'm looking through my manuals and may have found a solution, but I'm looking for some confirmation on how to set this up.

If I assign a new DO as a system Output linked to RunchOk(Run chain NOT broken), and then cross connect From (runchainDO) To (existingDO), will my existing DO set to 0 if the run chain is broken?

Thoughts / suggestions welcome. Thanks

So I replaced to upper arm servo cabling (hell of a job if you've never done one..) even had to solder an I/O cable because we were sent a cable with customer connection (which my robot doesn't have).

But, after all that, and after reprogramming my subroutines (lost rev counters), I am up and running and have seen absolutely no issue with the axis 4 error I was getting. Side note: once I got the old cable out I could tell it was in bad shape.

Thanks for the input to all that answered.

Thanks for the tip RoboGeek. But I have already replaced the drive unit, even swapped 4 & 5 drive cards, still axis 4 error

Thanks for the input guys.

I'll change the cable out and see what I come up with.

Quote from wheensy

I have [a] question[sic] for an experienced operator/installer.

2 axis (axis's, axii, axises,??? however it's said)

Thank you in advance

Axes. As in, "I'll chop down this tree with my two axes."

You are welcome.

Looks good.

Good stuff RacerMike

I'm looking for some insight into a problem I am dealing with. I have an ABB 6400 that I have been fighting with for a while now.

It began with intermittent Joint speed errors(always axis 4, NEVER any other axis). I have suspected the encoder cable and possibly the servo itself for a while now, but it has been suggested to me that the issue could be in the cabinet. Possible overheating, dust, etc. (I even changed the SMB on a suggestion, to no avail)

Now it has reached the point that the robot is not only throwing axis 4 joint speed errors, but every few times it also looses the rev count for axis 4.

I am thinking of replacing axis 4 servo and upper arm cable, but I need to make an informed decision.

Thoughts? Suggestions?

Not sure if this idea might help you but a simple solution (I use this with one of my robots) is to feed a solenoid(s) valve with the air, and manipulate which one is open/closed with I/O from robot or plc. for just a simple gripper you would just have 2 valves.

Quote from dfgas

I know the right way to fix this would be to move stations a and b where they need to be but i know they will probably now allow me to do that because the parts we run need to run all the time.

Welcome to automation engineering

I'm guessing this was some kind of pre-fabricated cell? I'm not 100% clear on your setup, but is there any reason your sensors couldn't be adjusted/moved?

and when you say the robot stops in the routine, what exactly do you mean? is there an error code? what are your proxy sensors doing?

Quote from Steve

Problem was the machine was not mastered.

Yep, that can tend to cause an issue.. haha GL

hmm, could someone explain the g:1 a:8 thing?

and the answer remains the same.. there are physical limitations involved. My guess is the program is too aggressive, and excessive heat in your controller is not helping the situation either.

Look at cooling options, and reduce speed.

Check your EOAT (tooling). more specifically, check your Tool Center Point

you may need to come up with a good way to keep your TCP calibrated

like HAWKME said, your positions will not simply alter. is anyone else allowed to alter the programming? make sure user frame is correct, and make sure robot and any fixtures are secure. other than that, I would be going right to the EOAT to see if it moved

Could you briefly explain your robot cell? what type of operation is your robot doing? (e.g. deburring/deflashing, material handling, pick and place, welding, etc)

understanding what is causing movement interference will help us give you better answers

uhhh you are asking in the wrong place

you could try asking in a general board, but this forum is mainly for industrial robotics (this section specifically for FANUC robots)

Quote from swapnil

Yes we are wunning robot at low speed but Production people want to run @100%
as Productivity goes down

Yep, I've been there lol

With any automated system, at some point there are mechanical limits. The answer is to try to find a balance where the servo isn't being overheated, and production/admin is ok with production speed.

You've still got me confused though.. this whole thread was about an axis 8 error? and you have 7 axes?

And you mentioned controller heat. There are different types of cabinet coolers/vortex coolers that could help with that and may help resolve your overheating issue.

I'm going to assume PRGM0008 is something you made and that P[1] is a position you created by jogging (correct?)

Is there any chance you have a Background (BGLogic) program running? and how are you starting your program? manually on the TP? is there a MAIN/subroutine involved?

That specific code refers to a Karel program error.

"Untaught or Uninitialized data was used by the program."

Fanuc's suggestion for this issue is to simply teach or initialize the data before running the program, so I guess you need to find out what data (I/O, register, pos register, etc) is causing the error.

alarm # ?