Posts by Hes

Quote from foffulaRob

I've tried using "SET_TORQUE_LIMITS(1,{lower "value", upper "value", monitor #off})" and "RESET_TORQUE_LIMITS(1)" in the past and it worked when I needed to move the robot to a position without force it.

When working with torque mode you need to set the correct parameters. And make one move to actually activate torque mode. Torque mode is not active until you make a move, this can be a PTP $POS_ACT or similar if you do not want the robot to actually move. I do not know what your setup looks like but you have it set to apply to axis 1 and said the part rises so im guessing that this is incorrect. Also pay attenyion to the torque limits and the sign, have on more than one occasion near to lost my mind finding that torque limit sign is the other way around. I usually use the system variable $TORQUE_AXIS[] (if memory serves) to check the actual torque and sign with the brakes released

Well, depending on if your camera is mounted on the robot one good way is to take the coordinates you get. Reposition the camera over the part and repeat the procedure. Once you have done that a couple of times the error will be negligable.

Another way is to pick a longer focal length and move camera further away, as that will make the distortion from perspective smaller the further away you are. keep in mind that when translating a feature detection to a point in space it will be projected on to your calibration plane.

Another tip is to not teach the whole contour, pick something that will not be affected as much. And something that is as close to your calibration plane as possible. and if it is not in your calibration plane, recalibrate at an appropriate height or recalculate the given coordinates to the actual coordinates in which the feature you are locating is at. I tend to do this often, especially with short focal lengths/wide fields of view or when product height is varying.

avoid locating things simultaneously that are skewed or at diffrent heights as that will impact the precision you can and will ultimately achieve.

Later on once you´ve done all that, you can still compensate by strategy. eg. grip the part several times to center it. drag and push against it to know where it is at. use a distance sensor to find or locate a specific feature to fine tune where exactly to pick the part, (eg a cylindrical part with a hole in it.).

That for starters. Been awhile since i' ve done anything cognex related but i'm sure there is somekind of perspective transform available. but I do not see an easy way of implementing it and having an easy way to refer back to calibrated real world coordinates in the transformed image so it wouldn't be my first approach.

i have been holding my breath for any new posts on this thread. I do hope there will be more on this and similar topics as they are actually very interesting to read, and i am assume many agree. Small coding challenges or similar would be one thing that i also would find educational and fun, maybe others also agree?

I've only done this with profisafe and physical inputs but the way i have done it is with a separate zone interlock bit on the none safe side. So when the plc does restrict the use of a space it sets the corresponding UER bit to activate the space and also set the none safe interlock bit to whatever state representing "not allowed" at the same time or slightly before.

I set a decent point exactly or close to the zone with a sptp or slin. And use "stop when path" to stop the robot before entering the zone if the non safe interlock bit is in "not allowed" state. If the robot would miss the interlock signal it will trigger an emergency stop upon entering the zone. Robot will also stop even if the user manually jogs it in to the restricted zone or tries to bypass it in by skipping lines. As long as the plc has activated the UER signal of said zone. Only way to bypass that would be either fiddling with safety config in either plc or robot.

There is an interesting segment in the system integrators manual regarding "braking before restricted areas" that i do not know by heart if it could be applicable or helpful but might be worth taking a look at.

I figured it was best to use a separate non safe bit to actually handle not entering restricted zones or lowering speeds. As i didnt find a good way to access them and you also want to know beforehand. E.g. if you want to lower speeds say if safe braking distance cannot be maintained and robot hence needs to move slower. You first need to actually tell the robot beforehand to lower the speed, before activating safe speed monitoring and BEFORE user can get closer to robot. Then robot needs time to decellerate, and then plc can activate speed monitoring thru safe i/o. Hence safety stuff is always handled on the safety classified stuff and cannot be manipulated. But the non safe handshakes, signals, interlocks takes care of telling the robot beforehand how to react to not trigger a safety stop due to violating max speed or being in a not allowed zone etc.

i'm following this topic closely as i am equally interested in this. Time has been constrained so i have not gotten around to do something universal yet, but i'm hoping to develop somekind of helper tools to alleviate code testing sometime in the future.

Currently i often end up writing specific testing programs that hammer logical code with diffrent test cases (random values, edge cases, faulty values, etc). I even sometimes if there is dynamic paths in a program chunk them out and test in a separate loop to verify functionality.

One tip i would have is to not only test that good parameters work but also remember to verify that a faulty condition will not run.

I often rely on alot of error handling in my code and it has saved me alot of trouble, but code may sometimes become lengthy.

as you stated you made lots of pick and place applications previously finding documentation should not be an issue. As you said you have a backup from a similar project but it is too complicated, i would take that as a good sign to hire someone else to do it. If finding documentation is this hard, when it is free and openly available and first pinned topic in this forum more or less explains in meticolous detail how to get such things and from where. I would not recommend attempting it yourself. There will be actually though and hard to figure out things along the way but if you cannot even get to the starting line on your own why even try?

