Posts by Hes

Yes and the mode on the vrp is not the same as the mode on the smartpad. I would have liked them to be in sync. Also disconnecting may is a hassle, it must be done properly from the vrp to not stop the robot.

There is an option Kuka.VirtualRemotePendant that works exactly as it sounds. Albeit you MUST have an emergency stop at hand which would be hard to implement over long distances. It has a crapload of quirks also.. buttons are toggle (which is annoying), spoc is implemented so that either a physical pendant or the remote one can be connected, if a physical pendant is connected you can only snatch the connection by having it in ext, the remote pendant window goes blank immediately when you click outside the window, and so on...

I do some stuff remotely but usually the option RemoteSupportView is good enough. You need someone on the other end to hold the deadmans switch and accept the connection. I would never dream of teaching points or movements remotely.

I use TosiBox to establish the actual network connection and it it works like a charm. Only thing is the bandwidth is limited (about 10mbit) so moving huge amounts of data kinda sucks.

Anything creating a ring circuit like in the attached picture?

Try putting a continue before the if block on line 33. Uncertain if set_tq_values on line 40 is possible to do on the fly, i expect it would cause and advance run stop. Can you comment it out to test and verify. I believe there is a note about this in the si manual.

Mixing new and legacy motion commands will cause an advance run stop. Sptp and ptp for example. But that is not the case here.

Inv pos is the reverse relation. Like your ideal_pos is a frame from base to the point. Inv_pos(ideal_pos) is the frame from the point to the base.

Hence Inv_pos(ideal_pos):ideal_pos = $nullframe this is also true the other way around.

Inv_pos i very powerful when trying to find the relation to something. Eg if you want to calculate the same point in another base or with another tool. Examples of this is available in the SI manual.

There is a really good topic on this forum by MOM where alot of people pitched in. Cannot remember the topic but something along the lines of "geometric operator in depth" with really good examples and general discussion.

Which motions do not approximate? Some motions do not have any approximation assigned to them. I did not see the open or close tool programs, they surely interact with i/o which would stop arp unless handled.

I have seen a few really odd cases that gave no warning and should have been approximated. But these have been ptp motions with incomplete instructions eg SPTP {A1 90, A2 120} c_spl.

Btw trigger when path works with both SLIN & SPTP. I did not know trigger when path wotked with legacy ptp motions, maybe this has something to do with the problem you are experiencing?

Do you have any mix of new and legacy motions that might be the culprit?

Do you absolutely get no messages when running the program? Approximation not possible messages are suppressed in EXT, but show up in T1 & T2

Hang on.. with 3 points i think it should be possible to calculate a tool frame, but you do not get any error with only 3 points. With 4 you get the error of "fit" also. As long as they are in diffrent orientations, not paralell and so on.

To get the location of a sphere 4 points is needed as 3 does not fully define its position. Holding a ball on 3 points still means the ball can be over over or under the points if you visualize the points laying in a horizontal plane.

But if you do not calculate a sphere (the error of fit) but instead a single point. 3 poses logically seems doable, 2 poses would logically leave the possible toolframe as an infinite line. Cannot defend this all the way, but do a search for "three point perspective pose estimation" it is quite similar. Only which part you chose to solve. I know this is not exactly what was asked but i'm assuming and extrapolating from something i could find quickly.

From the attached picture the assumption would be that S1=S3=S3 and to solve for that.

The picture is taken from a paper called "Rotations, quaternions and pose estimation" by Filippo Senzani

I do not mind the brake release device, but it is bulky, expensive and honestly quite crap. As the robot would always be connected to the ultimate brake release device (the controller) why cant we have the function there? ABB for example has "disable motion supervision". Even as one could macguyver style make a much better version as discussed in the linked thread. I would like the option to do something similar on the controller present and connected. I have not tried anything like it but i think torque monitoring is disabled for a short initial time to not trigger falsely from high starting torques. You cannot run a programmed "get free" program in teach mode as as soon as drives are energized you would get an over torque alarm. But would it be possible to do a small movement 0,5mm from pos_act in aut? (Bco would be problematic) Or if you have vectormove option, could you enabled a servohold move to get the brakes released? Or something similar?

Atleast some Inline forms are more restrictive and do not allow as fast movements as raw krl. Eg lin speeds in inline forms are limited to 2m/s whereas most robots can achieve far more. Especially delta and scara robots.

There is no cwrite command for select, there is only run. Which both selects and starts the program if circumstances allow it. I know this feels odd as there is both stop and cancel cwrite commands.

