Recent Posts

Pages: 1 2 [3] 4 5 ... 10

Only the base number is saved by default in KUKA|prc, so you can just program it all on e.g. base 6 and then on the robot you just need to change the XYZABC values of that base, either with numeric input or the 3-point calibration.
Or you create ten different bases and put some KRL code at the beginning of the file that in a loop cycles through them. I don't think you can change the base directly while a program is running.
So if there are only small changes there is no need to go back to GH.


Support / Re: Multiple KUKAprc core components on same GH canvas
« Last post by AleInno on March 07, 2019, 02:11:50 PM »
the reason for "stitching" multiple KRL codes is -more or less- the following:

basically, I have 5 different locations around the KUKA where every day, twice per day, I mount small artcrafts to be milled by the arm itself
these five parts are never exactly identycal among each other, they are just "very close" to identycal, so every time I need to tweak each base (just a few mm)

until now I have just hardcoded the position of those five artcrafts in KUKAprc as XYZABC coordinates in reference to $WORLD (base zero)
that approach works fine: I read the value of those BASEs from the KUKA smartpad and write them down as reference planes in grasshopper
then I update the solution in KUKAprc and I get the updated KRL code for the new positions

doing this task 10 times per day becomes pretty time consuming and also human error while copying numbers becomes a possibility

by having a single KRL file that works around multiple bases, I would just update those 5 bases by touching the 3 reference points with the KUKA, and the very same KRC code would still work... maybe... :)

You should be able to have as many Core components as you like on the canvas.
The base can be set via either the BASE input or the regular KUKA|prc settings. We always assume that the Rhino origin is the base, so you cannot switch that around during the process.
I don't understand why you would stitch the KRL code together from multiple machines, but that is possible as well of course. Note that Grasshopper gets really slow when you display thousand lines of text in a panel, so only use the panel for debugging.
Try to end with an axis position that matches the first axis position of the next file, otherwise the simulation won't be reliable anymore.

Support / Multiple KUKAprc core components on same GH canvas
« Last post by AleInno on March 07, 2019, 01:07:04 PM »
Hi all,

I was wondering if it is ok -and if it can be considered good practice- to have several KUKAprc core components in the very same grasshopper canvas

I have several bases that I'd like the KUKA to use in succession for different tasks, and the only way I have found to define a base in KUKAprc is to connect a frame component to the CORE component BASE input, so it will be the very same base for the whole simulation of that CORE component

by being able to have several different KUKAprc COREs in the very same GH canvas (same tool and different base for all of them) I can program a serie of movements, and then stitch their Analysis -> KRL outputs together in a single src file

I would like to avoid editing the KRL outputs, just stitch the different codes together: the only downside to this is that the KUKA will move to the next home position between a code and the other one

does this make any sense to you? :)
General Discussion / Re: Need a gripper for KUKA KR6
« Last post by Johannes @ Robots in Architecture on March 06, 2019, 08:40:26 AM »

If you are just starting out my suggestion would be to look on eBay as you can find grippers for really cheap there (also depending on where you are located). Otherwise the manufacturers will get you in touch with their local representatives.
We usually use grippers by Schunk, but there are also many other brands around.
Most grippers work with pressured air, so you will need a compressor. From there the air goes into the back of the Agilus and comes out through one of the three valves on axis 4 (6 openings closed with screws). Usually a gripper has got at least two ports: One side where the air opens the fingers and one side that closes the fingers. If it is spring loaded it might also just use a single port.

Note that a gripper comes usually without fingers - unless you order them with it. Schunk also has that eGrip design system, but basically they will just laser sinter the finger, which you could also do with custom designs:

General Discussion / Need a gripper for KUKA KR6
« Last post by smw11 on March 06, 2019, 08:01:25 AM »
Hello there, my name is Yorn..

I need a gripper to practice brick layering,I have only bare robot arm.
Is anyone here have some idea where I can buy it?
The one that I can practice with KUKA PRC sample files..

Any suggestion would be appreciated
Thanks in advance
Great, thanks for the update!
My suggestion is to always first get the turntable to synchronize properly and only then to start with SRC files!
General Discussion / Re: Integrating 7 axis on KR150 KRC2 ED05
« Last post by designfugitives on March 05, 2019, 12:26:13 AM »
Found the information I needed in a diagram - 2 wires were no connected.  Got the 7th axis turning.  Figuring out kinematic systems.

Support / Re: Digital I/O Curiosities
« Last post by Johannes @ Robots in Architecture on February 28, 2019, 11:06:56 PM »
Now that's an interesting catch!
In practice it shouldn't make a difference as the IOs are basically triggered at the same time, but I'll still try to find out what went wrong!

Support / Digital I/O Curiosities
« Last post by singline on February 28, 2019, 07:09:50 PM »
While setting up a script that is using multiple digital outputs and I need to switch between two within 2 lines of KRL, the output src swaps the order of the $OUT variables. Doesn't happen if there's a line of KRL in between them, is there a purpose for this or a workaround?

Pages: 1 2 [3] 4 5 ... 10