Posts by Tembai

Panic mode,

Thank you for your reply. I am grateful that you are willing to explain in such detail to beginners. I indeed did not have official training, but did extensively dive into the manuals and fora.

I understood your logic on defining A5 as a TCP and find it a very clever approach for eliminating one extra degree of freedom, as seen from above. I have defined all our tools in KRL with measurements gained from our CAD models and rotated their coordinate systems to match our typical base orientation. I do not work much with the teach pendant (rather KRL and the simulator), and as I read, the main purpose of setting your TOOL_DIRECTION are functions like align. I have not needed the function yet since I have all movements "hardcoded" using parametric distances and bases. I do read that splines take the tool direction in consideration, but have not yet seen any unexpected movements.

As for the X-axis movement, your comment clarifies my point of confusion. Since you did not specify the base in your code example, I assumed you had $ROBROOT selected and were defining a movement relative to the base of your robot, which had me scratching behind my ears.

Again, thank you for your time and ideas!

Hi panic, thank you for your answer.

That does sound like quite a tight setup! Fun challenge. You're right, compared to your example, I have luxurious amounts of real estate. My robot will be working with an operator however so I am expecting a good amount of emergency stops and wish to make the system capable of restarting safely from any position/stage in its programs, which I could hardcode but would much prefer to write logic for.

Quote from panic mode

if cycle was interrupted or aborted, check if still on path, and if not how far from path it is, on which side of the process it is etc.

How did you decide if the robot was still on its path? Calculate the distance between TCP and every point on your path?

Quote from panic mode

then you can calculate distance to robroot Z axis for both real TCP and the A5 TCP to determine which one is closer

This is a great idea! Thanks!

Quote from panic mode

P0 = $POS_ACT

P0.X = P0.X* r0/r1

I like how you retract here with a variable distance depending on that ratio r0/r1. Did you pick the X axis on purpose? I can't quite imagine what will happen in every situation when you don't know the robot's orientation in regards to that axis although I suppose it will always retract towards origin.

I have come to the realization that:

if A = - A1 then A5 =0

and so

|A| = |A1| - |A5|
and am convinced that with that and your A5 TCP, I should be able to calculate how much I would need to rotate around TCP, in the case that moving the tool backwards as-is wouldn't get it within the safe turn radius. I have yet to succeed in writing a function for it though.

In the current implementation, I do something quite similar to your example, and I think I might just stick to moving a set distance backwards before simply withdrawing. I am not entirely satisfied but if it works, it works. I can't help myself though for wanting to have a nice and exactly calculated failsafe solution

Hello,

I am having a little challenge that I am struggling with.

For our application, I wish to make a "failsafe" function. This to ensure that, if for any reason the running program gets reset, the robot will drive backwards along its tool's Z-axis to within a safe radius around its axis A1 first before starting the program anew. I would, before running a program, check whether the TCP is in the acceptable starting position.

The robot is in sort of a concentric warehouse-pick-and-place setup, where it stands in the middle of multiple rows, concentrically placed around the robot. But, not all positions the robot will reach are concentrically placed, which complicates matters. Otherwise, I could always withdraw straight to the robot's origin.

I wish to be able to calculate the distance that I need to drive the TCP backwards, along the tool's Z axis, to get back into a "safe radius". It is important to "back out" along the tool's Z axis to ensure it leaves any row the way it went in. I know how to drive the tool relative to its coordinate system.

To illustrate, I included a sketch, as you would see the robot from above. Here, you see the pink circle, radius1, the "safe radius" I defined (radius2 is just for illustration of a possible tighter requirement) and the red tool aligned with A6. Basically, I would like to be able to calculate x (the distance to drive the tool backwards) for any position the tool might be in. To clarify, I included the green position for a tool position which has no solution. In this case, I would adjust A, the TCP's orientation, until it would be able to be driven backwards into the "safe radius".

I hope my description is clear, the solution would need to work for any position & orientation the TCP might be found in.

I'd appreciate hearing if anyone encountered a similar situation or has an idea on how best to tackle this.

Kind regards,

Tembai

">">

KR-C4

KSS 8.6.5

KR 210 R2700-2

Hi Micahstuh!

Apologies for answering to an old thread like this.

Would you mind sharing your program? I am similarly annoyed to have my commits overwhelmed with changed files.

Kind regards,

Tembai