You can chain ext_start in your if statement too, if that is the functionality you seek.

There is something odd with agilus, larger robots can just jog away with a couple of tries but for some reason agilus is especially sensitive. If you monitor $pos_act_mes you can see if it even moves alittle bit. What i found out is using the joystick just drives the robot more stuck, it goes the wrong way even if you actually pull the joystick the correct way. But using the keys you usually get a small movement per try.

I have been wondering if there is somekind of a software workaround to temporarily get around issues like this. Could there be a programatical way to get away from this, eg. Make torque monitoring more insensitive for a slightly longer time? Has only happened once to me but still unscrewing the robot is not a good solution when you have a crap load of calibrated stuff. Neither is crashing but it will happen to someone at some point.

When calling braketest_req on some kss versions atleast you need to input a bit mask as a parameter. Like braketest_req('b111111')

When you setup vectormove you give it an allowable range if you violate that that kss03195 message pops up. There is also a hardlimit for maximum cartesian range for any move. I believe this is 200mm.

You can limit an axis thru safe operation. This is handy if your tooling is a nailgun or a laser, that you dont want to aim anywhere. However as robot will only stop at the limit, and after user acknowledges you can keep going into the restricted zone, you will have to think and do some extra work on how to accomplish the safety part. Eg. De-energize tooling or similar from the safety signals you can get output from safe operation.

Regular workspaces or axis limits can be changed at anytime and serve no safety function if that is what you are looking for. But these can be as previously mentioned be changed at will and even programmatically. And are handy as long as you do not need them for any safety purpose.

Also note that no robot to my knowledge has a safety performance level higher than pl d. Which in turn limits how dangerous stuff that you can have the robot be an essential part of in the safety system. Unavoidable risk with potential fatal outcomes will bring you to a required performance level pl E easily.

I think that from kss8.5 or 8.6 onwards you can also use ON_ERROR_PROCEED with motion commands. If i remember correctly on traditional ptp, lin, circ are eligible however. But i would personally rather use the inverse function others mentioned earlier for this purpose.

<PM : fixed spelling>

A fair warning, Halcon is not for the faint hearted. It is in my opinion the absolutely most versatile and powerful machine vision software there is. But it is not straightforward or easy.

Where most vision systems more or less regularly provide ready ethernet based communication to most industrial protocols (ethercat, profinet, ethernet/ip, etc) halcon does not natively provide it. If i remember correctly one of the recommended ways was using hilscher CifX cards if you want to use an industrial protocol. But there is quite a bit of programming and setting up required. Note that halcon itself is not very graphical and requires a decent grasp of programming.

For a simple pick and place i would not personally use halcon if you do not specifically need any of its unique features. As the setup time is significant. In truely hard cases or cumbersome setups with dozens of cameras where you can take full advantage of halcons "pay per runtime" licensing type or similarly difficult circumstances, Halcon will surely excel and come out on top of everyone.

But for the simple pick and place stuff i wouldn't bother. Both a racecar and a tractor have their benefits and drawbacks. Sadly for the simpler cases, halcon for simple one off use case is like plowing with a F1 car.

You must use literals in aggregate structures. You cannot assign variables directly inside curly braces {}

However you can assign variables one component at a time

Like:

pickPos.X = 1000 + (i-1) * xStep

pickPos.Y = (j-1) * yStep

..and so on

If you want to vary the speed on a preplanned path from the programmed velocity, the best way is to use $VEL_APPL. Which can limit the speed but not set it above programmed. You can couple this with whatever you like. Set vel_appl in relation to relative humidity of the room, distance to the next point, gluegun temperature, chromodynamic pancake batter mixture density,..., etc. You get the point.

$VEL_APPL should be available from kss 8.6

The other way is to hack with $OV variables which sucks. And i think most agree. But most people have done it at some point with various degrees of anguish, shame and regret.

The last way would be to use the not so much documented kuka function generator (dont remember the name) but you can find manuals and info on it thru this forum.

There are 2 diffrent variables that is ised to request a mastering test. One is internal (robot requests mastering test itself) and the other is external (plc requests). With safe operation the robot will itself request a mastering test and you can use that variable to handle it in your program accordingly. I do not remember them by heart but something along the lines of $REQ_INT_MASREF.

Search the safe operation manual for $REQ and you should find it.

This might be unrelated, but i have a vague memory that for beckhoff serial com modules and similar (including profibus) must be placed as the first slot directly after the ek1100 to work.