Messages

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

Hello,

Sometimes it needs a re-compute in Grasshopper, do that and then move the slider.
You can change the root point of the robot via the Custom Robot component. Plug it in as a reference and change the root point.
What is not supported is that when one robot moves, the second robot is constrained to it, i.e. it follows its movement.

Best,
Johannes

Hello,

That's not a problem, should be done in just a few lines of code in the sps.sub - the program that runs cyclically in the background. Something like:

Code Select Expand

IF $VEL_ACT > 0.0 THEN
$OUT[1] = TRUE
ELSE
$OUT[1] = FALSE
ENDIF

Of course I haven't tested it. Consider making a backup before changing important files like the sps.sub. Or run an additional SUB program if your robot supports it!

Best,
Johannes

Hello,
I quickly put something together based on the extrusion example. I wouldn't run it like that, but it should hopefully help!

Best,
Johannes

Thanks for the update!
Best,
Johannes

Hello,
What do you mean by "start milling from this point". Do you have an existing toolpath and want to start from a specific location? Like the KRL file is on the robot and you send some command via Ethernet to the robot, so that it does not start from the beginning from from e.g. line 400?
Best,
Johannes

Hello,
As you work with 3D printing I guess that you want a continuous process without stopping. In KUKA|prc you can right-click the digital output component and set it so that the robot does not stop, in KRL it turns from $OUT to $OUT_C. In addition, you could look into the TRIGGER command and use it through the Custom KRL component.

You have got a large number of outputs in the robot - they don't have to be connected to anything physical- so you could just trigger them in sequence to see where you are.

But if you can describe in a bit more detail what you want to achieve with that, I can provide you some more detailed pointers.

Best,
Johannes

Hello Henri,

That's a very interesting observation, are you sure that the KUKA|prc versions were the same? Because I occasionally finetune some the algorithms a bit for edge-cases. As any PC calculates with limited accuracy, 90 degree can sometimes become 90.0000001 degrees, you have probably observed that in Grasshopper somewhere.

For the ABC calculation those values are sometimes rounded, to get more consistent ABC values - that should be more aesthetic than functional, though it also helps when the toolpath is not wobbling around (i.e. 90.00001, 89.99999, 90.000001, so going back and forth). There are multiple ways to express the same orientation in ABC, so these small changes can also create quite drastically different numbers, though the frame will be more or less the same.

But a difference by a few degrees is very unexpected, we're usually talking about 1/100-1/1000 degrees here.
Do you have an example of the ABC values before and after? That would help a lot!

Thanks,
Johannes

That error has now been resolved in the most recent release!

Sorry, I must have missed your post. I can replicate the issue on my end, however the error is very weird considering that "DisableDpiAwarenessAttribute" is nowhere called in KUKA|prc. I will try to get in touch with McNeel regarding that.
My apologies again for the delay!

Hello,

If you have got a full license, you can use the Analysis component for that. I've attached an example for you!

Best,
Johannes

[So first back to your turntable from the initial screenshot: Is it synchronizing properly? What are its XYZABC values?]

Hello,

Sorry, where is the DKP 400 coming from now? Your screenshot showed a linear rail and a horizontal positioner.
You mention that the "simulation is not satisfactory", what do you mean by that? This can be anything from a 2mm difference to the robot being 1m away from where it should be.

I looked at your attached file and it seems fine to me. You would need to explain to me what exactly you want to achieve in order for me to be able to help you.

What I can tell you is that your tool is very high resolution which will reduce performance. I would reduce it down to like 10k vertices.

Especially when using a DKP (= 2 rotary axes) I would personally recommend defining your own positioner strategy (see e.g. attached). The automated solver settings define a vector (so entering 0/0/0 as in your file will have no effect). That being said I just looked at the solver and there might be bug in some cases. I will have to look into that whether it's related to us or Rhino.

The horizontal axis is not included by default, but we have several people using those through the custom turntable component.

It would be great if we could go through your questions in sequence and solve them one by one, rather than posting them all at the same time.

So first back to your turntable from the initial screenshot: Is it synchronizing properly? What are its XYZABC values?

Thanks,
Johannes

Hello Moh,

The first step is that the external axis needs to be properly working. So you need to make sure that the axis itself is calibrated and then set an Offset Base (fine to use all-0 fror testing). That way, when you go into base movement mode and move your external axis in that mode, the turntable will turn and the robot will move along with it, i.e. it will keep its position relative to the turntable.

Is that working for you? What are the calibration values of your rotary axis?

Best,
Johannes