Posts by droth

    Is the second picture the inside of your upper or lower cabinet? Can you post a picture of the inside of the other cabinet? I'm not aware of any I/O options that interface on or near the CPU, but I have a couple of R-J3s with a similar looking upper cabinet, which is where my Model A I/O is mounted.

    Also worth noting, if I just nudged one of my ESTOPs slightly - enough to break contact yet not completely open the circuits, I could not reset the chain fault until I eventually pushed an ESTOP in completely and pulled it back out. Kind of weird and certainly annoying, but I finally have a robot waiting to be deployed that I have the rare opportunity to just play with and learn things.

    Yeah, testing complete, I was wrong. I think our problem is the actual ESTOP buttons we use. I found that the only way I could cause the chain fault is if I did not strike the button sharply and cleanly.

    Now I just have to convince the guys and gals on the floor that this is due to operator error. I'm sure that will go well...:grinning_face_with_smiling_eyes:

    Pretty much all of the robots I am responsible for suffer from recurring chain failure. I've never understood why and just accepted it as normal operation. But I was thinking yesterday and something finally occurred to me. There are 4 pairs of safety circuits that are jumpered out when a new robot arrives - ESTOP, Fence, Servo ON/OFF, and Servo Disconnect . In most, if not all of my work cells, I am only using 4 of these for my ESTOP and fence circuits. I leave the other circuits shorted at the TBOP connector.

    I'm going to test it to be sure, but this MUST be the reason for the chain failure, correct? Do all of these circuits have to open/close within the specified amount of time, or are the individual + and - pairs subject to their own specific open/close window?

    It starts making less sense to me the more I think and write about it, so I'm just gonna go try to test it. If anyone wants to chime in, feel free...

    And how long did you wait until you determined it 'froze?' If I recall, this is a pretty lengthy process. Not trying to be a smart@$$ because I struggled with this too, once upon a time. However, once I finally got it to start transferring files it was pretty straight and simple. Search the forum for S-10 software loading threads and read those over. Maybe you'll see something in there you are overlooking.

    That is what I keep suggesting, but the people who write the checks insist. I guess it shouldn't matter, considering it is not my money. It just seems like a waste to me. The collision sensor is only effective until an operator decides to crank the air up for a stiffer wrist, and that usually does not take too long.

    Does everyone here use a collision sensor on their robots? If so, what brand of collision sensor do you guys use? I swear, every time I order one the price has gone up around $200, and I am really starting to wonder if they are even worth it at this point. Putting a $1,500 collision sensor on an old used robot feels like getting full coverage insurance on my winter junk-mobile.


    I typically don't use Position Registers much, and still don't have a spare robot to play with, so maybe someone here just knows and can answer my question...

    I'm probably going to use some incremental motion (feed to position via laser sensor) to deal with part variation that I cannot eliminate from an earlier process. So, basically;



    PR[3,1] = PR[3,1] + 1

    L PR[x] 100mm/sec FINE


    So my question is this... can I alter a PR element by anything less than 1mm increments? Are tenths of mm allowed? 3mm eats up most of my tolerance, so it would be nice to make shorter moves. Thanks for your help!

    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.

    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.

Advertising from our partners