Messages

Hi Johannes,

I think I was finally able to sort things out, I didn't notice the "Custom Tool: Plane" component automatically turns the tool by B=90 degrees
(it's also clearly explained in the component help window, I just missed it)

if I was a good mathematician I would be able to extrapolate ABC values from the rotation matrix... but I'm not
so the best solution I found is to use your Custom Tool: Plane component together with Putterfish's Rotate Euler component

hopefully this might be of help for other non-mathematicians like me:)

given a tool with correct ABC values, but where XYZ axis need to be rearranged while keeping the very same reference system orientation:



this way the ABC values listed in the tooltip of "Custom Tool: Plane" are recalculated by your component, and can be used to re-define the very same tool with rearranged axis (both in KUKAprc and in the KUKA itself )

Hi Johannes, thank you for helping out on this

I have done some research in the afternoon
from what I have understood, adding/removing 90 degrees to a single A/B/C value will not maintain the correct orientation of the other axis in the system (unless particular conditions are met, like maybe you might change B by +/- 90 if C=0 or similar cases)

I can very easily be completely wrong on this,
it's a very interesting topic and for sure I will dig into it in the coming weeks/months, but today I really had to find a solution to have our arm working again,

so I have used Rhino to do the following:
-> create an axis system that matched my current Tool_ABC values (that I want to reorient)
-> rotate this axis system -90 degrees around its Y, in such a way it reflects my final result
-> use galapagos to recalculate ABC from scratch (this was a bit time consuming because I had to narrow down the ABC slider values step by step, until I could measure an error as small as possible, in my case error between XYZ and X'Y'Z' reoriented axis angle [absolute value] summed up together --> smaller than 0.01 degrees)
note: Galapagos is not the best solver for this problem, but I wanted numbers :) so I gave it some more time

this way I got some new "random" ABC values that I can just write down to define a new tool with very same XYZ values

---------------

Edit#1
actually nothing changed: the tool keeps being slightly tilted


---------------

Edit#2
by changing tooling axis from X to Z, I also got some weird ABC outputs in the src file, like all A B and C never being 0 but -90 for some reason
the simulation on KUKAprc looks perfect, but when I try the src file on the KUKA (same base and tool calibrations, triple checked) the program is not executed because of "workspace error"

Hi all,

I start a new topic based on this old one: https://forum.robotsinarchitecture.org/index.php/topic,401.msg1133.html#msg1133
because at that time KUKA PRC did not have the option of using Z as tool axis

until now I have used X as a tooling axis, and I have very precise tool calibration values we have achieved in the last months

tool axis are oriented as per this image:


I would like them to be oriented like in $World, which requires a rotation around B by -90 degrees

A= 0.16  does not change
B= -49.945   becomes  -139.945
c= 0.411 does not change

after using these values in KUKAprc (and chosing Z as tooling axis) the tool does not look straight anymore, it looks like the Z axis is slightly in an angle

I think I am not doing it the right way, could plase someone enlighten me on the right procedure to follow?

Thanks!

very clear, thanks a lot!

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

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