Messages

Hello Jason,

I can't give you any exact numbers, e.g. for the maximum file size, as even KUKA does not provide them. But in general I really wouldn't go for a KRC1 controller as the price difference isn't huge. For most types the mechanics will be more or less identical and there are no great differences in code and capability (on a higher level, there are definitely many smaller improvements). It's really mostly about the file size. As far as I know KRC1 also does not support the USB port, so you will need network shares or floppy drives ;)
Windows XP is only available in the newer KRC2 controllers.
A KR150 with KRC2 controller is definitely a good idea!

Best,
Johannes

Got it, I'll have to think about a way to do it without needing a Core component with 24 inputs!

Best,
Johannes

Hello Jason,

KUKA|prc creates *.src files that you can execute on the robot, also on a KRC1 controller. We also support live control through mxAutomation (only for KRC4), and know several users that use KUKA|prc for pathplanning and then integrate their own solution for streaming the data to the robot.
As you correctly mentioned, you can use the serial port for communication, or you could also use e.g. the digital inputs like the buttons on the gamepad, for left, right, up, down...
In each of these cases the challenge will be the data flow if you want to achieve a fluent motion. KUKA|prc will be useful for the path planning and reachability checking, as well as e.g. getting the XYZABC frames to send to the robot.
In general we do not really recommend anyone to get a KRC1 robot as the memory is very limited, so your filesize is constrained. If you mostly want to stream data, that may not matter as much as for other users, though.
So your KRC1 real-time control (real-time not in a sense of a couple of milliseconds) via the serial port is generally definitely possible, but it will need some playing around with, especially if you want to get a smooth movement and not just go to one point, stop, and then go to the next one.
I've attached the serial documentation!

Best,
Johannes

Hello,

Well, the WAIT FOR only waits for the switch to TRUE, it does not matter how long it is. You could make some kind of logic that waits for a few seconds and checks if the value is still TRUE if you need a specific timespan. Or you could solve that in hardware as well on the signal side.

Best,
Johannes

Hello,

WAIT FOR $IN[5]
...would wait for input 5 to become true. See also page 99 of the KRC2 Expert Programming manual!
I could make a component for that, if it is helpful for your application!

Best,
Johannes

Hello Karl,

We recently implemented a simple solution where we have a global variable set whether the extruder is on or off (let's call it EXTRUDE). In the submit interpreter we check if EXTRUDE is true, and if so the speed is set according to the current speed of the robot's tooltip. That way we can compensate for the sometimes not perfect speed control of the robot in realtime. On the KUKA|prc side all you need is a Custom KRL component that says e.g. "EXTRUDE = TRUE" or "EXTRUDE = FALSE".

An even easier alternative would be to use an actual KUKA motor that you control with e.g. E1, but then you may need to expand your KRC cabinet, which is quite expensive (in addition to the motor).

Best,
Johannes

Hello Walter,

That is actually quite straightforward, refer also to section 14.7 in the Sunrise OS manual.

lbr.move(MMCMotions.handGuiding());

ESM are basically sets of safety rules that you set in the SafetyConfiguration of the Sunrise Workbench. For handguiding you could create a custom ESM (it will show up next to the PSM), as the AMF choose "Hand guiding device enabling inactive" and as parameter choose a safe input for the 1st enabling switch - if you've got an iiwa with a touch flange, go for that one., otherwise you will have to use one of the safe inputs. As the reaction, go for a Stop 1.
You can enable e.g. ESM 1 with lbr.setESMState("1"); - do that before the handguiding command.

Finally execute the program in AUT, the robot will stop at the handguiding command. Now keep the enabling switch pressed and press the green arrow start key to start the handguiding. Once you release the enabling switch, the handguiding will terminate, i.e. the robot will continue with the next command. So be careful that you don't get hit by the machine.

I usually have a second ESM with collision control at 15Nm or so that I activate immediately after the handguiding. For collision control you need the relevant safety options, which are not included by default.

Best,
Johannes

Hello,

If you are using global functions, don't put them again into the KRL file, but just call them via e.g. OpenCollet() in the KRL component.
You could also put functions into the code pattern in the settings, if you want to change them depending on the project.

Best,
Johannes

Hello,

We usually get our grippers from Schunk and also got one from Sommer - and there are plenty of other manufacturers out there as well. The most common grippers are either electronic or pneumatic. If you want to save costs and reduce complexity, I would recommend going for a pneumatic gripper, for which you will need pressured air - though the requirements are not very high, any small compressor should work.
You also need a valve to control the air, ideally get a valve that you can actuate with the 24V that you get from the KUKA's IO boards. If you're using an Agilus, it has got integrated valves on A4.
If you need just any gripper without any very specific requirements, I would recommend taking a look on eBay . you can often get grippers that would cost a couple hundred Euros for a tiny fraction of their price. With pneumatic grippers there isn't a huge risk regarding compatibility either, as you may only need an adapter for your tubing.
Note that there are no specific KUKA grippers, so you will need to 3D-print or mill an adapter plate to mount it on your robot.

Best,
Johannes

Hello,
If you define all positions clearly with PTP movements including status and turn then the movement will be largely the same in both directions.
LIN movements depend on a previous posture and will interpolate linearly from there on, so there can be differences.
In a smaller scale there will also be differences when the robot is blending movements in a different direction.

Two more things: In my file from before I set the position accurately with status and turn - meaning that if you move the position that may not be a viable solution anymore. Also, I've noticed that your custom tool has got a very high resolution. I would recommend reducing the complexity of the mesh with the Rhino command ReduceMesh. That will speed up your viewport, especially if you do collision checking.

Best,
Johannes

Hello,

The problem is that you are turning more than 360 degrees. While A6 can got from ca. -355 to 355, you "lose" some degrees depending on where you start.
So in the attached, edited file I added a PTP movement where I directly defined the posture with status and turn. Then I shifted the start movement so that we can fit it into the axis range.
You could also set A6 to rotate infinitely (right-click on the option for the simulation, edit the machine data for the physical robot), however then you would need e.g. a slip ring for the power supply of the hot wire.

Best,
Johannes

Awesome - you figured it out yourself, but if I make it to Tasmania again I'll gladly take you up on the offer!
All the best & don't hesitate to get in touch if you run into any other issues!
Johannes

Hello,

You can basically use any axis you want for the wire, it's just important to match the physical and virtual model. The Z-axis is only convenient because you can define it with the Plane Normal component, and adjust it via the Rotate Plane component.
So if you want to use the X-axis, you have to define your tool e.g. with the Construct Plane component and set X along the rulings of your cut surface. By changing the direction of Y, you adjust from where the robot is holding the tool.

Hope that helps!
Best,
Johannes

From my experience there are plenty of pitfalls, especially for inverse kinematics ;)
E.g. how do you react if a position is not reachable? Is the axis then 0, NaN....? Just as a very basic example.
What we did is that we created a "fake" robot - basically a simple GH component that took the RSI commands and visualized them. That helped with troubleshooting!
Consider looking into how to give your server process a rather high priority. Or as a stop-gap, just right-click the process in the task manager and assign the priority manually.

Best,
Johannes

Ah, OK, now I see what you want to achieve - I must have somehow blanked out before.
In any case, you can obviously also use KUKA|prc for forward/inverse kinematics, or try to use the relevant methods from the KUKAprcCore.dll. However, we don't officially support that.
If I remember correctly, Daniel Piker once wrote an open-source kinematic solver for Grasshopper.
Also, consider that Grasshopper isn't really the best platform for actual real-time applications. So if you get stutters in your movements, that may not be your interpolation algorithm, but rather a brief communication pause.

Best,
Johannes