So I've been archiving all the tools I've ever used with kuka|PRC for archival purposes, when I was reminded that the tool mesh is inputted differently between PRC2 and PRC1 (and between X and Z for the latter)
Whats an easy way to transform the tooling mesh between PRC1 to PRC2 and vice-versa?
Given that I have the xyzabc of all the tools, I figured all the information was there to do the conversion, but I've never really wrapped my head around that transformation :-[
Hello,
I don't think there is an automated way to do that. In KUKA|prc v1 the toolframe was equivalent to the Rhino coordinate system, and for v2 it made more sense for us to set the Rhino coordinate system as the flange - this way you can e.g. use the same 3D model with multiple tooltips.
The easiest way is probably to find the center of the flange of your tool and then transform it to the Rhino origin.
I often construct a circle out of 3 points in Rhino and then snap to the center!
Best,
Johannes
but wouldn't it stand to reason that the transformation from base(v1) to flange(v2) is already embeded within the xyzabc data?
I will try and fiddle around with that..
Don't really want to manually orient the 10 or so meshes, especially as the base never seems to line up when I try :(
that and it'll double the filesize and it's already pretty laggy..
That's right, but the XYZABC data is not exposed to Grasshopper. If KUKA|prc gets slow, the reason might be very complex toolpaths, but often it's also a very large tool mesh. Always join meshes for the tool into one mesh, and use the Rhino command MeshReduce to reduce the meshes' complexity.
You can further improve performance by hiding the tool frames and disabling the Analysis output (which is off by default, though). There is a performance slider on the first page of the settings that does these things automatically as well.
Best,
Johannes
gronked one together, attached in case anyone else needs a quick convert :)
mm, always found the unexposed portions of PRC slightly confounding, though I guess its just a different design philosophy..
It's slowing down because, as the Master/Reference file, it holds 10+ quite heavy if individually manageable meshes that, together, become unmanageable.
Was looking for a quick plug'n'play system, but in this case I'll have to settle for a conversion tool I think. Still better than 20+ meshes freezing up gh though >_>
mostly I have to forgo most of the simpler* options as it'd just confuse the end-users (i.e. other people in the practice :P)
Thanks anyways,
woops, X is facing the wrong direction >_>
and forgot to program for Z direction (I'd forgotten that was an option in v1..)
but still useful with a bit of tinkering :P
Hello,
Well, the XYZABC is an input, so it would be confusing to output it at the same component.
With one of the more recent member versions it's also possible to numerically set the tool (rather than as a plane or through the menu) - I know that this doesn't help you right now, but I just wanted to let you know!
Best,
Johannes