Messages

Hello Mohammad,
In general, the axes take their numbering from the order in which they have been added.
So if you have got a linear axis (as E1) and then add a turntable, it will be the E2. Internally there are ways to change that, but not through GH components.
For the DKP, there is actually an option in the right-click menu to change the axis order!
Best,
Johannes

Hello Alex,

Ask me something easier, with RiA on one side and the university on the other side, the time for the "new" PRC usually happens when my schedule clears unexpectedly.

Honestly the challenge is that KUKA|prc is now very well tested, stable, and relatively fully featured, so doing something that does "more" is hard, considering that users don't see whether the code behind it is janky or well structured ;) But the next PRC will definitely have some nice, new things that are not possible with the current KUKA|prc releases!

But thanks for the offer regarding testing. RoboTeam is definitely on my todo list to explore further, once we have got a suitable project that requires it, I might take you up on the offer!

Best,
Johannes

Thanks a lot for the feedback, glad that I could help!
Best,
Johannes

Hello,

What is shown in the screenshot is not the KRL output, but the string representation in Grasshopper.
So just like when you plug a point object into a panel, it says {0.1;0.5;16} or so. Within the data object, there is more data - like the speed - than is shown in the panel.
When you look into the generated KRL file and search for "$VEL.CP" you will find numerous speed changes.
But why would you expect a speed change at every line? In your GH script you are providing ca.11000 planes and ca. 200 speed values, one per data tree it seems. Some speed values are identical, in which case they are not output.

Best,
Johannes

Hello,

Regarding the planes in the Analysis component, there is an ID output for every position and if it's an integer (10) then it's a programmed movement and if it's a float (10.43) it's interpolated. Maybe that could help a bit.

For the kinematically linked base, I guess that you could simulate that by transforming the positions according to the other robot's movements, though, of course, that would mess up the KRL code as the positions would be in the global coordinate system and not in the other robot's base. So I think that would require two steps, one for code generation and the following one for simulation, with the appropriate transformations.

We are currently in the process of a full rebuild of KUKA|prc, and this feedback is very important to me to decide how to lay out the software architecture. But within the context of the current version of KUKA|prc, unfortunately I don't think that it's feasible for me to integrate the linked base any time soon, especially as we don't have a RoboTeam setup ourselves...

Best,
Johannes

Hello Alex,

You can right-click the Core component to set the base dynamically.
It's definitely possible to mock something like this up, however you might have problems with the normalized simulation slider. Because when you change the base, the toolpath changes and through that the time changes.
You may want to provide a single movement out of the toolpath, or have KUKA|prc generate all movements for one robot and then generate the corresponding movements for the other robot. That might also work fine via the Analysis component.

Regarding that becoming a feature: The annoying part is the communication between two components in Grasshopper. Of course it is possible in the "background" (as it is already doing), but the more such features there are, the less transparent the dataflows become. At least in my opinion.

But I'm very open to suggestions, how that could be implemented!
Best,
Johannes

Hello,

I would recommend that example to get started, and then you could expand it with the second degree of freedom of the DKP: https://forum.robotsinarchitecture.org/index.php/topic,822.0.html
If you provide me with proof of your member access (e.g. sending me an email from your university/company email address) I can unlock the member section for you.

Best,
Johannes

Hello,

You need a membership at the Association for Robots in Architecture (or a commercial license of KUKA|prc), having a license of Rhino is not enough. I am not aware of any specific DKP400 tutorial, so it would help to know what you would like to achieve.

Best,
Johannes

Hello,

Congratulations on your first steps with the robot! Regarding the DKP, in KUKA|prc it is implemented that it basically rotates your base (with an optional offset, if the center of the base is not in the center of the DKP).
So, you program your path normally and then add the rotation, usually to improve reachability. There is an automatic algorithm for it in KUKA|prc, but it is rather basic, so for more complex projects, you will probably define your own strategy to set the external axis value. You can show the inputs for external axes on any movement component by right-clicking it and selecting the relevant options - assuming you have got access to the member version through your university, as external axes are not supported in the free community version.

Best,
Johannes

Hello David,
You can do that with C# scripting, the component itself currently does not support it.
Attached is a related example. You see how you can get the external axis object, its rootpln property should be what you are looking for. Just be aware that the plane is not a Rhino.Geometry.Plane but a KUKAprcCore.Geometry.Plane. KUKAprcGH.PRC_GH_Methods has got a method to turn your Rhino/GH plane into a KUKA|prc plane.
Best,
Johannes

Hello Alex,

It's still weird why that would cause an error message, but I'm happy that it got resolved!

Regarding the PTP, it just avoids a lot of problems, because you cannot set the posture of the robot via a LIN movement. So in the settings via the Initial Posture that needs to be actively set. You can avoid it by manually setting a PTP position. But going from the start position to the first position in a straight line usually leads to problems with singularities etc.

Best,
Johannes

Hello Alex,

For one robot, you have the "Hardcode Tool and Base" option (in Advance/Code) enabled, could you try disabling it?

Thanks,
Johannes

Hello,
The first step is to get the root point of your turntable. Currently, it is set to 1500,0,0 (via right-clicking the turntable component). I guess that is not right.
Then when you calibrate the Offset Base, you will get values that are in relation to your positioner. So if the base origin is 10cm above the positioner, you will get something like 0,0,100 for XYZ.
Your current values seem a bit strange, because they have got a 2m offset in X and the other values quite low. Are the robot and the positioner more or less on a shared plane in Z?
In any case, unless you are working with a HUGE positioner, a base with 2000mm distance from the root point of the positioner is not really feasible, the values will be much lower.
Hope that helps with troubleshooting!
Best,
Johannes

By default, KUKA|prc generates a new file when the input changes. You can right-click the KUKA|prc Core component and enable the option to expose the file name. You now get an extra input for the file name. This could now include the current date or for example an incrementing number.
Just be aware that the file name is also used for the internal project name, so don't use any empty space, special characters or a number at the start.

So now you change the start position in Grasshopper and get a new file to run on the robot.
Is that what you are looking for?

Best,
Johannes

Sorry, it's still not clear to me what you want. Do you only want to change the starting position of the toolpath or the entire toolpath?
Either is easy to do in Grasshopper/KUKA|prc, the question is how to get it to the robot. Are you using mxAutomation? Or is it OK for you to manually copy a file to the robot?

Best,
Johannes