Dear Alex Sleep,
many thanks for your time to investigate the issue!!!
I just get to similar problem and what ever I did - the syntax error remains.
Finally I found your post and thanks to you, I sorted the issue out!!! 
Many many thanks!
Cheers
Svetozar Yolov
Thank you flatcurve, for excellent post.
I hope, after 4 years someone will answer to mu doubts :).
I am quite new in robot programming, but recently, I did quite complicated depalletizing/palletizing FANUC robot program and I need to know what is your opinion for the following.
One of the aspects of the task was, when robot lift a plastic box from a pallet, to detect at which side is the pocket for labeling (there is small groove /I believe the word I use is correct/ on the top of box side). The label pocket must face the machine, if not, the box must rotates - in my case at -179,98 degrees.
So the question was, where to store the rotation angle - into the Offset,PR[XX] or into Tool_Offset,PR[XX]?
At the time I program the project, I store the rotation in Offset position register. No I think the Tool_Offset position register was more appropriate!
What do you think?
Best regards,
Svetozar Yolov
Thank you gpunkt,
When I position the robot, and it J4 went to its limit. The bad thing is that when I teach points - it seems OK. As soon as I tray using "MOVE TO" button on TP or I create simple program with linear movement (I need linear, because the cardboard box need to go straight through taping head), I got limit error on J4.
I struggled with this problem for day and a half!
Cheers!
Svetozar
Dear Colleagues,
I am working on simulation on cardboard erector, using FANUC CRX 10iA/L cobot.
I am straggling more than 2 days and could not make it work. The problem is when I move the robot through the taping head, in the middle of the move I am getting limit error at J4. For this robot, J4 limits are +/-180 degrees. J4 goes more than -180 degrees and limit error raises.
To sort the issue out, I try to place taping head:
- On the other side of the robot
- Change the height of mounting of the robot
Until now, nothing seems to improve the situation.
Does someone, got an experience with this kind of robot and can provide any advices, how to place the robot in order to get rid of limit error?
On simulation and even activate Singularity Avoidance (R792) function. It was without success.
According a more experienced than me colleague, those robot was very fastidious.
Any advises will be highly appreciated!
Regards,
Svetozar Yolov
Hi,
Totally agreed with HalbesYoyo. Using web browser and internal web server of Roboguide or real robot is very easy way to rename registers (as it is on the picture HalbesYoyo posted).
Cheers!
Dear Colleagues,
I will be involve in a project, where FANUC robot SR-6iA (30 kg) will be used.
On the robot wrist, automatic screw feeder and screwdriver (most probably supplied by Atlas Copco) will be installed.
My question related to movement strategy to be used for screwing the screws.
The movement speed of the robot arm at the stage of screwing, obviously will be calculated by the step of the screw thread. Is that correct?
The number of threads and the step will give the total movement length. The number of turns (the turns will be set into the software/controls system of the screwdriver) will give the speed (mm/s).
One of the thing, which bothers me is the start of screwing stage and the screwing stage itself. At the begging, when the screwdriver is started, the move down must be slow, and next, when the screwdriver reach nominal revolutions, the move down should be increased - this is my understanding.
Should this robot movement must be determined on trial and error approach?
Or probably I too complicate the task?
Can you share your experience for such screwing projects?
And advices will be highly appreciated!
Reagrds,
Svetozar Yolov
Many thanks for the explanations.
To unwrap the wrist, I normally restore the R angle, close to zero. For example, if I need to turn +180 degrees, I use angle of +179.9 degrees, and then to unwind the wrist (the gripper), I set +0.5 degrees into R of the PR. With 90 degrees it is easy and more safer than +179.9 degrees.
I almost do not use P[]. My program, becomes quite complicates and all points are based on PR[], and the points are calculated.
From your explanations, it turns out that it is good idea, to have one or two points into the program, formatted in joints, in order to unwind the wrist of the robot.
Thank you for sharing your experience with me.
Good luck!
Svetozar Yolov
Many thanks for the explanations. I will try it.
I will very grateful, if you explains me the following.
I calculate a point in PR, where the robot must go - let say this is PR[80]. Configuration of PR[80] is NUT 000.
In PR[80], there is rotation R = 179.9 degree.
If there is NO rotation, the configuration is NUT 000.
If there is rotation, the configuration (in my case ) becomes NUT 001.
Strangely for me, EVEN THERE IS rotation, PR[80] with NUT 000 works, and the robot did not raise error and executes the move. Next the robot program continues further.
If the movement is interrupted (I use skip function), the robot did not allow to execute movement to position of PR[80] with NUT 000 - I get SRVO-115 SERVO Limit error (G:1, A:6) error.
As soon as I change configuration of PR[80] from the pendant to NUT 001, it starts working again.
I hope that I make myself clear.
What is this explanation for this behavior?
Probably, the robot did not know what will be the configuration, and it is executing the move with NUT 000. Next, after the interruption, the configuration is already changed and the move is not more possible? Am I right?
In this particular case, should I prepare PR[80] with NUT 001 before the movement?
What do you think?
Than you in advance!
Cheers!
Svetozar
Dear HawkME,
Thank you for your comment. I quite value your post, because you help me in the past.
The configuration of the point/position register really confuses me. I understand the meaning and the concept but some details, leave me confused.
Can you explain your idea regarding the use of joint move?
My program looks more or less as the following (all PR are in cartesian coordinates).
281: !calc dest. final position ;
// start point + offset in pallet
282: PR[86:palGenPurpose2]=PR[21:47PalFullBgn]+PR[6:PalFullOffset] ;
// start point + offset in pallet + gripper is 150 ABOVE the box
283: PR[85:palGenPurpose1]=PR[86:palGenPurpose2]+PR[29:47ToolOffset] ;
// approach to the place position with "not to hit something" code
296: CALL ARC_KLT_ADAPTIVE_APRCH_FULL(PR[85:palGenPurpose1],PR[86:palGenPurpose2]) ;
// some code
309: !unlock the box;
310: CALL ARC_KLT_UNLOCK ;
// evacuate from the box left
314: !move over full KLT ;
315:L PR[21:47PalFullBgn] 2000mm/sec CNT25 Offset,PR[6:PalFullOffset] Tool_Offset,PR[29:47ToolOffset] ;
I cannot understand how to use joint coordinates.
I check with the ROBOGUIDE, and I can change the PR coordinates only when it is included inti motion command. There in POSITION, with button REPRE, I can got to joint coordinates.
I missing the link between cartesian coordinates which I calculate and the joint coordinates which you suggest to use. I hope, I make myself clear enough.
cheers
Svetozar
Dear Sirs,
On my J6 faceplate, the gripper is mounted in a way, that at “normal” position (normal is the position of the gripper, which the robot works 99% of the time), I have already 105 degrees.
The robot palletizing boxes on pallet in to columns by 4 boxes. Something like this (O is a box):
OOO(O)
OOO(O)
The boxes not in parenthesis, the configuration of the position register is NUT 000. The configuration of the last boxes, the ones in parenthesis is NUT 001.
When I place all boxes, I rotate then at +179,9 degrees.
The first six boxes, after the rotation, got configuration of NUT 000.
The last two boxes, after the rotation, got configuration of NUT 001.
Strangely, for me the robot did not complaining for last two boxes and palletizing them even without NUT 001.
Unfortunately, when it cannot place the box properly (here I do not want to go into the detail, why this happening), it goes into SRVO-115 SERVO Limit error (G:%d^2, A:%s^7).
The position where the robot must go is in position register.
The remedy, I am thinking, is when I must palletizing the position in question (last two) to use configuration of NUT 001.
I tried to add to the position register, another one, which got all x,y,z,w,p,r = 0 and configuration NUT 001.
PR[81] = PR[81 - NUT 000] + PR[51 – the one with NUT 001]
Unfortunately this did not work!
I was advised to use joint coordinates, but at this stage of the project, I think it is not possible!
Can I set NUT 001 in a position register?
Thank you in advance! Any advices will be highly appreciated!
Svetozar Yolov
Dear DS186,
This is exactly what I need.
Many thanks for the hint. Actually I have this signal already configured in my PROFINET IO settings.
Have a nice weekend !
Svetozar
Dear Colleagues,
I have robot FANUC, model: M-710iC 50 and controller: R-30iB Plus.
Robot controller is connected to SIEMENS PLC S7-1512 SP, by means of PROFINET IO.
The current execution program/s, can be stop by pressing FCTN from TPendant, and next ENTER.
Is it possible this functionality, to be done through PROFINET IOs?
My point is to have functionality on HMI (connected to the SIEMENS PLC), by pressing a button to cancel currently execution programs and when the cell is locked, the robot to start execution its program from the very beginning!
I don’t want to train operators to address or use robot’s TPendant.
Probably my approach is wrong and there is another way to “kill the cat”.
Any advice will be highly appreciated!
Best regards,
Svetozar Yolov
Dear PnsStarter,
many thanks for you hint!
When I increase the limit of the J6, my robot starts to reach positions on robot's right.
I am puzzled, because by real robot got the limit of J6 and can reach positions on right!
I limit J6 because I afraid of breaking pipes and wires, which going into fastchanger.
Because of fastchanger mounting, my J6 is rotated +105 degrees. I thought that because I have made Roboguide project from backup, everything will be fine.
It turns out that Roboguide environment it is not exactly ae my robot or I missed something important.
It will be great, if you know what is happening to educate my or just point me what to read into documentation!
Thanks againg for the hint!
Reagrds,
Yolov
Dear colleagues,
I have got:
- Roboguide 9.40100.00.05
- Robot model: M-710iC 50
- Robot controller: R-30iB Plus
The project, I create from robot controller "all of above" type backup.
You can see from screenshot what are the axis limits. J1 for example is -180 to 180 degrees.
It turns out that I can not reach positions, located on robot right! Actually this are position below J1 < -70 degrees. I can not figure out why is that.
In addition I noticed that when the position is not reachable, robot gripper freezes and TCP with the Cartesian Coordinate System continues to move with my mouse pointer.
Roboguide Help is not an example for even approximately good help information system.
Can you give me a hint, what is the problem and how I can make positions reachable!
The real robot can reach positions located at -180 < J1 <= 0 easily!
Reagrds,
Svetozar Yolov
Dear Hawk,
Thank you very much for the answer!
Regards,
Svetozar
Dear Hawk,
From my current perspective I used only PR[] im my program. My understanding is that they provide me with greater flexibility. in addition, when we need to relocate the robot from test center to real installlation, I need to teach just a few points.
From your post, I understand that in the program is very good idea to have som key point in the program. Is that you mean? If it is so, can you give me some advice where to used them?
At present I am working on depalletizing/palletizing solution. On robot one side there is depalletizing station. From pallet, the ropbot place basket on conveyor.
On robot other side there is another pallet, where robot palletizimh full baskets. In this paradigm, where is good idea to use points, to untwist the robot wrist?
Best regards,
Svetozar
Dear HawkME,
Many, many thanks for the advices.
$MISC_MSTR.$hpd_enb is already set to TRUE. This is a prerequisite, in order $MISC[1].$hpd_trq[9] to be updated.
I followed your advice and I put constant (in my case -8.9) for axis 2 & 3. It works now.
My understanding is that there is a bug in robot firmware. As I told you the first pass of program succeed and at next step when I begun to play, the fault INTP-203 starts to appear.
Any way, I put OR expression for both axis 2 & 3 and used constant instead of register.
It works as charm now.
Thank you one more time.
Regards,
Svetozar
Dear HawkME,
Many thanks for the advice and info.
I use torque values in my program. Here is the code:
13: SKIP CONDITION RI[3:plate HP]=ON+ OR $MISC[1].$hpd_trq[2]<=R[40:distTorqMax] OR $MISC[1].$hpd_trq[3]<=R[40:distTorqMax] ;
14:L PR[66:incZn50] 100mm/sec FINE Skip,LBL[15],PR[80:adaptGrpPosition]=LPOS INC ;
Unfortunately I suffer from error:
INTP-203 (ARC_KLT_ADAPTIVE_APRCH, 13) Variable type mismatch" " STOP.L 00000110" act"
It is strange that rows 13 & 14 was executed one time and on the next pass a fault starts to occur!
Any ideas?
Regards,
Svetozar
Hi,
sorry for delay answer.
When I pic a basket, I rotate negative Z. This is because of the gripper mounting and supply of air and cables. There is a fastchanger connected to Z6 faceplate.
I always go first negative Z and next positive Z to release the gripper. In addition I use -179.98 for negative Z and .02 to rotate positive Z.
I provide only the rows, which I consider related to the problem I have. My program is very complex. I do not believe that someone will waste his time to study it.
There is no PICK and PLACE part. I is rather:
CALL ARC_KLT_LOCK – in order to lock basket with the gripper and
CALL ARC_KLT_UNLOCK – in order to release the plastic basket.
Unfortunately there no Vision option. It would be very nice to have it on board, but unfortunately, at the beginning of the project, my colleagues decided to get rid of it. I consider it as mistake.
To sort the problem when I go through red line I use:
J PR[23:47ConvEmptyEvac] 100% CNT25 ;
Probably I must change it from J move to L move.
On the way back I use:
59:L PR[22:47ConvEmpty] 500mm/sec FINE Offset,PR[7:ConvEmptyOffset] Tool_Offset,PR[29:47ToolOffset] ;
To HawkME,
Many thanks for the advices. I consider myself still newbie in this field. From my experience, as you point, the move from one area to another it is good idea to use J (joint) moves, which are fast and do not stops at the intermediate points. When robot is into area, using L (linear) move is better.
Please can you clarify the idea for “when you move back to another area you can use a regular joint move to unwind the wrist.”. What you mean by that? To return the twist at it start position – right?
In the forum I also met the word “untwist” which I believe got the same meaning.
At the end, I would like to thank you of you all for your time and knowledge you shared with me.
Svetozar Yolov
Dear Gents,
I have depalletizing program, which take plastic baskets (KLT) from a pallet.
Sometimes the KLTs, are not placed very well and they don’t fit properly, meaning that top KLT do not inserted properly into the one below. As result, the top one is a little bit inclined. When the gripper tries to catch the KLT, SRVO-050 Collision Detect Alarm occurs.
My goal is to make a routine, which in case of SRVO-050 Collision Detect Alarm, to return back the gripper and wait the operator to align the problematic KLT. Next when the operator reset the robot (from HMI), the process to continue.
I wrote the following program but it doesn’t function as I expect. I addition, SRVO-050 suddenly stops to appear.
ARC_KLT_ADAPTIVE_APRCH.LS
1: //save curr pos on the top of KLTY ;
2: PR[35:CurrentPos]=LPOS ;
3: ;
4: LBL[1:adaptive begin] ;
5: ;
6: !adaptive approach start ;
7: LBL[10:adaptive start] ;
8: // moves 90 mm down ;
9:L PR[67:incZn90] 500mm/sec FINE INC ;
10: //sensor that gripper is on the KLT ;
11: SKIP CONDITION RI[4:plate WP]=OFF ;
12:L PR[68:incZn30] 200mm/sec FINE Skip,LBL[15] INC ;
13: //sensoe that gripper is on pos. to catch KLT ;
14: SKIP CONDITION RI[3:plate HP]=ON OR ERR_NUM=11050 ;
15:L PR[66:incZn50] 100mm/sec FINE Skip,LBL[15] INC ;
16: ;
17: //check if the stop is because of sensor or error;
18: IF (RI[3:plate HP]=OFF) THEN ;
19: //if RI[3] still off, must be the fault occur. Go UP!;
20:L PR[35:CurrentPos] 500mm/sec FINE ;
21: UALM[2] ;
22: JMP LBL[10] ;
23: ENDIF ;
24: ;
25: ;
26: JMP LBL[100] ;
27: ;
28: LBL[15:P20] ;
29:L PR[35:CurrentPos] 500mm/sec FINE ;
30: UALM[7] ;
31: JMP LBL[10] ;
32: ;
33: LBL[100:END] ;
Any advices and recommendations will be highly appreciated.
Best regards,
Svetozar Yolov
