Anyone ever seen the SSR's burn up like this (see attached photo)? They are on the 1GB board on a C controller.
I can enable the motor power but as soon as I try to jog any of the axis it throws error 1504 (position envelop error).
Anyone ever seen the SSR's burn up like this (see attached photo)? They are on the 1GB board on a C controller.
I can enable the motor power but as soon as I try to jog any of the axis it throws error 1504 (position envelop error).
Positional envelope errors usually occur when there is a substantial difference between commanded value and actual value for the motor(s) position based on the encoder feedback.
ie. if the brake has not fully released, preventing/restricting shaft rotation.
Those devices are the individual brake release controllers which are logic controlled switching the main brake voltages (hence SSR's) and are used when using the robot in teach/repeat modes.
The manual brake release buttons inside the controller, directly drive the brakes instead and are not controlled from the 1GB directly.
HOWEVER:
I would investigate thoroughly the brake supply chain in totality first, from the secondary side of the mains transformer to the internal rectifier (V1) as this is the source of the brake supply voltage.
The logic side of the devices on the 1GB should be ok as the SSR's provide isolation so this really pushes the root cause from incoming mains/transformer secondary/V1 rectifier areas.
V1 is a bugger to get to in order to check/replace if memory serves me right too
Replacement 1GB is required (or you may be able to obtain these as individual components - not sure due to age), but I would carry out some checks first or possible risk of damaging the replacement.
Thanks, I'm leaning towards a short in X5/X5A harness or a short in the machine harness. Causing the load side of the SSR to burn up. I verified T1 and V1, that side of the circuit seems to be operating fine.
Further referencing info I have:
1GB CN4 connector supplies the 24V supply via K3 auxiliaries.
- K3 energised (NO) aux when motion demand.
- K3 de-energised (NC) aux when no motion demanded allows for manual brake release instead.
1GB CN5 (when K3 de-energised (NC) aux) receives 24V, feeds the brake release buttons.
1GB CN6 either uses 24V supply on CN4 for SSR control - K3 energised (NO) aux when motion demand.
or when K3 de-energised (NC) aux directly drive each brake via switches.
1GB CN6 outputs all brake supplies to brakes via X5/X5A.
From what you've got just from the image, my next step would be:
- Disconnect X5 and X5A (both ends), use a megger to test for current flow/leakage test:
- Brake line to earth.
If that doesn't yield anything, then from X5A (Robot side) do the same with each brake harness.
- Disconnect motor brake harness from motor.
- From X5A end, megger each brake harness lines to earth again for current flow/leakage.
Both should prove/disprove internal harness/umbilical damage.
Check your 'conversation'....
Got it, thanks!
I'm getting a weird reading between pins 1&2 at X5A when the harness is connected to the controller (CN6 @1GB is disconnected). I'm getting 2.26 M ohms between 1&2. It goes away when X5 is disconnected from the controller.
When you checked T1 secondary and V1, what VAC and VDC were you getting?
So you have disconnected X5A from the robot and measuring pins 1 & 2 on X5A whilst X5 is still connected and 1GB CN6 is disconnected?
What about 1GB CN5, is that still connected, if so disconnect that also.
I take it you have replaced the 1GB at this point too?
So you have disconnected X5A from the robot and measuring pins 1 & 2 on X5A whilst X5 is still connected and 1GB CN6 is disconnected?
Yes, my I disconnected/removed my 1GB board from the controller (waiting on a replacement). I had to go track down my megger, its reading less than 1/2 M ohm between 1 & 2. But is open when I disconnect X5 from the controller?
When I test 1&2 at the controller without X5 connected its also open.
So no 1GB board is inside and 1GB leads are all disconnected then?
Then you're measuring from X5A (not connected to the arm) whilst X5 is still connected to the Controller?
ie the umbilical is just connected to the Controller and open ended at the robot side.
What series arm is it U or Z?
So no 1GB board is inside and 1GB leads are all disconnected then?
Then you're measuring from X5A whilst X5 is still connected to the Controller?
What series arm is it U or Z?
Yes, and Yes, Z series.
I'll have to megger out stuff tomorrow on the robot side harness/brakes. I'll also power back up and verify V1 again.
Ok with it being Z series, referencing troubleshooting manual pinout I would disconnect the complete umbilical both ends then send some HV down it and check for current flow/leakage, there should not be any to earth at all:
Each brake line to earth (please double check these with the troubleshooting manual first):
- 1 & 40
- 2 & 40
- 11 & 40
- 12 & 40
- 21 & 40
- 22 & 40
- 3 & 40
- 4 & 40
- 13 & 40
- 14 & 40
- 23 & 40
- 24 & 40
Each brake line to brake line (please double check these with the troubleshooting manual first):
- 1 & 2
- 11 & 12
- 21 & 22
- 3 & 4
- 13 & 14
- 23 & 24
You would also benefit whilst it's all disconnected, also disconnect the brake cable at the motor end, then megger at X5A connector and test the integrity of the robot internal brake lines too.
(take care to cross reference the right pins in the troubleshooting manual before zapping).
Aging issues I have seen before where internal brake harness is failing in certain positions (stretch and compressing areas), but not enough to cook an SSR, never mind all of them, the positional envelope error usually catches that and mech disconnects 24V to the 1GB via K3.
Maybe worth checking the aux's out on K3 too.
Finally at the motor end, if you have a variable current 24VDC power source, individually check each brake so that they are working and not pulling to much current....
Take care if you do that though as joints will fall under gravity - brace them first.
I think if all the above checks out, then this steers back to the controller.
It just sticks in my mind the fact ALL SSR's are cooked, kind of steers me towards T1 secondary and V1 providing too much juice or V1 diode failure.
I noticed today that my diodes were burnt out D1-D6. I also noticed that the diodes are installed in a reverse bias. So... I went and checked my voltage on V1 and sure enough I had my polarity reversed.
Correct me if I'm wrong here but reversing the polarity at V1 would cause D1-D6 to "close" and create a short circuit across the SSR's. Burning up the diodes and the SSR's. Which looking at the spec sheet for the diodes is 35A, which is why my SSR's are fried (with a max load of 4A).
Not too sure what you mean here:
Are D1 to D6 short circuit (have you removed them from the board) as in circuit if the SSR is short circuit then they would measure as a short circuit.
, never seen the outcome of reversal of V1 before as it would never happen in normal production, not unless someone had been in there.
But D1 to D6 are freewheeling diodes to dissipate the back emf for when the brake is de-energized.
In normal operation they block current when the brake SSR is activated.
So reversing the supply to the complete circuit would fry them and if the internal SSR has no protection, probably fry them to as I expect they are just a high power Transisitor/Fet/IGBT component with isolation from the low logic control.
I moved the robot and controller, when I did that I unhooked the external IO. When I went to power back up the teach pendant wouldn't power up (I had to reinstall some jumpers... gets me every time!). I was troubleshooting that when I unhooked the wires at V1 to verify voltage. Definitely a sloppy mistake hooking them back up backwards.
The SSR's have built in reverse polarity protection. But D1-D6 burnt up when the SSR's closed providing a path to ground and in turn caused a large amp draw across the SSR's burning them up.
I got the replacement board today, I'm going to throw it in and power up. I'll ohm out the harness before I connect things up just to double check. But I'm 99% certain that reversing the polarity on V1 caused this problem.
But I'm 99% certain that reversing the polarity on V1 caused this problem.
100% for me, especially as you've described the 'before, during and afterwards' with you unhooking V1 wires.
I don't think you will have any harness issues, but whilst it's all disconnected, worthwhile giving them a once over just to be sure.
Definitely a sloppy mistake hooking them back up backwards.
Buddy, we've all been there and that V1 location is not the easiest either.
Troubleshooting is made difficult when you are removing things just to troubleshoot......easily done.
I did something similar with K3 replacement back in the day
This was a simple K3 coil failure, therefore simple in and out......but due to carelessness on my part I reversed the DC coming out of the power block via K3 to the big capacitor.
The result was spectacular - something to be proud of.
When you look at it, it doesn't seem possible.....but oh yes it was possible.
I did something similar with K3 replacement back in the day
This was a simple K3 coil failure, therefore simple in and out......but due to carelessness on my part I reversed the DC coming out of the power block via K3 to the big capacitor.
Appreciate the kind words, I bet that was something to see. That capacitor scares me a little bit lol.
I haven't got to test my 1GB board yet, I'm running into an encoder error on joint 6. Error 1553 and 1517. I have 5v supply at the encoder, I'm going to do some more troubleshooting on it Monday so see if the signal lines are OK or if its the encoder giving me fits. Any tips on troubleshooting encoders?
I think it's a 'rite of passage' to anyone tasked with troubleshooting and maintenance to experience a bad day or two at some point.
When it happens, it's better being a spectacular moment to remember with lot's of witnesses, then you can look as dumbstruck as anyone else, become famous in your company for turning a 5min job into a major breakdown, blame the pixies, turn around and then
Encoder error response errors can easily be proved on Z Series where it's a minor axis related error as they are all mounted in the same vicinity and encoders are available as spare items.
The encoder circuit is: Encoder=>1FG=>X3A/X3=>1GB CN2 (As below).
So you have a couple of choices but ALWAYS ensure:
- Don't rush, and be sequential and logical so that you can retrace your steps.
- Note the errors before you start, don't just read, many times people ignore specific error details.
- Make an all data file save before you start.
- No need to make any mechanical disconnection at this point.
- Power down before disconnection/reconnecting any harness.
- JTx abnormality errors will occur due to power cycle value comparison differences (ignore/resettable).
- Do not try and jog/electrically move any axis.
- Carefully read all JTx error messages and compare with your originals.
- Misreading could result in you going 'off piste' down a different direction.
- All you are doing is checking for encoder comms, actual positional data is irrelevant.
Option 1:
If you have a spare encoder, you can disconnect the harness and connect the new encoder.
- No need to mechanically remove/install at this point.
- JTx abnormality error will occur but you can ignore and is resettable.
- If the JTx encoder error persists, a disconnection between encoder and 1GB CN2 or 1GB fault is likely.
- If the error clears, then the encoder is bad.
- If you start receiving new errors, reverse what you have done and get back to where you started.
Option 2:
If you don't have a spare encoder, then you can swap encoder connections between minor axis.
- Making sure to connect both encoders and to not attempt to jog/electrically move any axis.
- JTx abnormality error will occur but you can ignore and is resettable.
- If the JTx encoder error moves joint, then you have a bad encoder.
- If the JTx encoder same JTx, a disconnection between encoder and 1GB CN2 or 1GB fault is likely.
- If you start receiving new errors, reverse what you have done and get back to where you started.
Obviously, this all carries risks and I cannot accept any liability.
If you make an all data file save first, as you are not mechanically removing anything, then as long as you return everything to as it was, then you all data file save could be used to restore any settings you may have changed during.....but as you can see, nothing above involves changing any data.
You are just checking for encoder comms remember, so no data should change in the controller.
Hope this helps.........
I swapped CN5 and CN6 (joint 5 and joint 6) at the 1FG board, same joint 6 encoder errors. So I disconnected X3 and X3A and was cleaning them when I noticed a piece of aluminum flashing in the pins at X3A. Cleaned it out, and no more joint 6 encoder errors.
Also, the new 1GB board was good, I was able to finally jog the robot.
Thanks for the help!