Posts by brian.b

    I have a Cognex camera setup to take an image of a part and bring back offset values of x, y, and angular rotation.

    • TCP was taught with QTOOL ON and with the teach pendant. Tool pointer does track with the pointer used to teach the TCP.
    • Robot frame has been taught to the calibration grid that I used in the vision setup. I used the origin of the fiducial on the grid and went out x and y and taught those points to set up my frame. (cam1_frame = frame(cam1_o,cam1_x,cam1_y,cam1_o))
    • Created a master pick position and referenced the robot frame. (cam1_frame+master_pick)
    • Created a final pick instruction. (point final_pick = cam1_frame+master_pick+trans(x,y,0,a,0,0)
    • I execute the shift. (do lmove final_pick)

    Everything works pretty well when shifting in either the x direction, y direction, or both the x and y direction. However, when I try to do an angular shift, it does not shift correctly. My pick position will shift in the correction direction but if I tell the robot to shift 1 degree, it seams like shifts further then 1 degree.

    So I feel confident that my vision system is set up properly, what are some things that I can check/verify on the robot side of things to see why my x/y shifting is ok and why my angular shift is not?

    Please let me know if any more info is needed.

    I try to clear out the address of one or the other and cycle power. It boots back up and the address is repopulated and I get the duplicate address yet again.

    Another Ford spec...

    I couldn't find the description of the warning in the manuals since this is Ford specific. Essentially this alarm occurs when the clock from the controller cannot be synced with the time set to the network that it will eventually be tied to.

    If I wanted to clear the alarm, I need to turn the system switch "CLOCK_SYNC_HI_PRIO" off.

    Yea, the process took about 6+ hours to resolve going back and forth thru emails and what not until this got resolved. Once the tech support got a hold of an automotive guy at kri, it was solved fairly quickly.


    Yea we have two at our shop. From what I've seen and heard, it's quite the "project"...

    ---Here's what the tech had wanted me do:

    "1. Connect to the robot using CS-Configurator (Cubic-S software) and then go to Parameter Tree View -> Safety I/O -> Safety Input Settings and make sure the "Emergency Stop" setting is off."

    "2. In the controller, take a look at the X204 connector; it's located at the bottom of the card rack. I'm going to attach images to give you a reference, they're also from an E52 controller. Disconnect X204 from X204A, disconnect X204B from the motherboard, then plug X204 directly into the motherboard. The original wiring forces the input from the teach pendant deadman to go through the Cubic-S, and since you're not connected to safety or a PLC, the Cubic-S isn't passing it forward from there. Connecting X204 directly into the motherboard will mitigate this and allow the teach pendant deadman input to go directly to the motherboard."

    ---This was his initial thoughts prior to giving me instructions to fix the issue:

    "...Ford-spec controllers; this type of controller (E52) is setup so that when there are several robots in a cell, only 1 robot can be in teach before the robot moves. So if you have 2 robots in teach, it won't work. It's possible that you need that signal coming from the PLC to let the robot know it's the only robot in teach. I'm not sure yet, that's my best guess. It may also be possible that you can't jog without having the PLC and safety setup first, but I'm going to find that out."

    ---Now for my scenario, I never had Cubic-S setup to begin with and couldn't even connect for some reason. So, I went ahead and went to step two and that resolved my issue. Looks like how X204 was originally setup was to a Ford Spec and I wasn't quite ready with my cell build to allow that to properly work. Once that all gets setup, I can then just return X204 to the way it was.

    ---Cubic-S Version(???): CubicsVersionInfo,CSUV010333305 2013/01/11 12:00 70de:70de CSUW010333305 2013/01/11 12:00 c44f:c44f

    With the help of Kawasaki tech support, my issue has been solved!

    Long story short...

    From Kawasaki:

    "The original wiring forces the input from the teach pendant deadman to go through the Cubic-S, and since you're not connected to safety or a PLC, the Cubic-S isn't passing it forward from there. Connecting X204 directly into the motherboard will mitigate this and allow the teach pendant deadman input to go directly to the motherboard."


    That's the reasoning as to what was going on. Prior to that, he explained what to do to mitigate the bypass until I can get the PLC and safety setup. Since I'm "bypassing" something, I'm not sure if I should post directly on this thread what was swapped around inside the controller. This is temporary and I will be undoing these changes once I move further along.


    I appreciate your attention in trying to help me with this!

    1. E Controller (E52G)

    2. BX200

    3. Not 100% certain... This is a special project we're doing for a company and I had been told by Kawasaki that "all options are being given"

    4. Not configured

    5. I just want to move the robot. Maybe create some generic programs that will allow me to refamiliarize myself with this robot. Lower the arm, to allow the EOAT to be put on, etc. Nothing in full speed/motion, etc.

    I attached a picture as to what I believe is X8, correct? X7 is identified as the top connector and X9 is identified as the bottom connector. I'm only assuming the middle one is X8.

    I'm not sure if those four open ends on that plug is 5-6 & 7-8? Should those be jumpered?

    At this time, the robot is a stand alone unit and is not connected to a plc. I'm just trying to do some general things.


    So your feedback got us back on track. From what I was told, the PLC was trying to command the program start bit at two different points during program execution for whatever reason. Since we reference past jobs, most likely, this was a timing issue or a band-aid that got implemented on a previous job that didn't work on this project.


    R30iB+, two MH and one weld robot. All robots are having the same issue...

    I'm to the point where I'm integrating a cell and checking functions from the HMI. When I try to send the robot home or to a repair position, via PNS, the HMI/PLC properly calls up the correct PNS program and executes it. Once the program is complete in the robot program, the cursor returns to the top of the PNS program and it restarts the program that just completed for a second or two and then aborts out of it on its own.

    The only thing I know or can tell is that the program is not written to repeat itself and that when the program has completed, I can see that UO3 (Prg Running) and UO10 (Busy) turn off, the cursor returns to the top, and then the program runs again for a brief time before aborting out.

    Any thoughts? Is this a PLC/Controller processing issue?

    Any help would be greatly appreciated!

    I don't necessarily want to change the level but to disable it so that the shock sensor isn't being used at all.

    I went to that page and made it invalid and messed with the levels but I'm still getting the alarm.

    I am integrating a YRC1000 weld robot with a Fronius CMT welder and Fronius crashbox (clutch/shock sensor). As of now, the cell is being built but I have temp power to my controllers but not my welders. I'm assuming because of this, I cannot clear my shock sensor alarm and keep it from coming back after release and reset.

    My question is, is there a parameter that I can set to disable (temporarily) the shock sensor or do I have to jumper out the shock sensor inside the cabinet.

    If so, I do I jumper it out?


    I made a BG job to turn off step mode when the TP is off and the system is in auto by using variable $SSR.$SINGLESTEP. I tested it and I can see that the variable changes from 1 to 0. However, when I do this, the step mode indication on the TP (upper LH corner) does not turn off and remains yellow. Does anyone know if those indicators are tied to a variable or what I can do to get that to turn off when it is supposed to?

    To clear it, I have to turn the TP on, put it in step, and then back out of step in order to get rid of the step mode indication.