Messages

Hello Boy,

Fortunately there isn't a huge difference in functionality between the KRC1 and KRC2 - except memory and the Windows side of things.
A single relevant function does not exist yet for KRC1, which is why there is the checkbox in KUKA|prc for older KRC1s.

1. Why do you think that KRC1 needs an additional *.dat file? It is true that if you teach a program, the robot will automatically split it into a *.src and *.dat file, but this is only for convenience and the program structure. If the KRC1 could not read your *.src file, I guess that you may have used a number at the beginning, or a special character somewhere. Or forgot the checkbox in the settings. Or I'm wrong here, as I haven't worked much with KRC1 myself, but I know that other members use KUKA|prc successfully with KRC1 robots.

2. Safety should be separate from your program, I definitely wouldn't recommend e.g. setting axis limits on a per-file basis. If the robot won't let you run a program, you probably either haven't installed the safety equipment, or didn't override it, e.g. with a bridged X11.

3. Alex is a great teacher, so following his course sounds like a good idea - however I don't quite understand the question here.

4. It would be great to have you as a member! Regarding the robot - if you had a free KRC2 controller around somewhere it may be worth giving it a try. If not I'm 99% sure that it is not worth the time and trouble trying to upgrade an old KRC1 robot. I've seen very usable looking KRC2 ed05 robots for around 12k EUR from companies, and if you are lucky to come across a factory line that is being dismantled you can get them for much less - sometimes they even have spare ones with hardly any operating hours.

However, from your post it seems that you have more underlying issues with the robot configuration, which won't be much different with KRC2. So it probably make sense to try to get the KRC1 to work, and if you then run into memory problems etc. to consider upgrading.


Hope that helps a bit!
Best,
Johannes

Hello,

The manual is really helpful there, status and turn basically describe the posture of the robot with a series of 0s and 1s, if an axis is in the positive or negative range, overhead or not. If you program it wrong, you will get "out of reach" errors.
And yes, PTP is in % of the maximum speed.

Singularities are just a mathematical reality and the things you can do on the robot side to avoid them are limited - after all you wouldn't like your robot to leave its path to avoid a singularity. Only with certain applications like milling you can influence them quite easily as the tool is symmetric, i.e. we can rotate the tool axis without any negative impact. E.g. PowerMill has got a nice graph where you can change the orientation, as you would do in KUKA|prc with the Orient Plane component.

It's much easier to consider them in the simulation and move your workpiece or robot - having an extra external axis is extremely helpful as well.
PTP movements do not suffer from singularities, so you can use series of PTP movements as well - of course at the expense of accuracy.

Best,
Johannes

Hello,

If you had the wrist turning you probably went close to a singularity. You can try to place your workpiece differently, so that the axes of the robot don't "overlap", avoiding the problem from the start.
Turning just one axis won't solve your problem, as - unless you turn by exactly 360 degree - you will have to adjust your other axis anyway.
Let's say you are close to the limit at -175 degrees and turn by 360 - now you are at +185, i.e. exactly at the axis limit of the robot at A4.
I would really recommend using PTP with Status and Turn for these things - the KUKA manual describes it in detail. Or you just have an intermediary position described in absolute axis values - works as well.
I stand by my opinion that relative movements are not particularly useful in a CAD environment. That being said, they should not be difficult to implement, so there is a chance they will make their way into KUKA|prc.

Best,
Johannes

Hello,

The component that you are showing in the screenshot is not an axis move component, but it extracts geometric or axis data from a KUKA|prc movement. It will only output an axis values for axis movements.

Axis move is just a fundamental movement type, where you define the position with the axis values, which has got the advantage that it's uniquely defined. Personally I do not really see the need for relative movements when you are working within a CAD environment as you can have absolute values anyway. They are extremely helpful when you are writing code manually, though.
In any case, if you want to unwind the robot, you can either use axis values, or alternatively PTP movements with status and turn defined.

Best,
Johannes

Hmmm... This could happen when Rhino has to draw large amounts of geometry, i.e. when the drawing time is significant in relation to the computation time.
As I said, I'll look into it, but it's not an ideal situation to start with.

Best,
Johannes

Hello,

By default, the Play component tries to automatically adapt itself to the computation time of the entire solution, but if you set a custom refresh it will try to enforce that, no matter how much performance it takes.

I'll look into making it more reliable, however it seems to be quite an underlying problem with Grasshopper, as its internal Timer component comes with a widget that operates outside Grasshopper to avoid these problems. Maybe I can integrate something like that...

Best,
Johannes

It may differ by region, I sent you an eMail!
Best, Johannes

Hmmm... The robot already knows where it is in space at all times, so maybe you don't need the live feedback, but could just program the toolpaths based on a finished piece, which then grind it down to the desired shape?

Best,
Johannes

It's a file that is cyclically executed in the background, SPS stands for PLC in German.
It should never contain movement commands, but can contain logic that e.g. triggers outputs based on system variables etc.

Best,
Johannes

Good idea, we'll dedicate the first section to you ;)
...but to be frank, it seems that robot training is a big business and people make more selling training sessions for a couple thousand Euros, than a few books for 30 Euros each.

Best,
Johannes

Hello,

This is exactly what the RobotSensorInterface (RSI) is made for - you collect some data with an external sensor and then use a real-time capable system to stream toolpath-offset coordinates to the robot. It should be available for KRC2 as well.
A more simple solution may be to e.g. adjust the tool calibration through code, something like this...
$TOOL.X = 125 + $ANIN[5] * 10
You can then put it in as a Custom-KRL component and call it throughout the code. Maybe that could also be run through the sps.sub (but try it in regular code first!).
I did not test that, but it seems plausible ;)

Best,
Johannes

Hello,

Do you have any photos of how the parts would look like?
I don't believe that any off-the-shelf solution would be particularly affordable, so you may have to hack something together, or combine the robot with other machines.

Best,
Johannes

Hello,

There are some very useful posts regarding that on the robot-forum:
http://www.robot-forum.com/robotforum/kuka-robot-forum/krc2-io/
http://www.robot-forum.com/robotforum/kuka-robot-forum/krc2-io-mapping-question/
It should help you set it up. With KRC4 it's a bit easier through an actual graphical interface, in KRC2 you need to delve into the iosys.ini.

Best,
Johannes

Usually KUKAs are shipped with (a printed) electronics plan for all plugs. It's - as far as I know - not possible to get a full documentation for the entire control unit, though, only for the connections that are usually relevant to customers.
If you are missing that documentation, you could try asking KUKA for another copy.

Best,
Johannes

Hmmm... I think that the separation of the curve is indeed the easiest way to approach this if you need precise control over where it is triggered.
I'll think about it some more, and will let you know if I find a simpler/smoother solution.

Best,
Johannes