Messages

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

Hello,

With interpolation turned off you will get the rough polyline between frames, otherwise (for motions other than LIN, of course) you will get the actual, smooth path.

Best,
Johannes

Hello,

The default behavior of the speed setting is that the initial speed is used until it is overridden by a specific speed setting. So if you don't set the speed of the movement component the offset speed will continue to be used - see the screenshot below. KUKA|prc is a generic interface so it does not differentiate by default between cutting paths, traversal paths etc. as people also use it for other applications than milling.

Doing three speeds is definitely not a problem, but you would need to make your own code, e.g. as a cluster. If you have access to the member version you can extract the plane from e.g. a LIN movement, with the Community version you would need to set it up at the "plane-level" before you turn it into a movement component. Afterwards you simply offset the first/last plane, set the according speeds and weave it back together in the right order.

Let me know if you run into any issues here, then I can provide you with an example!
Best,
Johannes

That is a rather crazy toolpath! You can optimize it by changing the position of the orientation point, see attached.
It's very important to consider though that the robot spline is NOT a NURBS curve and that the actual spline might differ. The advantage of robot splines is that you can create a freeform curve with few control points.
Also I would strongly recommend to enable the motion interpolation in the settings as it will make the simulation much more accurate!
Best,
Johannes

Hello,
That sounds like a date tree mismatch. I can only comment on the "Transform CMD" component, which accepts a list of commands and a list of transformations. You either need to provide a single transformation that is then applied to all commands, or the same number of both transformations and commands, so that every command is transformed individually.
Best,
Johannes