Isn't there a kuka hot line in the us? If not call the german one. They usually pick within a minute or two and simple things can be sorted out with one phone call.

If you have a recovery image why not put that in and restore latest working archive?

Quote from nicok

If I only want to use SPTP for the sake of a single PTP motion I shouldn't need to program any additional points in between my start and goal as all the spline supports are computed by the robot controller, is that correct?

That is correct, you can replace a single ptp with a sptp to the same point. I do not know if it holds true but sptp's seem smoother than traditional ptp moves. Im speculating this is because they are bound by diffrent limits

it appears i made a blunder. For ptp acc and vel is of course max 100% for cartesian motion you have $VEL_MA and $ACC_MA that defines max values.

and if you have oscillation problems easiest way is to stiffen up your tool, decrease acceleration or both. Setting correct loads and inertias are also essential to make motions smooth. There are also parameters for jerk if memory serves (derivative of acceleration). You may want to keep a high speed but decrease acceleration and jerk alot to keep it from oscillating if tool is flimsy. On abb's you get one more parameter so you get vel, acc, jerk and snap. But i've never felt the need for the last one atleast. If your tool is flimsier in some direction you can quite comfortably set $ACC_AXIS[6] to something decently low if it is sloppu around flange z axis. If it is sloppy in both swiveling and rotation, i would suggest setting $ACC.ORI1 and ORI2 to a decent value and keeping critical moves as LINs. Also approximation strategy could be worth checking eg. Diffrence between c_dis and c_vel. Could also be worth checking out newer S type motions. There are some experts on pancake chromodynamics and kuka motion related stuff on this forum. I think Fubini would have valuable input on this and surely others too. But stiffening up your tool and lowering accelerations and setting speeds, approximation etc up perfectly would be my suggestion. Many times you can also orientate the tool in such a way that it does not flap around that much when you do big moves.

Quote from nicok

What joint acceleration values does the robot realistically use? In the KUKA docs I haven't found any information at all so far and I don't know if the range is something like 250-500 °/s² or more like 5000-10000 °/s² or anything in between. I only need a rough estimate to know the range I am working with.

You can check $ACC_AXIS_MA[] there might be a typo in the variable name but it should point you in the right direction

btw getting lin and circ motion speeds correctly set up requires first of all $TOOL_DIRECTION to be correctly set up (watch out theres two variables that needs to be set, believe the other is $TOOL_DIRECTION_LIN_CIRC). Then relevant structures $ACC, $VEL AND $APO needs to be set up correctly. Check this forum for "swivel and rotation" to get a good grip on which is which *.ORI1 and *.ORI2. Suitable approximation strategy must also be used as eg. If you are turning around tcp using c_dis will not make for any smooth motion. So that also must be taken care of c_ori, c_vel, c_dis, c_ptp or c_spl.

With that set up correctly and should be fairly easy to get a smooth motion profile.

First of all thanks for the response. Alot of stuff seems daunting like the limited "hackability" and the 2 diffrent programming languages (can these be mixed or is it either or?) Like i guessed this is a can of worms that creates more and more questions. But the summary provided gives the main pointers i was looking for. I've signed up for a fanuc account, any good pointers what a good place to start digging would be? Like kuka i would get to start with: kss syntax 8.x, system integrators manual, system variables 8.x as a bare minimum and go cover to cover. What is the equivalent with Fanuc?

do not know any way out of this other than reinstalling a previous image. Tampering with the wrong ip address settings usually ends up like this. The KSI port is normally configured to act as a dhcp server so the only thing that would normally be required is to set you laptop to obtain ip address automatically.

hang on.. isnt ptp motions only limited by axis speed $VEL_AXIS[] and axis acceleration $ACC_AXIS[]? Atleast that has been my understanding. $VEL or $ACC would do nothing for a ptp motion. But as SkyeFire wondered what is wrong with the original path and motion planner?

check mastering as earlier stated also, lin movements not being linear is a pretty sure sign that mastering is not correct.

Hi,

I'm coming from an almost pure Kuka background but will have to do some work with Fanuc in the future. What would be the main diffrences? Stuff thats good to know? Where do you find relevant programming manuals? Are Fanucs as open as Kuka to modification? Options, what are the most common? How do they compare to kuka? What hardware is used for i/o? Have anyone else gone the same way, and what is your experience? IDE for programming, what is commonly used? Are fanucs big or little endian? Datatypes any special quirks? General program structure for fanucs?

I will take a programming course within some weeks. But still would like if anyone has gone the same route or has any opinions. I'm guessing I would very much like someone to explain the details and diffrences between fanuc and kuka from a kuka programmers point of view.

If you use is_key_pressed() to monitor for statuskey presses in a submit and react accordingly (set outputs) it does not block setting outputs even when program is running.

i have a hard time figuring out a valid reason to downgrade. I would not expect that the hardware is compatible for such a downgrade either.

Forgot to say $CYCFLAG must be used for the interrupt condition when the expression becomes more complex than a simple boolean. But it is simple to just assign the required conditions to a cycflag and use that in your interrupt.