Posts by Tuipveus

version 5.0 also seems to require port 4966/tcp forwarding in addition to those ports.

I think SkyeFire understood me quite well! Reason that I didn't post pic of the gripper here is that I am on sick leave and just wanted to get something done (remotely) fast. Gripper is almost (very roughly) like umbrella upside down and I am lifting with the ribs).
https://cdn.shopify.com/s/files/1/0301…an_Umbrella.png
With heavier tires it opens more and more of the force is used for weight and less is used for gripping horisontal.

I changed $FOL_ERR_MA from 50 to 200 and it seems that it is working better now. I don't know if it is enough, but that is something that I need to ask from the operators.
Original acceleration (when I left the site was 0.4) and it was already reduced to 0.04 and robot movement was really really slow. Now I increased it back to 0.2 and it is still working (with modified $FOL_ERR_MA)

I used oscilloscope also, but took so long time to catch the error that I was not there anymore and I am not sure if the next error which stopped the oscilloscope was same error at all. I used oscilloscope successfully earlier with the problems when E1 was dropping the product "too" quickly.

Ideally I should position close to product surface with high speed and acceleration, then do slow movement (where weight moves to gripper) and then accelerate up with medium acceleration but full speed.

So next steps are checking Z-distances of these new points (difficult to know since depends of the product) but first I will need to check that $BRK_DEL_EX (Thanks SkyeFire! ), because if it is too big, it might solve the whole case. Or if I am lucky, problem is already solved....

Thanks of the answers.

Quote from SkyeFire

$FOL_ERR_MA is probably the one you want.

I was thinking that too.

Quote

However, there are some other factors to examine:
Is E1 being used as an Async axis?
Are you using E1 in soft-servo mode to grip the payload?
When this error occurs, is E1 in Sync or Async mode?
Do you have an SBM module on the E1 KSD?
What are your settings in $BRK_MODE?

Display More

E1 is async all the time. I am not using soft-servo to grip. E1 is positioned so that there is empty space between the gripper and tire, so they are not touching at all, until I position A3/Z. I don't have SBM module, from Kuka I got information that I need that only if I want to have another asynchronous axis.
$BRK_MODE='B1101' and I got this setting from Kuka. (E1 was added to this robot afterwards). This is portal robot with X1, X2, Y and Z and now E1 has been added for gripper.

Quote

I am not sure of your setup, but it sounds like the brake on the motor of e1 is not powerful enough to hold position.

You are probably right. But like I told, I think it is only the impulse and heavy weight which are causing this problem. If I could know exact dimensions Z-coordinate when weight comes from conveyor to gripper, I could position with slow speed that 100-300 mm. And I know I should use constant speed and high acceleration, instead normal speed and slow acceleration. But in this particular case, it does not matter if E1 gripper tilts 10 mm or so with the heavy tire, as long as it does not go to an error.

And yes, Kuka also recommended soft servo configuration, but I don't understand why, since I am not positioning against any current limit or anything like that. I am not familiar with soft servo and that what things you can do with it and what you can't. If you could explain the concept with sentence or two, I would appreciate it.
Probably I should describe my problem better for Kuka, if modifying $FOL_ERR_MA or Z-axis velocity do not help. Problem is that I don't want to slowdown movements of other products, because these couple heavier ones. And of-course the robot is in the another side of the world.

ps. Another option would be to slowdown Z-axis ($OV_PRO) based on E1 current, but I don't want to go there.

Hello,

I have problems with KRC2, where we have asynchronous external axis for gripping to tire. After gripping E1 is positioned fine, but when we move up +Z (= A3 in this case), we get error with the E1:
1044 brake defective
2962 common KSD-error E1

These errors are coming with the two different robots and only with the heavy products.
I think that the problem is the impulse for the E1, which is caused when mass of the product that we are lifting up, is moving suddenly from the conveyor to gripper. I am not sure if brake is on or off when this happens.

I would like to increase the window, which is used to trigger these errors, but I am not sure what would be best way or variable to do it. Positioning itself goes fine, but problem comes when external force (weight) is coming to gripper.

$IN_POS_MA (axis positioning window), but when we get error we are not positioning E1, but A3.
$FOL_ERR_MA (factor for following error monitoring)
$COM_VAL_MI (axis command speed limitation), but again when we get error we are not positioning E1, but A3.
$TL_COM_VAL (tolerance time for command speed limitation) but again when we get error we are not positioning E1, but A3.

If there is some way to drop down the positioning of the E1 and hold the axis with brake (separately with that axis), please let me know.

This is not official list, but...

I checked quickly while was in Kuka class with netstat -n from WorkVisual computer and found that following tcp-ports are having connection to robot.
9985, 50457 (Remote view, remote service ?)
49010, 49003 (work visual ?)

But didn't get any official list from trainer...

I have same problem with KRC2.

Hello.

I was working couple of years ago also with project, where neural networks would have helped. What I wanted was that it would handle the smartest route and automatic optimization so that robot is always waiting job in correct position, depending of past taskhistory.

You need saferobot, to make robot to understand the dimensions of your workpiece.

Most likely it is still much easier to define combination of axis for the working envelope to be allowed and not allowed.

I made a project with saferobots (kuka option) using both envelopes and safetyzones. Safe-option is used for protecting humans and software-based envelopes are for protecting robot itself of another robots and slidingdoors.

Changing status of cartesian envelopes from submit interpreter usually does the trick.

Doh, it was declared in a.dat as global. That is problem for sure.

Is submit using the same variable, if it has been defined global in a.dat ?

It was not declared at all in submits dat. Sorry about confusing question.

Problem was that both the main program and submit are writing the same variable and probably calling simultaneously the same program.

I have a function in "a.src"-file, which does some calculation. Function is called like:

func1(p: in)

inside function "p" is declared as local variable but it has line:
y=p
and y is not declared anywhere globally or locally.

It is declared in submit interpreter dat-file, but not in $config.dat or a.src.
It is used by both submit and a.src. Program works most of the time. Yes, most of the time.

Could this not-declaring be the problem of random incorrect values?

If using the XYZ 4-Point method fails and you have such a long tool, problems can be with the physical tool, that it is bending because of the gravity, while you are teaching the tool in different positions.

However, it does not explain that why some of the axis are not leveled, like you described. So probably reason is still with mastering or MADA, like was suggested before. Try mastering with EMT, if that does not help, contact Kuka Germany to get the original MADA of your robot with the robot number. Its easier, if you just send your archive to Kuka to examine and compare the madas.

Is the robot floor mounted and has it been originally also floor mounted? Anyway, I think you can not position such big tool accurately giving millimeters to it, if it the robot model is not "accurate" one.

And remember to be extremely carefull with advance run, since I have notice that it doesn't always go according $advance with conveyor tech. Sometimes very rarely it doesn't work and caused crash. Stopping the motion after advanced run solved the problem in my case.

Can you give password for me too?

It is also possible to read coordinates from binary file with Kuka SoftPLC and send them to KRL-program. That way it is a lot easier than with XML.