I do not know, if it is helps You, but one of the BG logoc what we are using:
123: !Robot actual position ;
124: GO[11:4336:CurrPosX]=($SCR_GRP[1].$MCH_POS_X*10) ;
125: GO[12:61953:CurrPosY]=($SCR_GRP[1].$MCH_POS_Y*10) ;
126: GO[13:5523:CurrPosZ]=($SCR_GRP[1].$MCH_POS_Z*10) ;
127: GO[14:65523:CurrPosW]=($SCR_GRP[1].$MCH_POS_W*100) ;
128: GO[15:64052:CurrPosP]=($SCR_GRP[1].$MCH_POS_P*100) ;
129: GO[16:14064:CurrPosR]=($SCR_GRP[1].$MCH_POS_R*100) ;
Hello,
I have an LR Mate with R-30iB Mate cabinet, I would like to disable the touchscreen.
In the system setting as You can see in the attached picture is write protected . What should I do ?
Thanks For Your Answer!
Different speed control for program running and jogging , Kuka already have it 
Did You add the part, what You want to manipulate, to the EOAT ?
Tried on both controller and TP. Good to know img only works on controller port though. I'm suspecting something is up with my usb. It is FAT32, but I can't reformat it due to needing other stuff on it at the moment. Will try and get another usb soon.
Also can be a problem, if your usb is bigger than 4gb
How did you determine:
and
Maybe you move the robot with an active userframe but you calculated the target position in world coordinates?
Also if you look at Fanucs own Palletizing function they would require 3 points to be taught for what you want to do. Maybe that helps with accuracy? Wouldn't change the fact that the robot doesn't move to the calculated position though.
Supplier tried the Fanuc own Paleletizing function, and it is working fine !
Did PR[25] = *. If so that was the issue.
An easy way to fix that is to set PR[x] = LPOS-LPOS first in your program. That will initialize it to an all zero cartesian pr.
I had a same issue before .
I used a PR for offset positions (every cycle different values) , and it was not working all the time.
I changed my program like You said, "clear" the PR value before write in the new value.
So daco , Your program should look like :
.
.
.
11 : PR[25]= LPOS-LPOS
12: PR[25,1]=(R[166:OffsetX]) ;
13: PR[25,2]=(R[167:OffsetY]) ;
14: PR[25,3]=(R[168:OffsetZ]) ;
.
.
.
Hello,
I‘m a greenhorn at robotics but got a problem that needs to be solved.
I got a screw unit at the robot to fix spare parts in milling machine. I put the Signal to the unit with DO X=[on]. The screw unit do his job and give a Signal back to the robot. On DI10 if it was okay and on DI11 if it was not okay. Program just can Go on if I Gotha signal on 10 (ok), if I got a signal on 11 (not ok) program have to stop and lightning bulb must be activated.
How can I program this steps?Thank you in advance
IF DI[10:]=1 AND DI[11]=OFF, JMP LBL[1] ;
IF DI[10:]=0 AND DI[11]=ON, JMP LBL[2] ;
I don't remember specifically if it is due to crossing an axis or lack of turn data, maybe someone else can better explain it. It still reaches the cartesian point, however (for example) J4 could flip. The tcp is still at the position, just with a different config.
When you say "not going to exact position", do you mean the calculated position vs the displayed position are different? Or is it the robot didn't line up with a part/fixture?
If it is the latter, you need to verify stack up tolerance on the trays/fixtures. If the destination has 20 spots and they were built +/-50um, you could have up to a mm in error at the end. You can't expect a robot to pick +/- .5 mm if the tray is +/- 2mm.
The calculated and the displayed positions are different 
I already checked the NUT values (from backup) , the robot makes changes ( From NUT 0 0 -1 to NUT 000 ) while moving to the palletizing position ...
I spoke with the supplier, but I still did not get answer...
One thought, verify the robot isn't changing config when it reaches the point. We do a lot of calculated matrices and I have fought this before. The robot can reach the same point in space with a different joint configuration. Theoretically it should be the same point but from what I've seen it will introduce an error.
Just my 2 cents.
I will check this config changing in roboguide !
Actually I do not really understand, why it can happen ? If all the point is teached it is working well, if try to pallettizing, it is not...
Have you set the payload settings for the robot with and without the part being palletized? You should have different payload schedules set up for each EOAT + Part combination, and switch between them as needed in the program by using the Payload[n] instruction.
I would suggest trying that first, and maybe decreasing the acceleration/deceleration speeds using the ACC motion option (try ACC 50, for example, for double acceleration and deceleration time; this will make the moves slightly slower but should help smooth them out).
Edit: Beat me by a minute or two
Yes, we checked the gripper payload, the part is roughly 5 gramm , so we did not make an additional payload for it ...
The speed was reduced so much
Thanks for your ideas
Maybe it is the speed of the movement, 2500mm/sec is very fast.
Move fast to a position close to the desired position, and then move slowely to the position.
We changed the speed to 50 mm/sec and had the same issue
Hello !
Last week , we had a feasibility test with the an external supplier ( they will build a machine for us ) , and I have seen a very strange issue .
Subject of a test :
- Pick up a part ( rectangle shaped) from a plastic tray
- Drop the part into the Jig. ( Placing is really tight, only 0,1 mm per side)
The supplier said, the palettizing function was not worked , so they tuoched up all positions ..
Pick : 60 positions
Drop : 36 positions
It is not seems so good if someting is going wrong...
Pallettizing code :
9: FOR R[2: Y]=0 TO 5 ;
10: FOR R[1: X ]=0 TO 1 ;
16: PR[2,1]=R[1: X ]*(-118) ;
17: PR[2,2:]=R[2: Y]*(-45.3) ;
PR2 is used for Offset .
Like this :
L PR[6:POZ1] 2500mm/sec FINE Offset,PR[2]
Issue :
The Robot was not going into the exact position , which was written in the PR[6] .
For example :
PR[ 6] value with the offset :
X 100 W -90
Y 100 P 0
Z 100 R -45
PR[6] reached position
X 99.8 W -90.1
Y 99.6 P 0.2
Z 100.1 R -44.8
Do You have an idea why ?
Robot : LR Mate 200iD/7L R-30iB Mate Plus
Thanks for Your answers
I would really appreciate it, if You could send to me this document and backup :)
TIA
Email : danikab62@freemail.huHello!
Actually I had an experience with ABB and Kuka with spot welding. Really important thing, and You can save a lot of time, if Your welding gun open/close values are well adjusted. I mean that if the maximum open value 180mm, do not drive use it all the time this value
Hello Guys!
I tried to make a "main" program, but I had an issue. In the first level , I want to choose the type of product, second level what to do with the product ( this is necessary, because, if the robot stops meanwhile the production , in this case we should start the robot from the middle of his cycle ) .
In the third level will be the programs, whit the movements .
If the robot finished his third level program, the program jump back to the second level, is it possible, to jump form the third level to the first one ?
Thanks for the answers !!!
Level1:
IF DO[125:ON ]=ON,JMP LBL[1] ;
3: UALM[1] ;
4: ABORT ;
5: LBL[1] ;
6: WAIT DI[125:OFF]=ON ;
7: R[150]=GI[50:0] ;
8: ;
9: SELECT R[150]=1,CALL P1 ;
10: =2,CALL P2 ;
11: =3,CALL P3 ;
12: ELSE,CALL ABORT ;
13: JMP LBL[1] ;
Level2: Actually this is the Program "P1"
1:
2:
3: R[151]=GI[51:0] ;
4: ;
5: IF (R[151]=1)) THEN ;
6: CALL P1_1 ;
7: ELSE ;
8: ENDIF ;
9: ;
10: IF (R[151]=2)) THEN ;
11: CALL P1_2 ;
12: ELSE ;
13: ENDIF ;
Level3: Actually this is the Program "P1_1"
1:J P[HOME2] 100% CNT100 ;
2:UTOOL_NUM= ;
3:UFRAME_NUM= ;
4:WAIT DI[102:AREA_ST02]=ON ;
5:DO[102:AREA_ST02]=ON ;
6:CALL GRP1_CLOSE ;
7:J P[1] 100% CNT100 ;
8:J P[2] 100% CNT100 ;
9:J P[3] 100% CNT100 ;
!FRAME DROP POSITION IN ST02 POS1 ;
10:L PR[4:DROP_FR_ST2_P1] 500mm/sec FINE ;
11:CALL GRP1_OPEN ;
!DRIVE UP IN "Z" AFTER DROP POSITION ;
12:PR[X]=LPOS ;
13:PR[X,3]=PR[X,3]+80 ;
14:L PR[X] 500mm/sec CNT100 ;
15:J P[5] 100% CNT100 ;
16:J P[6] 100% CNT100 ;
17:J P[HOME1] 100% CNT100 ;
18:DO[102:AREA_ST01]=OFF ;
/END
