Multiple KUKAprc core components on same GH canvas

[AleInno]

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? :)

[Johannes @ Robots in Architecture]

Hello,

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.

Best,
Johannes

[AleInno]

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... :)

[Johannes @ Robots in Architecture]

Hello,

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.

Best,
Johannes

[AleInno]

very clear, thanks a lot!