Posts by Hes

I think interrupt declaration is missing from the list, might have been mentioned previously also

Hi,

Has anyone found a way to display variables in a "selected" format in the "display -> variable -> single" view?

In other words, is there a way to show a variable as decimal, binary or hex under this view?

I would check the mechanical parts to rule somethin out. It looks like there is a shaft hub connection in the center of the table. These usually connect a smooth shaft to a smooth bore. Try wiggling that around if something is loose, retorquing it wouldnt hurt.

Do not know what the actual drive mechanics is. But eg. If there is a servo and a planetary gear they often have a smooth shaft clamp connection. If that kind of connection slips it can be quite notorious to figure out. Same could also be true for the connection to the resolver.

Putting up a reference mark at a certain angle would be nice to verify if it actually has slipped or the problem is elsewhere.

This may very well be that i am barking up the wrong tree, but i started thinking about the precision of the resolver on the rotary table. If it is allowed to just increase you should at some point start to loose precision as you only have a certain amount of valid digits on the rotation. Reteaching should not however fix that.

Depending on the mechanical setup and where the resolver is actually attached there will be more or less play in the system that could affect this.

Is it drifting to one direction? Is there alot of free play in the system? How is the resolver attached?

Atleast a few years ago i can confirm that it was free for a robot running kss 8.3

Yes but cant remember the exact steps but robot button and thru a few menus, you will also find the call stack close to it

Perhaps the easiest way would be to make cycflag with the conditions $stopmess or $in..

And set the cycflag as the trigger for the interrupt instead of the standard $stopmess

If i understand you correctly you want to run ir_stopm in either case.

Is braketest requested internally or externally? If it is external, it must be acknowledged and the request dropped otherwise you will be stuck.

I think the requirement is actually that you must keep the pointer deeper than the routine where the interrupt is declared. If you plan on triggering it. Otherwise Resume would not have a clear purpose. Interrupt with resume wipes the call stack up to where the interrupt is declared. If the pointer has gotten there, nothing can really be killed in the call stack.

I'd say an ARP breaking statement is good enough WAIT SEC 0, WAIT FOR TRUE, etc. There is no need to set advance to 0 for this purpose.

There is a section in the SI manual with examples if you search for something along the lines of "soft servo". I have done this for 7'th axes mounted on tools. As SkyeFire implied it depends on the axis and the mechanical setup. For "own" optimized mechanical setups this works extremely well. For axes with large minimum holding torques it is close to garbage.

Robot axes are not as easy to drive backwards as fowards with the gearing in between physical axis and servo motor so hence results will vary. For low planetary gear ratios, gear racks, timing belts and ballscrews designed for the purpose, it works wonders. For the cases i've done that I've optimized mechanically i have not even had to calibrate the force values (more than some slight stick slip due to kinematic and dynamic friction differences)

The agilus KR10 is unbelievably sensitive in this regard. It will immediately trip overtorque when tried to move from a strained/stressed collided position. Where the larger robots just jog free with 1 or 2 attempts. Have not seen any diffrence in using the collision override. Im unsure if it does anything at all. Using the 6D mouse is a no go as robot wiggles when brakes dissengage while using the mouse. And it often goes the wrong way when the robot is pushing against something.

Using the pushbuttons and monitoring $axis_act_meas or $pos_act_mes you will see some 0.001mm movement for each push and overtorque trip. You will eventually get free.

What i've heard most people unscrew the robot and get free that way with alot of touching up and recalibration to do.

A brake release device is available but is such a specialty item that you will practically never have it when you need it.

I have thought about a programmable solution if this would occur. But as this is something I have only seen twice, it wasnt at that point worth the effort. I wonder if anyone has checked with kuka? Maybe there is a brake release overtorque filter time that could be temporarily adjusted for this purpose. Perhaps setting an axis to torque mode and the minimal holding torque could be able to release the tension of the axis? Never tried but it might be feasible. It however requires one move to activate, even if that would be ptp $pos_act

There are other threads on this forum regarding the same issue, but i have not seen anything "innovative" or workable yet.

If you are using expertech touching up arrays works just fine.

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?