The eprom only has the bootloader, normaly you will have to load the software yourself.
Or, in case you have a backup, load the backup.
If you are not able to do that, try to buy a pre-installed board.
Be sure to give all the information of the robot as there are a lot of versions of robots.
It should not make any difference I would think, but Have you tried using another PR ? Or using an offsetregister ?
In addition to Skooters remarks,
When the distance between the feeder and the nozzle is big, and there is more then one bend in it, the wire will buffer and that extra lenght will come out when the feeder is stopped.
So, make the distance between the nozzle and the feeder as short as possible, keep it as straight as possible and use a lining with a fit as thight as possible.
Is there a remote / local switch ?
There are two ways to standardize robot programs :
1 - Stick to one brand.
2 - only use the common programlanguage, so, only use the things available in all used robots.
It seems the plc guys have two options :
A - remove all the Staubli commands the Fanuc can’t handle and replace them with something that both can.
B - They quit moaning and get the job done, that’s what they are paid for.
It seems that nobody knows...And I don't either.
The only help I can give you is to tell you how I did it. (not to a plc but to another robot)
I use a 15 bit group IO plus a separate input for negative numbers.
Ofcourse you can use 16 bit signed integers, but I use the fact that it is negative also for other porposes, and this makes life much easier.
This gives you a range of 0 to 32767 positive and negative.
I use three additional IO for handshaking.
One -hello I need a position- line
And two -I am ready, are you ?- lines
A little more precision is welcome but you don't need real numbers.
In the sending robot (for you the plc) for X, Y and Z, multiply the number by 10 and send it, and divide by 10 in the receiving robot.
For W, P and R I multiply by 100 for even more precision.
This gives me the range that I need and a better precision than the repeatability of the robot.
If you find a better way, please let me know.
Fanuc had no explanation ?
I can't find these faults in my lists.
I think the only way to get rid of this is to reload the software from scratch.
As I understand it is not possible to de-install software options.
When the robot is working and doing it's job, simply ingnore the faults.
If not, you will need the schematics to see where the robot wants his 24 volt and give him what he needs.
If the robot is, as I understand, from 2021, the cable-fault is comming very very early in its life.
A possible cause of this is an axis 1 stretching the cables too much.
We had a robot with the mastering of axis 1 is not in the standard position and allow the robot to go way over the maximum position normaly possible.
This stretches the cables.
The communication with the encoders is very sensible, so they are almost always the first to go.
Move to the pr41 position. without the offset.
If it moves the problem is the offset.
If not :
Change it to a joint movement.
If it moves, the position is reachable and the problem is an intermediate position.
Try to reach it from another angle by adding a position, or keep it a joint movement.
If it still don't move you will have to change the position or rotate the robot.
I am afraid that you will not find anything specific....
It is a encoder problem, thats for sure.
You swapped the encoder, so it can be :
Cables
Connectors
Servo amplifier
Grounding !!!
Something else.
Read this post, there is already a lot of information in it.
And as you will read, sometimes it is something you did not suspect at all.
You will get a limit error when the next point you are going to is out of reach.
In case of a linear movement all of the intermediate positions must be reachable too.
So the problem is the next point or the fact that it is a linear movement.
check if the PR41 is within limits and with the offset is too.
If that is ok, try a joint movement.
The robot moved when it is not supposed to, or is not moving where it is supposed to.
The robot may be overloaded or the brakes are worn or greasy.
If not, check voltage on all three phases
Check connections of the servodrive.
Replace the SIF-daughterboards.
Checked all fuses ?
I had that same problem and I could not find a software solution.
So I hooked up a horn on the UOP tp enabled output.
Every time when the robot is in program and they switch on the tp, there is a 130 DBa sound resonating through the whole factory.
That helped.
It will work, all the PSU's of RJ-2 with the same partnumber are interchangeble.
The only thing on RJ-2 i ran into trouble with are the axis- daughterboards on the servodrive.
Some versions of daughterboards won't work on some versions of servodrive.
And all of the daugterboards have to be the same version.
It indeed sounds very similar, and the solution will be very similar too.
It is bad memory or a bad cpu-board. You will have to replace and reprogram it.
If the robot has been stored in moist condition the contakts of the memory can be oxydised and cleaning can be helpfull.
Remember that removing the memory whipes it !
Since bootmonitor is having problems… you are sure the PSU is ok ?
I think the robot has to be remastered.
When it is on all axis, the batteries for the encoders are empty.
If the robot still is mastered, change the batteries WITH THE ROBOT ON !
Otherwise you will have to remaster the robot.
Change these batteries every year.
If it is only on axis 6, the problem is the encoder or the cable.
