Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - bridgewater studio

Pages: [1]
Support / Don't understand the lead-in/lead-out
« on: April 30, 2018, 09:20:00 PM »
Hi Johannes,

I've attached the files for a very simple hotwire cut that I want to do to square up the top of the part. PRC is throwing the robot way out off target in an unexpected way that I can't figure out how to stop. Can you see what I'm missing?


Support / Looking for smoother hotwire cutting definition
« on: April 26, 2018, 03:50:31 PM »
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?


Support / Unwanted TCP motion at beginning and end of toolpath
« on: April 24, 2018, 08:56:07 PM »
The files I've uploaded show a straight line toolpath for a hotwire cut. You can see at the beginning and end PRC wants to add an 360 rotation around tool axis, which I very much don't want.

I've set up the BASE curve for my toolpath, the GUIDE curve I've set to control Z axis of my TCP (my tool axis is Z in grasshopper for reasons not important here), and the ORIENT point to control the -X axis orientation of the TCP.

Basically, I arranged BASE, GUIDE, and ORIENT to align with the TCP orientation of my tool. I've also set up a base where I will cut the foam wheel, along with the tool and both of their data.

In my set up on my computer, the robot follows the path exactly as I want it to. PRC is just adding these tool spins at the beginning and end and I'd like it to stop as well as understand why it's doing it to begin with.

Thanks for any help.

Support / Problem calibrating turntable root point
« on: April 17, 2018, 05:52:47 PM »
We've gotten to the point where we're trying to use the rotary table with CAM software, but there's a problem calibrating the root point. I've repeatedly followed these directions, but keep getting a wrong calibration. I've attached a picture of the saved settings.

Correct me if I'm wrong with your directions:

1) Locate table where it is to be used and level it. (I've also mounted a steel point in a small spindle and calibrated a TCP for that to use. I used that steel point TCP to find the rotary center of the table by rotating the table top with the steel point touching it near the center and jogging the tip until I found the center of the table. From there I repositioned the table top to be square with the base. From my homemade table top center point, I jogged the tool tip 395 mm to one edge of the table (the table measures 400mm from the center to closest edge) to make the mark for the Tool Reference Point. I numerically entered this data as (395, 0, 0, 0, 0, 0) (X, Y, Z, A, B, C) as a Tool in the Kuka.}

2) Unmaster External Axis 1 and remaster using Dial mode. (I'm not sure if I need to unmaster every time I move the table, but I have been doing that.)

3) Measure the External Kinematic Root Point using the Tool Reference Point created above using the 4 point method with the calibrated tool already mounted.

Can anyone see anything here that I did incorrectly? I ask because I consistently get a C value of +/- 179°. Why does the robot keep calculating the table to be upside down?

The software we're using to program the robot with the rotary is Kuka|PRC. If I enter these values or any C value like this into the generic turntable component, it flips the table relative to the robot, which won't work. I don't understand what could be causing this C value.

If anyone have any ideas or other sources to find answers, please let me know.


Pages: [1]