Tool Path Axis for Hot Wire

[singline]

Hi,

I'm hoping someone can help me - I'm attempting to do circular hot wire cutting. I have everything working apart from that I require the x-axis to always be perpendicular to the cut lines to ensure my tool doesn't pass through the styrofoam. Everything I've tried so far has shifted the Z axis.. ?

I've attached the 3dm and gh.

Thanks.

[Johannes @ Robots in Architecture]

Hello,

You can basically use any axis you want for the wire, it's just important to match the physical and virtual model. The Z-axis is only convenient because you can define it with the Plane Normal component, and adjust it via the Rotate Plane component.
So if you want to use the X-axis, you have to define your tool e.g. with the Construct Plane component and set X along the rulings of your cut surface. By changing the direction of Y, you adjust from where the robot is holding the tool.

Hope that helps!
Best,
Johannes

[singline]

I resorted to rotating each of the 10 planes individually so that x axis is directed outwards - but the robot still goes through the model ... when i use the rotated planes the robots tool still doesn't go to the x axis..

[singline]

I believe I have found the core issue  - the origin of the movement was not placed correctly for the tool, which then needed another adjustment.

Johannes, thank you very much for the prompt and helpful response, if we ever have the chance to meet I owe you a few beers.

[Johannes @ Robots in Architecture]

Awesome - you figured it out yourself, but if I make it to Tasmania again I'll gladly take you up on the offer!
All the best & don't hesitate to get in touch if you run into any other issues!
Johannes

[singline]

Its seems to be going ok, but I just can't figure out why the KUKA does what it does when I attempt edit my path.. If I try to reverse the order it gives me an error on axis 6 and also if I repeat the first list item at the end to ensure a full circle I have the same issue.

It runs fine up until I'm adding in the new list item. It runs around but doesn't complete a full rotation of the styrofoam. And I wish to reverse the motion due to tension on a couple cables..  ???

[Johannes @ Robots in Architecture]

Hello,

The problem is that you are turning more than 360 degrees. While A6 can got from ca. -355 to 355, you "lose" some degrees depending on where you start.
So in the attached, edited file I added a PTP movement where I directly defined the posture with status and turn. Then I shifted the start movement so that we can fit it into the axis range.
You could also set A6 to rotate infinitely (right-click on the option for the simulation, edit the machine data for the physical robot), however then you would need e.g. a slip ring for the power supply of the hot wire.

Best,
Johannes

[singline]

Thanks for the prompt reply Johannes. I understand that - but in my head i had it running correctly in one direction with no full twist of A6 - when I reversed the command line why does it then have to 'untwist', wouldn't it run the exact same points, just in the reverse motion? At the end of the path, when the kuka returned to the end position, it untwists A6 which wasn't twisted in the non-reversed version? Does that make sense?

[Johannes @ Robots in Architecture]

Hello,
If you define all positions clearly with PTP movements including status and turn then the movement will be largely the same in both directions.
LIN movements depend on a previous posture and will interpolate linearly from there on, so there can be differences.
In a smaller scale there will also be differences when the robot is blending movements in a different direction.

Two more things: In my file from before I set the position accurately with status and turn - meaning that if you move the position that may not be a viable solution anymore. Also, I've noticed that your custom tool has got a very high resolution. I would recommend reducing the complexity of the mesh with the Rhino command ReduceMesh. That will speed up your viewport, especially if you do collision checking.

Best,
Johannes

[singline]

Hi Guys,

I'm having a hell of a time generating paths from a brep form to subract from a syrofoam block. Have to ensure the kuka isn't attempting to pass through the material and performing sweeping motions in the correct direction to basically subtract chunks of styrofoam to be left with the original brep shape. I've attached an image i am hoping communicates what I'm trying to produce.

I've been trying to set it up parametrically so i can put in different forms and cut without having to adjust the GH too much.

Any and all help would be greatly appreciated..

[Johannes @ Robots in Architecture]

Hello,

The main issue is that you have quite many degrees of freedom that each have got a large effect on reachability. Basically you can go in any direction if it's a planar surface, or in two direction if it's a non-planar ruled surface. Then you can also rotate around the tool axis.
I would definitely approach each side separately for now, possibly implementing toggles to switch direction etc.
What you could also look into is using Galapagos - you assign your parameters and as the fitness function you use the Analysis component - to which you as member have got access - and make a Mass Addition for Collision and Reachability. Then tell Galapagos to try to minimize the values.

Best,
Johannes

[singline]

I've put this together. One issue is that with all the cuts currently being merged on axis is rotating too much going between the starts of new cut lines.

I'm thinking if I put in a PTP move from the end of one to the start of another it will stop some of the interpolation?

Or is there a way I can insert a line to unwind the axis before moving onto the next stage in the code. Currently it cuts all sides, then top slice and bottom. Its currently hitting the red line when it moves from sides to the top.

Maybe I can send it back to the start to unravel and then re-enter the process?

[Johannes @ Robots in Architecture]

Hello,

I see from the other post that you've found the right approach yourself, but just for anyone else who may be looking: Set the TURN value of a PTP movement to exactly define the posture, thus "unwinding" the robot. Through the  STATUS/TURN input, you can now enter "010 100010" to set the STATUS to "010" and the TURN to "100010". Refer to e.g. page 63 of the KUKA Expert Programming Manual. TURN input is optional, use it e.g. to "unwind" the robot between complex movements. If you open an existing definition, the input will still say "STATUS", but the optional TURN functionality should work.

Best,
Johannes

[singline]

yep - all sorted. thank johannes.