1. Home
    1. Dashboard
    2. Search
  2. Forum
    1. Unresolved Threads
    2. Members
      1. Recent Activities
      2. Users Online
      3. Team Members
      4. Search Members
      5. Trophys
  3. Articles
  4. Blog
  5. Videos
  6. Jobs
  7. Shop
    1. Orders
  • Login or register
  • Search
Everywhere
  • Everywhere
  • Articles
  • Pages
  • Forum
  • Blog Articles
  • Products
  • More Options
  1. Robotforum - Support and discussion community for industrial robots and cobots
  2. Members
  3. Jesper

Posts by Jesper

  • iRvision precision

    • Jesper
    • May 23, 2019 at 6:31 PM

    And the 'lagg' problem has been solved.
    The solution was to put the LINECOUNT and the SETTRIG lines in between the RUN_FIND and GET_OFFSET:

    VISION RUN_FIND 'LETTERS'
    LINECOUNT[1]=R[1]
    SETTRIG LNSCH[1] R[1]
    VISION GET_OFFSET 'LETTERS' VR[2] JMP LBL[99]
    PR[5] = VR[2].OFFSET
    SELBOUND LNSCH[1] BOUND[1]

    I can now run it on a speed of 9. :bravo:

  • iRvision precision

    • Jesper
    • May 23, 2019 at 6:26 PM
    Quote from HawkME


    Make sure the correct user tool and user frame is selected. I would do it in User coord to make it easier to square up with your table/sheet of paper. Do not rotate in Joint coord, because joint mode is independent of your TCP. Looking at your picture it will probably be jogging rotation about Z (the z rotation or J6 button on the TP).

    Thanks! The gripper seems to be setup correctly.

  • iRvision precision

    • Jesper
    • May 21, 2019 at 5:22 PM

    Good Tip, I will try that!
    Does it have to be in USER Coord? Or can I do it in JGFRM aswell and then rotate joint 5 (last joint)?
    I don't really know what USER coord is for.

  • iRvision precision

    • Jesper
    • May 21, 2019 at 4:41 PM
    Quote from Fabian Munoz


    Dutchbrother
    I merged your two posts.

    Regarding your issue.
    I work with iRPicktool which integrates vision and line tracking, Anyway, on your comments I never see you mentioning how do you deal/integrate the pulse counts to the vision. I think that's the problem, somewhere in the tracking and vision you are missing the link


    Yeah sorry, the reason I made a new post is because it's regarding a different problem.
    The 2nd problem (with the blocks being out of the gripper center) occured when I adjusted the program for tracking:

    UTOOL_NUM=1
    UFRAME_NUM=8
    LINE[1]=ON
    J P[1] 100% FINE <-- random point 'home position'
    CALL GRIP_OPEN
    LBL[99]
    VISION RUN_FIND 'LETTERS'
    VISION GET_OFFSET 'LETTERS' VR[2] JMP LBL[99]
    PR[5] = VR[2].OFFSET
    LINECOUNT[1]=R[1]
    SETTRIG LNSCH[1] R[1]
    SELBOUND LNSCH[1] BOUND[1]
    CALL TRACKING

    And I made a seperate program 'TRACKING' that includes only the tracking part.

    J P[2] 40% FINE Offset,PR[5] <-- position above the block (with the position register offset)
    L P[3] 100 mm/sec Offset,PR[5] <-- grip position (with the position register offset)
    CALL GRIP_CLOSE

    Within the program details of this 2nd program I can enter a line tracking schedule which includes the encoder count.
    I can see that it takes that into count, because it is always grabs the part, it just grabs it further apart from the center when I speed up the conveyor.

  • iRvision precision

    • Jesper
    • May 21, 2019 at 4:00 PM
    Quote from TFROK


    If the application frame is set to 0 check to make sure the XY of the calibration grid matches the world frame of the robot.

    I'm using the grid calibration user frame for this project.

  • iRvision precision

    • Jesper
    • May 21, 2019 at 3:57 PM
    Quote from HawkME


    When you switch offset methods you have to reteach the all points that are used with the offset. Looks like just P[2] in the code you posted.

    The other thing is to make sure you have the correct UT and UF selected. You have User Tool 1 selected; does that correspond to the center point of your gripper?

    First I made a new reference, played the run_find & get_offset and then I reteached the point with the touch-up method.

    The User tool I used is Utool=1 which was already set up for the gripper before I started working on it. I don't think that they set it up wrong, but is there a way to test it? It's a gripper so I can't really move it around 1 point.
    And the User frame I used is Uframe 8. I created this user frame when calibrating the camera (without moving the calibration grid).

  • iRvision precision

    • Jesper
    • May 21, 2019 at 2:12 PM

    I've been trying the process with linetracking now (conveyor on).

    Everything is working good, but when I change the conveyor speed this happens when picking up one of the blocks:

    Stationary:

    Speed=2

    Speed=4

    Speed=6

    Can this be caused by the exposure time? (maybe to high)
    Or is this lagg that can't be fixed? Because if that's the case I will need to run the conveyor on the same speed everytime and adjust the offset.

    Thanks in advance! :help:

  • iRvision precision

    • Jesper
    • May 21, 2019 at 1:48 PM

    First of all, thanks for your extensive explanation. It's starting to make sense now.

    I tried using Voffset, however when I do that the robot went completely out of place (far out the FOV).
    And the Gripper is set up correctly.

    So it must be the calibration then, because I tried jogging the (self made) pointer tool in TOOL COORD and the pointer is off a couple of milimeters. Especially when rotating around the z-axis.
    Maybe I should advice the owner to buy a professional pointer.

    For now I just snapped the square block on 4, 90 deg, angles.
    This seems to work out pretty well, but comes with complicity when making a program (orientation requires different ID's).

  • iRvision precision

    • Jesper
    • May 20, 2019 at 8:24 PM

    I have a fanuc M-430iA with a Fanuc R-30iA controller and a sony xc-56.
    I'm trying to set up a vision system where the robot picks up wooden blocks (with different letters on it) from a conveyer belt and puts them into a specific order to form a name.
    To test some basic things I thought I'd test the process without the belt moving to make sure the camera can find the blocks and that the robot gets the correct locations and can pick them up.

    The program looks like this:

    UTOOL_NUM=1
    UFRAME_NUM=8
    J P[1] 100% FINE <-- random point 'home position'
    CALL GRIP_OPEN
    LBL[99]
    VISION RUN_FIND 'LETTERS'
    VISION GET_OFFSET 'LETTERS' VR[2] JMP LBL[99] <-- store offset in vision register
    PR[5] = VR[2].OFFSET <-- move offset from vision register to position register
    J P[2] 40% FINE Offset,PR[5] <-- position above the block (with the position register offset)
    L P[3] 100 mm/sec,PR[5] <-- grip position (with the position register offset)
    CALL GRIP_CLOSE

    Point 2 and 3 are touched-up with the reference position.

    What happens is:
    The letters get recognised, and everytime I move the block within the FOV withouth rotating, it will pick up the part (nearly) perfect.
    However when I rotate the part in any way, the position will be off (in x, y, and rotation) but still around the FOV.

    I used one of the wooden blocks (with a nail in it) and lined it up for calibration, but the nail is not 100% straight.

    Many people have told me that the tool frame and TCP are very important when calibrating.

    But I don't really get the science, doesn't the origin of the part get lined up with the TCP when using the vision system?
    So when the part rotates, how can the origin move away? Because non rotated parts are picked up at almost all locations.

    Can this problem get caused by the nail not being completely straight?
    And how can the positions only be off when the part is rotating?

    Thanks in advance! :help:

  • Pulsecoder conveyor defect?

    • Jesper
    • May 17, 2019 at 9:18 AM
    Quote from Nation


    Yep you are correct. The six axis amp gets placed into the line tracking card, and the jumper goes from the card to where the amp used to be.

    Here is what the manual says about it:
    Fiber Optic FSSB Connector
    When a line tracking interface board. A2OB-8101-0421 (Wide mini slot) is used The original fiberoptic FSSB cable connector that connects to the COP10A connector of the main CPU board should be moved to COP10A of the line tracking interface board. The additional fiber optic FSSB cable should connect COP10A of the main CPU board to COP10B of the line tracking interface board.

    Thanks for the help man, that was the problem!

  • irVision Setup / Fanuc manual

    • Jesper
    • May 17, 2019 at 9:02 AM
    Quote from I3ooI3oo


    Personally I have had that issue many times when using GET_OFFSET, I prefer to use POS_FOUND and just move there. I also make sure my userframe and my camera calibration are exactly the same. I think the problem is it is offsetting the tool frame not the userframe.

    I didn't get it to work yet, how can i use POS_FOUND? I cleared the found positions in VR[1]
    This is what i thought:

    VISION RUN_FIND 'EXAMPLE'
    VISION GET_OFFSET 'EXAMPLE' VR[1] JMP LBL[99]
    PR[7]=VR[1].FOUND_POS[1]
    J PR[7] 50% FINE

    Is this the right way? because I can't get it to work.

  • Pulsecoder conveyor defect?

    • Jesper
    • May 14, 2019 at 4:26 PM
    Quote from Nation


    I've edited your posts so they are not nested quotes within quotes with responses in order in increase readability.

    Is your FSSB interconnect cable from the line tracking card to the CPU missing? I had that happen once, and it produced similar symptoms.

    My bad for the quotes, but that might actually be the case.
    This is how it looks right now (The pulse coder is connected to the JF21 port):

    Is it correct that the cable that is now in the left cabinet (C0P10B) should go to the C0P10A of the line tracking cabinet?
    And that the short cable that is now going nowhere should go from the C0P10A of the left cabinet to the C0P10B of the line tracking cabinet?
    It would be great if this is the problem, thanks!

  • Pulsecoder conveyor defect?

    • Jesper
    • May 14, 2019 at 9:11 AM
    Quote from Dutchbrother

    Yes, I've tried Them all (with cold starts) but it remains zero.

    EDIT: one 'absolute' changes from like 7427631 to 7427632 to 7427630 etc. but it does the same thing when it's disconnected and is not affected by any rotation

  • Pulsecoder conveyor defect?

    • Jesper
    • May 14, 2019 at 9:09 AM
    Quote from Dutchbrother

    Yes, I've tried Them all (with cold starts) but it remains zero.

    EDIT: one 'absolute' changes from like 7427631 to 7427632 to 7427630 etc. but it does the same thing when it's disconnected

  • Pulsecoder conveyor defect?

    • Jesper
    • May 13, 2019 at 10:23 PM
    Quote from stare284


    Remove the encoder from the conveyor and turn the shaft by hand in both directions to see if the value changes.

    I doubt that it would change anything because the Shaft is rotating, but I Will give it a try

  • Pulsecoder conveyor defect?

    • Jesper
    • May 13, 2019 at 10:22 PM
    Quote from Witty


    Have you already tried all the other "Encoder Types" just to make sure that's not where the problem is?

    Yes, I've tried Them all (with cold starts) but it remains zero.

  • Pulsecoder conveyor defect?

    • Jesper
    • May 13, 2019 at 11:11 AM

    I have a fanuc M-430iA with a Fanuc R-30iA controller.
    While setting up a new line for visual tracking I was testing the pulse coder that is attached to the conveyor:

    I think this is an incremental encoder, but I'm not sure.

    So these are my settings:

    Now my thought was that when I press Encoder Enable and move the conveyor, the Current Count should change.
    But that's not the case, it stays 0.
    Does that mean that the pulse coder is broken?

  • irVision Setup / Fanuc manual

    • Jesper
    • May 10, 2019 at 4:37 PM
    Quote from I3ooI3oo


    Personally I have had that issue many times when using GET_OFFSET, I prefer to use POS_FOUND and just move there. I also make sure my userframe and my camera calibration are exactly the same. I think the problem is it is offsetting the tool frame not the userframe.

    Thanks for your reply! I will try using POS_FOUND first thing monday.

  • irVision Setup / Fanuc manual

    • Jesper
    • May 10, 2019 at 4:34 PM
    Quote from scotty

    You are not missing se-up. When you have conveyor tracking system, you are not able to use regular single-view visual tracking. Unless you have camera set-up as regular iRVision 2D. Send me a pm with you email, i will send you conveyor tracking manuals.

    That explains alot and that would be great!
    I've send you my email in a pm.

  • irVision Setup / Fanuc manual

    • Jesper
    • May 10, 2019 at 11:41 AM
    Quote from andreic


    Hello,
    So some thoughts about your problem:
    1. If you don't use tracking, take it out (do a normal calibration - Grid Pattern Calib.)
    2. After calibration I would make 2D Single View Vision Process to test the system. Teach a circle on a grid and do tests.
    3. What type of vision process are you using? If you are not using tracking use a simple 2D Single-View Vision Process. Make sure Offset Frame is correct. It can be your calibration grid uframe, for example.
    4. Check if proper tool is used.

    Display More

    I've tried to do the grid pattern calibration, however the only tool that I can choose is the : camera calib. for vis. tracking
    Same counts for the vision process, the only one I can choose is the: Single-view visual tracking.
    Am I missing a setting somewhere?
    Thanks for the response!

Advertising from our partners

IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Advertise in Robotics
Advertise in Robotics
  1. Privacy Policy
  2. Legal Notice
Powered by WoltLab Suite™
As a registered Member:
* You will see no Google advertising
* You can translate posts into your local language
* You can ask questions or help the community with your knowledge
* You can thank the authors for their help
* You can receive notifications of replies or new topics on request
* We do not sell your data - we promise

JOIN OUR GREAT ROBOTICS COMMUNITY.
Don’t have an account yet? Register yourself now and be a part of our community!
Register Yourself Lost Password
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on Google Play
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on the App Store
Download