Posts by droth

To clarify... it was suggested that grease has penetrated the seal and is affecting the brake, not that I should add lubricant. And the brake does grab, just not instantly, hence the alarm. It holds just fine after that initial, short slip.

J2 axis on an M-16 robot is slipping when the brakes engage. The arm drops/droops for a split second before the brakes actually grab and stop/hold the robot as expected, but at that point, the controller has faulted for Stop Error Excess (SRVO-023).

My robot guru suggested grease on the brakes and sent me the procedure for replacing J2. No problem with that, but where exactly is the brake? Is it internal to the motor? Do I need to open the motor up to look for grease leakage? I am not completely mechanically inept, but neither am I a servo surgeon. I've delayed the inevitable by increasing the servo_off_time variable, but I am going to have to address this sooner than later, I guess. Just trying to decide if I should order a replacement while I have this one repaired or if this is something I can handle in house with minimal down time... any advice is welcome.

I highly doubt anyone is going to recommend you use anything other than the designated safety signals for your ESTOP chain.

This is slightly off-topic, but does anyone know what the first version of HandlingTool w/ BGLogic is? I have a couple of R-J3iBs with BGLogic, and I have several other R-J3s without it.

Maybe you should write a sort of MAIN program to run as your autoexec and then set up one of the USER buttons to CALL or RUN a conveyor program. I feel like you are going to run into issues unless your autoexec has more flexibility than just running your conveyor...

I just finished up a cell with 2 overhead controllers. We brought the ON/OFF buttons down with the key switch for remote access.

FWIW, though, I get a lot of chain faults in this cell, and part of me wonders if the remote key switch is the problem here. I get occasional chain failure on most, if not all, of our R-J3s, but none as often as these with the overhead controllers.

You might want to set a HOME position if you care to use the UOP signals...

You can record a HOME position in the reference position menu, which I believe if you press:

MENUS --> SETUP --> (F1)TYPE --> Ref Position

Record your HOME position as Ref Position 1, give it a tolerance for joint angles if you like, and configure I/O to turn ON/OFF when at the reference position.

I don't understand. If it works, it works, right? Why would it be unsafe? If it wasn't intended to work on an R-J3iB cabinet, it simply would not work.

Just guessing here, but is it possible to run a program in BG that says something like;

IF $TP_DEFPROG = X, DO[x]=on

IF $TP_DEFPROG = Y, DO[y]=on

IF $TP_DEFPROG = Z, DO[z]=on

I don't have an idle robot to try this on, and it has potential to eat up a lot of outputs, but from what I've read above, this sounds more in line with what you want to accomplish...

Probably something to do with dual channel safety circuits...

Can't remember who put this glorious troubleshooting guide together, but here is everything it contains on SRVO-068. I think the last solution, the grounding clamps, is particularly interesting, considering all of the stuff you have replaced already... Wish I could be more help to you. Good luck.

Begin SRVO-068

SRVO-068 DTERR alarm (Group : i Axis : j)
(Explanation) The serial pulse coder does not return serial data in
response to a request signal.
(Action 1) Make sure that the RP1 connector of servo
amplifier (motor side) is connected tightly.
(Action 2) Check that the shielding of the RP1 cable is
grounded securely in the cabinet.
(Action 3) Replace the pulse coder.
(Action 4) Replace the servo amplifier.
(Action 5) Replace the RP1 cable.
(Action 6) Replace the robot interconnection cable (for the
pulse coder).

I have a DTERR alarm active as another problem.
Reply #1
The driver chips on the CPU mother board may be bad! They can be easily replaced!

Reply #2
Would these be effected by a srvo193 SVON error?
Racermike123
Reply #3
No the driver chips protect the CPU from damage if the device that is being turned on by the output is shorted.
They are mounted to the CPU and you can tell by looking at them that they are burned.

Reply #4
So I found the smoked drive and stole a CPU board out of another controller. Now I have a DTERR alarm. These things are driving me nuts.

Reply #5
The driver-chips are two Toshiba TD62107 drivers.
They are located right behind the blue CRM10 and CRS1 connectors, and they sit in sockets, so they are very easy replaceble.
Reply #6
The DTERR error is pulse-coder related.

Is there an extended axis, if so, check if it is connected OK.
In case of a second-hand robot, check if there was an extra axis that is not connected now.

Check your cables and connectors.

Change the SIF-module of the axis involved with another SIF-module, and look if the error changes as well, if so, replace SIF-module.

Do the same with the DSM-modules.

If that all don't work, replace pulse-coder.

