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. 
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.
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.
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.
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.
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).
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! 
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).
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!
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!
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.
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!
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
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
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
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.
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?
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.
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.
Display More
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.
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!
