I solved the problem. I loaded a backup to ROBOGUIDE and saw, that my space was wrong aligned. I didn't check the user frame good.
Important for someone else having a similar problem: the DI needs to be set and if it is not ON the robot will HOLD when entering the space.
To avoid see attachment.
It looks like you want to kind of vibrate the part to make it easier fit into the box, right?
I already looked for this feature but could not find it too. It would help placing my parts on a pretty tight fitted holder.
I solved my problem with the folowing idea:
1: SKIP CONDITION $MISC[1].$HPD_TRQ[3]>R[1:Torque AX 3] ;
2: ;
3: LBL [1:Placepoint] ;
4: L PR[1] 5mm/sec FINE Skip,LBL[2] ;
5: JMP LBL[3] ;
6: ;
7: LBL[2: Collision] ;
8: PR[2]=LPOS ;
9: PR[2,3]=PR[2,3]+100 ;
10: L PR[2,3] 100mm/sec FINE ;
11: JMP LBL[1] ;
12: ;
13: LBL[3: End] ;It will cancel the movement when the torque in axis 3 is too high (Define the torque in R[1:Torque AX 3]), moves up a bit and tries the same movement again.
Hope this helps!
Hi
I need to define a new space for a LR Mate 200iD 7L. In my program I want to use this space in a IF statement to check if the gripper is in this space or not. I can't really find useful information in the manuals to set it up. Here is what I did:
- named a new space
- defined a DO
- defined the space area
- enabled the space
Now when I move to the space with the robot, the DO is still not changing its value.
What am I missing?
Best,
Dominik
Hi
I do not have any of these robots, but I checked them out for a future project. As far as I know the main difference is, that the KUKA robot is way further developed especially in different connection interfaces to for example a SPS. This is for sure because UR is a pretty young company and thus not all bus systems are already developed.
Check out this ebook from Robotiq about different Co-Bots, you will find a lot usefull comparison data there:https://blog.robotiq.com/collaborative-robot-ebook
Hope this helps!
For the first try I connect independently. If there will be a switch is not sure yet. First I want just the independent version.
Hi
I got five Fanuc robots and the goal is to connect them all to one network for FTP datatransfer and accessing the Robots Website. Later maybe also communication between the robots is an option.
I tried to setup a direct connection to my computer, succeeded with two robots but now I'm struggling with the third. Here is what I did:
Connect Ethernet in the robot controller to my computer
Computer has IP 192.168.250.XXX
In the robot setup I changed the TCP/IP settings to:
[hr]Robot Name: Robot 1
Port#1 IP addr: 192.168.250.YYY
Subnet Mask: 255.255.255.0
Board address: ---
Router IP addr: *************
(no Host Names)
[hr]
Then I clicked the button ">" then "INIT" and "YES". With the first robots it worked to access then on my computer the website by entering the IP of the robot: 192.168.250.YYY
Do I need to configure something else? Pinging is also not working.
Thanks so much! This is what I was looking for! Just today I printed out my code for a better overview (Tip for everyone that did not know: also the points are printed when you do ASCII export) and saw that some of the points are FUT 000 and some are FUT 001. The options for F, U and T I already tried to flip but I saw fast that this is not what I was looking for.
I researched for short about this settings and found an interesting post where everything is well explained here: https://www.onerobotics.com/posts/2013/the…ix-axis-robots/
Yes, this I know. But how so, that the JOINT movement (assuming we do a complete joint movement) and a LINEAR movement (also complete linear without WJNT) behave different?
Is this different behaviour only because the axis are controlled different?
I thought that the joint motion has absolute angles stored. Meaning you could also do a 360 degree turn with a tool for example.
On the other hand the linear representation has just the end point stored, which means, that the best and fastest way is driven.
Am I right with this?
That's right, they just touchup the PR and ask themselves why the correction is not working.
...
What I have done at other places is to make a diagram of the part, and the PR's associated with that part. Then the guys/gals know exactly which PR is where.
...
I guess you mean a diagram of the points right?
The WJNT (Writs Joint) Option worked out. This is exactly what I was looking for. Everything works seamlessly. Thanks a lot!
For understanding:
How are the points stored in the program? If I store them with the LINEAR option, I only see the cartesian coordinates when checking the point. When I store them with JOINT option, I see the joint angles.
But now when I do WJNT, it is basically a linear point but still the joint angles of the wrist are saved somewhere.
Can someone explain me this?
I actually do first two TOOL_OFFSETS and then the point itself. The first TOOL_OFFSET is with a JOINT motion. The others are Linear. So in the end the point is stored in cartesian coordinates of a user frame. Shouln't this work?
Hi
I am teaching a program and got troubles with limits. Going to a point that is 180° turned from the home position, is done sometimes differently by the robot and I can not figure out how to set the points right. If the robot accesses this point turned into the wrong direction, the next points will give a limit error.
How do I force the rotation direction for accessing a certain point?
Reteaching points should hopefully stay a rare functionality. But we are often teaching new parts to our system and this is why I made a basic structure for our program which can be copied. The only thing that needs to be changed then for a new part is that the points need to be reteached. This procedure should be made as easy and fast as possible.
Often we also see only after a certain amount of time, that one point is not exactly how we expected and ends sometimes in errors. Like this we can easily reteach this point.
The last question from my post was actually a bug in the tool chosing routine. So its solved.
This is acutally the way the program is built up till now. The thing is, that with this structure it can be difficult to teach the points. Our workers are usually running the program until the robot is standing in a certain position and stop it then to watch where the coursor stoped. They tried to teach there but usually this was a PR. So the changes did not hold for long 
This is why I came up with a programming section like the following:
42: !TEACH POSITIONS ;
43: R[57:Teach Point 1]=14 ; -> change here
44: R[58:Teach Flag]=1 ;
45: PR[30:DynTeachPoint]=PR[100:NULL] ;
46: PR[30:DynTeachPoint]=P[R[57]] ;
47: CALL TEACH0024 ;
48:L P[14] 5mm/sec FINE ; -> change here
49: PAUSE ;
50: R[58:Teach Flag]=2 ;
51: PR[30:DynTeachPoint]=P[R[57]] ;
52: CALL TEACH0024 ;
53: PAUSE ;
54: R[58:Teach Flag]=3 ;
55: R[59:Teach Point 2]=R[57:Teach Point 1]+100 ;
56: PR[30:DynTeachPoint]=PR[100:NULL] ;
57: PR[30:DynTeachPoint]=P[R[59]] ;
58: CALL TEACH0024 ;
59:L P[114] 40mm/sec FINE ; -> change here
60: PAUSE ;
61: R[58:Teach Flag]=4 ;
62: PR[30:DynTeachPoint]=P[R[59]] ;
63: CALL TEACH0024 ;
64: PAUSE ;
With this procedure one full motion can be done without searching it in the full program. The user just has to change the position numbers where I marked it with "-> change here". The program TEACH0024 has different prepositions and points to do depending on the R[58:Teach Flag].
What do you guys think about this? Is this a common thing to solve this issue like this?
Unfortunately I ran into a different problem now. Somehow the points after line 54 are showing me the error "position not reachable" after a tool change. If I reteach, the position data is exactly the same but then everything works perfect. The used tool is the same for all four motions but only motion 3 and 4 are giving me the error. Do you have an idea where I could look for solving this error?
Hi
I am pretty new to Fanuc programming and I'm now on an existing program which should be improved. The program actually handles pretty easy pick and place motions which are executed in different loops and also storing points in position registers during the program.
With this structure it is the problem, that the guys that work on the robot can not easily re-teach points. Their procedure is to let the robot run and stop at the point where they want to reteach. Unfortunately this is often on a position register, which they can not touchup.
So my idea is to write some kind of a teach program, where they can go from point to point and reteach these. The problem is that I do not have enough position registers to copy the points from the "teach"-program to the "run"-program. Is there another way of solving this problem or a smoother way of doing all this?
Thanks for all your answers!
The camera slider has rubber bumpers on the left and rigt side and one of them fell off. We actually figured it ojt because if the clicking noise that appeared. We just added this bumpers and lowered the speed of the slider by reducing air pressure.
We will check the silicon bead idea! Thanks!
Sorry for the late answer. As you can imagine, it was a hard time when the system was not on production. But now we figured it out what was the error and fixed it!
As the camera was on a slider moving between two positions it untied the lens of the camera from vibrations. Of course this gave a new random offset whenever the camera moved to the new position.
So always check also hardware. Especially when the error is random.
Thanks anyways for your help Fabian and SHIFT_Lock!
The parts are picked by a mechanical gripper. The robot will "crash" into the parts as it does not hit the hole, where the gripper should go inside and gives an error. The part that I teached is the same that was already teached to exercise but in a total new program.
Another problem is, that the camera has two positions. So there are complicated calibrations in the program that I dont understand. Thats what makes it difficult to check the VR as the positions don't tell me anything.
Thanks for the fast answer. We thought about this. But somehow the offset is not constant. The error changes over time 
We set the reference position new and then the robot picked 10 parts properly. But after a time there was an error.
I cant explain it, as I only added another vision process and a new program. Is the vision register that I used maybe a hint?
Or could i change something on the calibration of the camera with making these two programms?
Hi,
We got a system with 5 Fanuc Robots for paint work. The first robot uses iRVision to locate parts on a desk and put them on the holder for painting. Today we run into a problem after trying to learn a new part to iRVision (I did this the first time). Now all the other programms that were teached by an extern company will have a slight offset while picking the parts.
Here is what I did:
Made new Vision Programm
Learned the part
Saved the postion in VR[1] (which is also used by other programms)
Wrote a new programm which picks the part from this position
This task was an exercise to see how the iRVision works (adapted from here:
We tried to restore the auto-backup but the mistake is still the same. I can't explain where I could change something that now this offset occurs.
Does anybody have a solution for this problem or an approach what we can try to solve this? Tell me if you need more information.
Thanks so much for your help!
Best regards, dofrey
