Messages

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.

Thanks for clearing that up for me! This is what I was actually trying to do without really knowing how to get to this solution.

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?

Thanks,
John

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

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

SOLVED:

Figured out my own problem. In the KukaPRC settings, in the Adanced tab, in the Start-/ENDPOSITION panel, under initial posture, I changed the default 110 to "As Start" in the dropdown.

Everything worked exactly as expected after that.

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.

Thanks for all your help with this Johannes.

So, it turns out I had all the right elements, they just needed to be blended just so.

I mastered the turntable and found the root point. I zeroed the B and C values since my table was leveled. I decided to keep the A value, but I could probably chuck that as well.

(No matter how many times I tried, I always get a C value of near +/- 180; if I changed the C value of ET1_TA1KR to 180, that wound up causing other weird problems, I think; this is such a weird, vexing problem; that it turns out not to be a problem, at least right now, just gives me anxiety, because it just seems like a problem waiting to drive me insane in the future.)

As it happens, I had multiple TCPs for the hotwire tool I had created in two different files that I was working with. For the purposes of communicating with you I had used the files above that you had helped us with. However, I had been working with another file where I had updated the TCP for that tool but had yet to update the files I posted here with it. Another person came in to help us with this and he just immediately looked for those values on the robot to double check and sure enough that was the final puzzle piece.

Also, there might have been something to do with having changed so many of the configuration settings and then resetting them that the computer needed to be rebooted. Once that happened, it just seemed like everything started working better. (It had stopped recognizing our usb drive for instance. Once rebooted it found it again.)

Anyway, for the moment we're up and running and we are now able to run the program using a rotary table in the robot and cut foam with the program running to completion with no problems. I'm still not completely confidant that if I move the table and do this all over again that I will be able to run everything correctly. But at this point, I at least have a better process by which to instantiate everything.

Thanks for your patience and efforts! Have a great conference.

John

I didn't. I'll try it. Do you think I would need to recalibrate my tools' TCPs as well? I wouldn't guess I'd need to, but so far none of my guessing on any of this has been very good.

As for physical location, see pic. This looks like the same problem I've been having all along. You can see that the X/Y/Zs of the tool relative to the rotary table are all negative even though it is currently occupying a very clearly +Z location, at the very least.

Actually, I just tried setting C to 180 degrees for ET1_TA1KR in Axis Configurator and then recalibrated the root point. I'm now getting close to 0 for B and C, which is good!

However, when I try to run my test.src out of prc I'm now getting an error for Work Envelope Exceeded. Is there something else I need to set in prc to accommodate this change? Or is it something else altogether?

Thanks

So, when I ran the offset with the root point of the table as the origin, it initially had the effect of causing the robot to execute the prc code correctly with the exception of the table rotation.

I then did in fact open Axis Configurator to change AXIS_DIR to -1, which didn't change the positive rotation direction of the table at all, but instead screwed up how the robot executed the code. I'm not sure how to describe what it was doing, but it was even close to what the prc simulation was doing.

I really feel like this should not be this difficult. Measuring the root point is so simple to do, how can this forever be causing so many problems? This is why I'm worried that the wiring or configuration is wrong, but I really don't have any procedure for tracking down the error. No matter how I do it, the robot thinks the table is upside down. I can't find any other variable to modify. And now, after making changes in all these other regards, the robot now thinks that the starting position is about 3 feet higher than where prc is indicating it is.

I would happily read the manual, if someone would kindly show me what page in which manual clearly states how to resolve this.

Alright, I figured out that the problem was in improper offset calculation. I had previously been thinking that offset were for working on parts on different parts of the base. Here, though, the offset is simply informing the robot as to which side of the rotary is up... I think. I used the center point of the table (physically scratched into the table using a steel point) as the origin of the offset. Then setting +X in the direction of positive/outward from Robot Root and +Y perpendicular and to the left of that. Now when I run the as expected with the robot making the correct approach and the tool oriented correctly from what I can see. However...

The final fly in the ointment is that our table is now rotating in the opposite direction of the PRC simulation and it's not clear why.

Thoughts?

Thanks

Actually, correction to previous post: I stated the orientation of the X/Y/Z incorrectly. It's actually more simply like a -90 degree rotation away from positive X. So X is along -Y, Y is along +X, and +Z is +Z. But that's with A/B/C uncorrected to 0s. When A/B/C are "corrected" to 0s, you'd see values more like the picture above.

From the turntable manufacturer, we were directed to simply set the A, B, C values to zero for the Root Point using the Numeric Input option. His reasoning was that since the table was leveled, which he also directed us to do, that we were simply rectifying the machine data with the actual table.

I just want to state for the record that his advice was fundamentally unsatisfying. I really want to know why the machine made the incorrect calculation to begin with. I get worried that this is the result of crossed wires in the data cable. It should be noted that this same manufacturer sent us a power cable with 4 of the wires in reversed positions; I had to track this problem down myself, open the cable to expose the leads, reverse the positions of the brake power lines and the mains power lines, and reassemble. It all now works. But that isn't to say that the data cable was wired correctly, which I haven't yet checked and don't know how to check.

All that said, our table and the simulation are rotating in the same direction - initially. I have a gh definition that you had made for one my colleagues here and I modified it so that the generic turntable component matches our turntable location as well as to incorporate some changes I had made to our hotwire tool. With another adjustment to the opoint of the Orient Plane component to get the tool to align correctly, I got CORE to solve and generate code that does run in our robot.

However... the robot still thinks it's upside down relative to the table, even though I zeroed A/B/C as seen in the picture: X/Y/Z are all negative. So when I run the program the robot wants to push the TCP to the positive position relative to the table top, which in this case would be underneath the table top. If I then change the C value in the robot back to 180, the program will execute again, but when I gets to about line 14, I think, it links with the table and the TCP and the table start synchronously rotating counter-clockwise, opposite of programmed rotation. Eventually, the robot hits an axis limit and halts movement.

I fully realize that you're not responsible for our hardware problems, but I'm hoping you might have some insight as to what is causing this or maybe direct us to information somewhere, somehow that will reveal what we are fundamentally missing.

As to our calibration method, I've marked the reference point on the table as (395,0,0,0,0,0) [X,Y,Z,A,B,C] per the manufacturers specification, which is also set in the Axis Configurator in the variable $ET1_PINFL. When I calibrate the table, I first unmaster the table, then master in Dial mode with the table top more or less square to the base and in the location that I want to use it for this project. I have created a tool for the reference point using the same input as the Axis Configurator. I used a previously calibrated TCP with a metal point mounted as the measure tool. I followed through with the procedure lined out inside the Root Point measure tool inside Setup.

The way all of this is setup, I would expect that the positive X direction in the Rotary base for the external kinematic should point from the center of the table toward the reference and the positive Y perpendicular to the left of that vector. In fact, after calibration, using the newly calibrated Rotary1 base coordinate system, the positive X lies in the direction of what I thought should be negative Y and positive lies in the direction of what I though should have been negative X. And as you might guess, positive Z is down into the table. No matter what I do, it keeps thinking the table is upside down.

This is why I thinking we've got crossed wires somewhere, or a secret button wasn't set correctly inside some as yet unseen configurator that no one wants to tell me about.

We just can't make any progress at all because of this problem and I just don't know what else to do.

I've attached the rhino and gh files to see our setup. This will run in our robot, just not like what you see in the simulation.

I've been simply setting C to 0 in the turntable tool in PRC just to make it work. I'm worried that this will cause everything to flip once I run the program at the robot.

And yes, whatever tool I set, if associate with the external kinematic system, then when I jog the table the robot TCP will stay fixed to the table and jog with it.