What’s the deal with all the ”Please help me?”
You don’t have to beg. Everybody’s pretty much here to help. 😅
What’s the deal with all the ”Please help me?”
You don’t have to beg. Everybody’s pretty much here to help. 😅
Before I’m off reading the documentation for it, what else does expert-tech provide else than this?
You need option expert tech. Then you can touch up none inline form movements.
…Alrighty
I guess Expert tech is a payed option that you’ll have to buy along with the robot etc?
Hi,
Is there any possibility to use the Touch-up function without Inline-form?
The Idea is to avoid Inline-forms as much as possible throughout the entire program because I don’t like it. 😉
(Yes I know ”Touch-up” is a function that belongs to the inline-forms)
Alright!
So neither $VEL or $VEL_C shows the actual tcp-velocity/what the robot tries to achive, just the ”programmed” velocity?
Hi,
Lets say $ADVANCE = 3
The robot passes a couple of positions with different velocity and accelerationparameters.
P1 (VEL 0.5)
P2 (VEL 1)
P3 (VEL 1.5)
If $VEL and $VEL_C is monitored, will they still show the same or what will be the difference?
User level?
Administrator, so it doesn't matter.
Hi,
I'm currently trying to create a tool all numerically and have entered the mass etc.
At the bottom I'm unable to enable the Overload/Underload because the "Load data verification has not been enabled."
How do I enable this?
The OR1 and ORI2 was the deal.
Thanks!
Hi,
I’m currently working on a project containing one KR16 - KRC5.
I’ve written in a previous thread that I’m a previous ABB-programmer.
I’m having issues with the speed of some ”short” LIN-motions. (It’s a movement of 500mm or so)
I’m using full acceleration and 2m/s but the movement still seems pretty slow compared to the PTP ones.
Is it something obvious when working with LIN-motions that I’m maybe missing out?
(I’ll paste the code later, just putting this here if anyone knows something of this little information above)
Display MoreIn KRL, unlike RAPID, motion commands are completely separate from Velocity, Tool, Base/WObj, etc settings. Setting the motion parameters is separate executable lines from the motion commands themselves. Even if you're not using ILFs, you can still make use of the system BAS functions to make this easier.
You don't have to avoid ILFs if you want to do offsets. ILFs just don't include offsets, but you can still do them. Also, your example KRL is not going to do what you want -- it will generate a tool offset, not an offset in the active WObj/Base:
PTP P1 : {X 0,Y 0,Z -100,A 0,B 0,C 0}
PTP {X 0,Y 0,Z -100,A 0,B 0,C 0} : P1
The order matters, since that's not an offset command, it's an actual mathematical equation. It works like a function call, the result of the equation goes into the PTP/LIN command. The offset after the point takes the point, and shifts along the point's Z axis. The second line applies a shift along the Z axis of the active Base/WObj to the point, before taking the point's orientation into account.
To use offsets with ILFs, the simplest method is to use Base offsets. This works just like applying offsets to a Work Object in RAPID, except KRL Bases don't have a second OFrame element, only the primary frame. So, something like:
Code Display MoreDECL FRAME _fOffset DECL INT _nIndex DECL REAL _nShift _nShift=7.5 ; mm FOR _nIndex = 1 TO 10 _fOffset = $NULLFRAME ; set to all 0s _fOffset.Z = _nShift * _nIndex BASE_DATA[2] = BASE_DATA[1] : _fOffset PTP P1 Vel100% Tool1 Base2 yada yada ILF stuff ENDFOR
The key here is that Base2 is being written to. BASE_DATA[1] is your "reference" base, set up once, and should never be altered by the program. This can work for "raw" KRL, or for ILFs. You simply have to alter the Base values before the ILF executes.
Doing tool offsets with ILFs is harder -- either you dynamically apply adjustments to the TOOL_DATA value, or apply offsets to the actual E6POS value of the point itself, before the ILF.
Well thanks for that input!
Any tips on how to lower/set speed and approximation during continuous movements else then the stuff fubini just wrote?
Also I'm not into using inline forms because its lack of offset functionality and "dynamic" PDAT/LDAT.
Hi,
I'm a previous ABB-Programmer and have just started to program KUKA-robots.
When programming ABB-robots each movement has to have the given parameters like velocity, aproximation-distance, tool and work object (Base in KRL)
The example I'd like to use is:
MoveJ Offs(PickPosition,0,0,250),v2500,z50,tGripper1,wWorkobject; (This position is far away from the actual "PickPosition")
MoveL Offs(PickPosition,0,0,50),v800,z30,tGripper1,wWorkobject; (This one is closer than the previous point with less distance, velocity and aproximation-distance)
MoveL Offs(PickPosition,0,0,10),v100,z10,tGripper1,wWorkobject; (This one as well)
MoveL PickPosition,v50,fine,tGripper1,wWorkobject; (The actual "PickPosition")
KRL Corresponding I assume would be:
PTP {X 0,Y 0,Z 250,A 0,B 0,C 0} : xPickPosition C_DIS
LIN {X 0,Y 0,Z 20,A 0,B 0,C 0} : xPickPosition C_DIS
LIN {X 0,Y 0,Z 10,A 0,B 0,C 0} : xPickPosition C_DIS
LIN xPickPosition
How do you code this when for example want to lower speed and approximation while getting closer to the point like the ABB-example above? (In a nice-code-way)
I Could assign the velocity and APO in-between the movements but it would look like crap and would not be easy to re-use.
I could make a DEF/DEFCT which is like the ABB-way and use Position, Approximation etc in the program-call but I'm not into doing that either, when programming KUKA-robots I'd like to do it like it should be done (?)
This is not a problem, just a tip on how you guys do this? (Maybe most of you use the same speed & aproximation during the entire program cycle idk)
Well I found many of them but didn't get them to work properly. The real question is actually if anyone uses it, and can recommend a specific one?
Hi,
Does anyone here use VS-Code for KRL?
I'd like to try it but can't find the correct add-in for it.
Hi there,
I've made a program that helps me do a specific path with the orientation that my tool needs to have on each point on the path. Each point has an X Y Z coordinates, but the orientation of my tool is given by a normal vector. I would like to know if there's a method or something else I can do so I can convert my normal vector to the variables A, B and C.
I will put an image on this thread so you can visualize what I'm saying. Each red line is the orientation my tool needs to have on each point. The orientation is a vector [X; Y; Z] but I need the following variables: A, B, C.
Thanks in advance!
Dumb question, but in which software did you take the print screen?
Hi
I will release soon.
Hello! Is this released yet?
LIN motions ignore S&T in favor of maintaining a linear path.
PTP motions always obey S&T. There's no KRL equivalent of the CONFL and CONFJ commands in RAPID.
To get the equivalent functionality, use FRAME variables instead of E6POS or POS variables. FRAMEs contain only the AYXABC values, so the path planner is free to use whatever makes the shortest path in joint space.
Since hand-taught (Inline Form) points are always E6POS (or E6AXIS for pre-DECL'd points like xHome), this can be a headache when using ILFs. Usual practice is to create a subroutine that uses a FRAME variable, and receives the E6POS as an argument, copying the E6POS into the FRAME before putting the FRAME variable into a motion command.
Thanks!
Hey,
I'm currently trying to learn KRL from Rapid (ABB) and have a question about Status & Turn.
If I move to this position with PTP or LIN, does it always go to this position with the declared status & turn value or does it change these depending on current axis-position?
E6POS Position ={X 0,Y 0,Z 0,A 0,B 0,C 0,S 6,T 21,E1 0,E2 0,E3 0,E4 0,E5 0,E6 0}
IF Yes or No:
Is there any system-variable to enable/disable this?
In Rapid/ABB you can choose if the robot is going to take the assigned "Status & Turn" or just chose the closest and most suitable during the movement, with a system-variable (ConfL/Off, ConfL/On). Is there any settings like this in KRL?