Posts by brian.b

    The O element. Visually, not actually, I want to determine the orientation of the tooling as if the suction cups are square and overhead with the part it's picking up. Right now, the blank is coming down the conveyor parallel with the conveyor. If I have a blank come down perpendicular to the conveyor or anywhere in between, I want to adjust my general position or skip it in general depending on how the part comes down the conveyor (cycle time purposes). I use mp2[4]+r2 (r2 = rotation from camera offset) to apply the actual offset of the pick so I'd figure I can use that to determine my needs.


    Most of the program is "model" dependent that relies on one general program to do numerous jobs. I can't have a dedicated job for each one either.

    Kwakisaki:


    The way I have the programs set up at this time, everything working properly and with no issues. It currently goes to:


    Pounce

    General Position

    LAPPRO "above final_pick"

    LMOVE "final_pick"


    Since "final_pick" can be different based off of which part I'm running (J6 could be anywhere between 0` and 180` give or take), my goal is to take a specific value of "final_pick" (mp2[4]+r2) and determine based off of that value if I need to utilize the "general position" or go straight to the LAPPRO.


    Alexandru wrote out what I was thinking, I'd just have to test it to see if it was that simple.


    Thanks for everyone's input!

    I'm looking for help in creating an IF/THEN statement that involves the current location of a real variable...


    Currently what I use in a simple example:


    1. "Move To Pounce Position"

    2. Block Step (Go to above general pick position). This is generally a meter or so above actual pick position.

    3. DECOMPOSE mp2[1] = master_pick2[1]

    4. POINT final_pick2 = TRANS(mp2[1]+x2,mp2[2]+y2,mp2[3],mp2[4]+r2,mp2[5],mp2[6])

    5. LAPPRO final_pick2, -100

    6. LMOVE final_pick2



    What I want to do is determine the current value of mp2[4] based off of the master_pick position and adjust the J6 axis if it's within a certain range. The purpose is to decide if the robot needs to go to is "above general pick position" or go straight to its LAPPRO position if J6 does not need to move at all or that much. I will have dozens of different pick positions stored in a pick program, so I'd like to have the flexibility to make the decision to skip the block move if it isn't necessary.


    So in one form or another, this is what I'm trying to accomplish, I just don't know how to write it.


    1. "Move To Pounce Position"

    2. DECOMPOSE mp2[1] = master_pick2[1]

    3. POINT final_pick2 = TRANS(mp2[1]+x2,mp2[2]+y2,mp2[3],mp2[4]+r2,mp2[5],mp2[6])

    4. "IF mp2[4]+r2 is < 130.00 OR mp2[4]+r2 is > 190.000 THEN; GO TO GENERAL ABOVE PICK POSITION

    5. Block Step (Go to above general pick position). This is generally a meter or so above actual pick position.

    6. END

    7. LAPPRO final_pick2, -100

    8. LMOVE final_pick2


    Simply put (I think), I want the robot to go straight to its LAPPRO move if the orientation of J6 does not change from its pounce position to the final pick position. If J6 needs to move in excess of a certain amount of degrees, I want the program to execute the block step.


    Any suggestions?


    Thanks!

    We originally started at 0.2 and then changed it to 0.1 and then to 0.05 just to see if this would hurt or help us. We didn't have any issues at this point and I'm comfortable in saying that each robot is getting its information from the PLC when it needs to. So I plan on keeping it at 0.05 for the time being.


    Maybe I am 'handshaking/echoing and my scan time isn't a factor at this point.


    Thanks for your help!

    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.


    ericwiz:

    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.


    Anyways,

    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.


    Thanks

    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.


    Thanks!