Looking for smoother hotwire cutting definition

[bridgewater studio]

I'm looking for help getting smoother foam cuts to see if there's a better programming solution. We're running a KR60L30-3-KS on a KRC2, running KSS 5.4.14.

I've uploaded 3dm and gh files for 3 definitions for rotating stock for hotwire cutting that Johannes had helped us out with earlier. I've added several modifications to smooth out and trim away excess movements, make the feed-in and feed-out more predictable/controllable, and better control our tool. However, this definition relies on the LIN MOVE component. I would like help in figuring out how to using the CIR MOVE component or the DIVIDE CURVE component. I haven't had any success making either one work with the curves I have in the 3dm file.

My roadblock for CIR MOVE command is that I can't figure out how to organize the points into plane triplets for input to the CIR MOVE component. (Also, as noted in the definition I've attached, I'm getting an extra unwanted segment when I run the EXPLODE component on the curves. Not sure how to even deal with that or whether EXPLODE is the best approach.)

My roadblock for the DIVIDE CURVE component is that I can't figure how to set up the GUIDE curve and ORIENT point or curve to get a valid solution.

Right now the COLUMN SECTION definition runs correctly. The drawback is that with so many tiny LIN MOVE commands (5000 in this example), we get a lot of striations in the foam. We have to increase the heat more than we'd like to smooth these out. Less points in the file doesn't get rid of the lines, it just spaces them out. Also, this is a rather inelegant solution, whereas DIVIDE CURVE seems to do more of the heavy lifting under the hood that is explicitly defined using the definition with LIN MOVE. Further, it just seems that since I have curves of multiple different arcs connected together, the CIR MOVE component should be the better choice for getting smoother cuts.

What do you think?

Thanks

[Johannes @ Robots in Architecture]

Hello,

The immediate approach for this would probably be to look into the interpolation settings first. By default it's interpolating by distance (C_DIS) and through $APO.CDIS you can set the distance when the robot starts to interpolate. At most it's at half the distance between the two positions. For wirecutting it might also make sense to set the interpolation to C_VEL with a focus on constant velocity. Change the interpolation by right-clicking the movement component.
You can set interpolation values through PRC, but I would rather recommend to set them on the control panel, so that you can write down the current value.

The KUKA Expert Programming manual and the System Variable documentation is useful for such things, you can find it via Google.

If you want to use CIR movements, here is a quick approach that might work. Note that I first converted to curve in Rhino to a series of arcs. I didn't immediately find a way to do that in GH, but I'm sure there's a plugin or script for it.

Best,
Johannes

[bridgewater studio]

Hi Johannes,

Thanks for that. I've tried inputting those lists into a CIR MOVE component, but still don't see clearly how to make it work. I'm sorry to keep asking for help, it's just not at all clear to me the logic of PRC and how to make things work until I have a very clear, explicit working example to see.

I've uploaded what I tried to add to your file to make it work, but don't know how to identify what the solution is. Would you mind helping again?

Thanks,
John

[Johannes @ Robots in Architecture]

Hello,

I have edited one of the example files to use circular movements. I'm not a huge fan, but it works.
Note that you still need to worry about interpolation when transitioning from one CIRC to the next.
Also, I have manually baked the curve and used Convert/To Arc to convert it, and then re-referenced it. If you want to do this natively in Grasshopper, Rhino.Geometry.Curve.ToArcsAndLines() was added in 2017 (https://discourse.mcneel.com/t/wish-convert-curve-to-arcs-polylines/40152/4) and should be part of Rhino 6. I did not want to create a definition that only works in RH6, though.

Best,
Johannes

[bridgewater studio]

Thanks for this.

Just a note from your comment above: C_DIS actually gives me cleaner, less ragged cuts than C_VEL. I really don't know why, but I'm sticking with C_DIS for now.

[Johannes @ Robots in Architecture]

Hello,

You can parametrize them both, I believe it's $APO.CDIS (in mm) for C_DIS and (now I'm guessing) $APO.CVEL (in %?) for C_VEL.
I usually set those variables through the KCP/smartPad, but you can also do it through PRC.

Best,
Johannes