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...
I have an old S-10 with R-H controller that is throwing a 4007 Motor Overheat 004 alarm. My manual conveniently skips from error code 4006 directly to 4008, with no mention of 4007. The alarm will not reset, and this occurs right after startup, so I have a hard time believing that anything is actually overheating.
Does anyone have any suggested course of action for this dinosaur? Any details as to the cause or remedy at all? Thanks in advance for your replies...
Does anyone have any experience with MiR or Fetch or any other autonomous robotic vehicles? Would really like to get a ballpark figure on pricing without having a half hour discussion about workflows and usage plans. No sense in making plans for usage if management determines the cost is way too high. Why can't sales people seem to understand that sometimes, the interest level is directly related to the price, and that time has real value?
I have a pair of R-J3s that have BGLogic. Can't remember which HandlingTool Rev. it became available, but 6.4 and later, for sure has it. And I'm pretty sure you can configure a program to ignore pauses in the details screen. I don't know about the abort requests.
Once again, good stuff, thank you. I think your option 3 is my best (maybe only) bet. The software on this robot, like most of the 12 I tend to here, is pre-BGLogic, and like I said, the controller is out of the operator's reach. But we count on our operators to be pretty comfortable with the TP, so they should be able to apply this method without much trouble...
Excellent. Thanks for the help Rob_Eng_13. That was exactly the issue. Now, maybe you can enlighten me as to how that first program made its way into that variable in the first place? I didn't put it there and I can't imagine anyone else here would have either.
Anyway, I would like for the operator to be able to select the program he wants to run from the TP, hit the START button that I've mapped to the User Input for PROD_START, and go on his merry way. Is that possible or do I need to create a MAIN program to run on START. I could do that, but that likely means having to edit the CALL or RUN command in the MAIN program every time we need to run a different part...
Otherwise, I guess I could switch the robot back over to local (SOP) control. Unfortunately, the controller is mounted above the work cell and inaccessible to the operator. Can I use the SOP with UOP enabled? Or can I map the START button on the controller to a digital input or do I need to physically wire that START button down to my operator's button bank?
I guess this setup is slightly different than the work cells I've put together in the past, but it seems like it should still be manageable...