Reply #7
Gentlemen. Thank you for the information. The driver was shot. I tried to just replace the whole cpu and received the DTERR alarm on all axis's. So I replaced the driver on the original cpu and reinstalled. All is well although this DTERR alarm has been dogging me for a month now. These are used robots and controllers and I can power them up one day and all is fine. The next day or the next time I grab the pendant to teach it will spring the DTERR.

Reply #11
DTERR alarms can be caused by poor connection of the shield on the RP1 cable to ground at the controller.

Reply #12
Ok, cool, I will check that.

Reply #13
Yes the shield clamps were all loose in the cabinet. Tightened them and problem cleared. You people are life savers. I thank you.

End SRVO-068

Thanks, SHIFT_Lock. I did not have that extensive of an explanation. We swapped E-STOP units this morning with another M-16. He hasn't been running long enough to think we've solved the problem, but so far, so good.

Thanks, but this LED window is on the amplifier. Top left corner. The circuit breaker that sits between the transformer and the redundant E-Stop board is tripping. Usually, just the 3-pole breaker (QF2), but sometimes, the single pole breaker (QF3) for auxiliary axis brakes trips out too. Of course, we aren't using any auxiliary axes, which leads me to believe the transformer is bad...

Does anyone know what an error code "4" means on the amplifier board LED? This is on an R-J3iB/M-16iB. Problem was sporadic at first but ever-increasing in frequency. Can't find any loose wires or connections. Voltages all look good... SRVO-136 is the TP fault that shows, but I am much more concerned about that 4. I think the DCVAL could be a symptom rather than the problem.

Unfortunately, I need to revive this thread. I sent this controller back to our vendor. They found a 'loose connection.' I got it back and let it run idle for several hours, and sure enough, it seemed like the problem had been resolved.

Fast forward a couple months, and I've placed the robot (M-16i) and controller (R-J3iB) into the work cell. There are actually 2 identical robots in this cell, and robot A has no problems. Robot B, however, is once again throwing SRVO-043 right at startup... unless I start with the key switch in T1 or T2 with the pendant turned on. In fact, I can jog the robot around all day long if I boot in teach mode. But as soon as I turn the key back to Auto, I get SRVO-043 DCAL on axes 1 and 2.

I've gone through all of the suggested remedies from the manual. I've swapped just about everything I can swap between these 2 robots to no avail. I've re-seated every connector I can find. This is driving me crazy.

Could this be a software glitch? Can I swap CPUs between these 2 robots? Maybe there is a problem with the backplane? If anyone has any suggestions, I'd love to hear them...

OK, motor replaced, jogging like a champ, but as expected, mastering has been a nightmare. Maybe someone can help. Again, it is an RH controller, Karel 2.23.

So, I follow the mastering procedure in the manual, and I've calibrated, both at the zero position(s) and 'near' my home position. I tried calibrating near home due to the advice from an old thread on this forum.

Either way, I get the same results. The axes jog correctly in joint mode. No surprises there. But if I jog in world, or any other coordinate system for that matter, the axes are all screwy. Z is sort of close to where X should be, but + runs slightly uphill and to the right rather than moving the TCP vertically. X and Y are just as screwy.

If I try to run the HOME program, the robot faults out due to over travel on axis 2, and the posture is nothing like it should be. I am at a complete loss here. If anyone has a suggestion, I would love to hear it. Is there a file I need to save after mastering or something? After calibration? This is driving me crazy!

Like the dummy I am, I must not have had the motor disconnected from the control when I checked resistance through the switch because today when I checked again I got something crazy, like 187 ohms! Needless to say, I am now waiting on a call back to verify that my supplier does indeed have one of these motors on the shelf ready to buy. If not, I guess I can always eBay it. Pretty cheap at less than $400...

I haven't even gotten to the fun part, yet... re-mastering the old robot. I took a test run of connecting my laptop via null modem cable and terminal emulator software the other day. Connection went surprisingly smooth, but it has been quite a few years since I actually had to do anything with this robot. We shall see.

I don't remember what they were at the cable ends, but they were just slightly less than an ohm at the motor. I'll check them again when I get the amplifier back and let you know...

Yes, 8 and 9. I checked those pins on all the CF9x and got similar readings. I ended up sending the amplifier to our local(ish) servo shop since we were already making a trip. Seems like a long shot, but I don't see a problem anywhere else, especially after swapping axis control cards... I guess I'll find out soon enough...

Thanks Skooter. Resistance looks good, or at least comparable to the rest of the CF connectors. I have a pair of these S-10s, so I did swap axis control boards. The alarm stayed with the original robot.

Looking at used amplifiers on eBay... How important are the last few digits in the part number? For instance, I need to replace an A16B-1100-0330/05B. Will my robot work if I put an A16B-1100-0330/04B in it? Significant potential savings on parts for an OLD robot...