kuka PRC for parametric Laser Cladding

[sialam]

Hello everyone.
My name is Syed and I am a student at University of Alberta, I am working in the automation of a laser cladding facility along with another fellow in the university. As for our setup we have a Laserline 9kw laser,  a Thermach powder feeder, a siemens PLC, a Kuka kr16 and a dkp400, in terms of software we decided to use Kuka prc as we believe it truly potentializes the  flexibility and ease of programming for multiple and complex geometries of our worn out parts that we are working in repairing.

So our workflow involves a 3D scanner that we use to create our model of the worn out part and then we use the 3D model in rhino in order to create the toolpath adding polylines. Once we do this, the laser and powders are controlled with the I/Os of the Beckhoff module and the siemens PLC.

Any how we are now struggling when we try to use our DKP and maintaining the tool as statically as possible and let the dkp do the most of the work in terms of moving. We are aiming at rebuilding a pipe as a test but for now we are using a plate.

My specific question is what type of values does the external axis accepts, angles? vectors? I tried to find this on the documentation but probably I missed it and just can't figure out and understand how should I input the values and also understand what I am inputting.

Finally I want to thank Karl and Johannes, your work is amazing and we are using most of the resources to put this together. My colleague Daniel reached Karl I believe but we didn't wanted to share anything until we had something much more useful or specific. So now We are showing our work here in order to share, hoping to get a bit of help as well as show the capabilities of in engineering processes. We will be featured in WELD magazine soon talking about our setup and the use of parametric programming and we are very happy to share this with you and hope to get more thing and collaborations in the future.

Thanks in advance  for everything and hope you find this interesting.

[Johannes @ Robots in Architecture]

Hello Syed,

The external axis uses simple degrees as the input value, in the case of the DKP you have got one axis that sets the tilt and one that sets the rotation. Which one is E1 and which one is E2 depends on your particular setup and can be changed in the simulation (to fit your physical setup!) by right-clicking the DKP 400 component.
You can of course calculate the value so that e.g. the tool stays as vertical as possible, that code may be useful as a pointer, through it only uses one rotational axis:
https://forum.robotsinarchitecture.org/index.php/topic,822.0.html
Give it a try and if you get stuck somewhere, let me know - and clearly define what movement you want to delegate to the DKP, "most work" is too vague, do you want to keep the tool vertical? Keep the robot very close for stability?

Best,
Johannes

[sialam]

Hi Johannes
Thanks so much for the reply, sorry if my description is not accurate.

What I mean is I want the e1 to maintain a 90 degree angle always and then the e2 to continuously rotate if necessary according to the toolpath, i.e. if I put a pipe in our chuck, I want e2 to rotate continuously and the tool maintain its position and just move a bit further to the end of the piece after every iteration.

I just downloaded the code that you pointed to me I will study the case and try again and let you know how are we doing. Thanks for the assistance.

We are working on a demo incorporating the Inconel powders and the laser so we might have a video of this to share with all of you guys. Also the Weld magazine should be out soon, I'll post the link for anyone to have a look at what we wrote, feedbacks, comments and anything is very well appreciated.

Johannes, Thanks again and I'll be in touch with you.

Syed

[Johannes @ Robots in Architecture]

Hello Syed,

I think the linked code should work well for that, please give it a try and if it doesn't work as expected let me know and I'll look at it in detail, OK?
And it would be great if you could post a link to the article you mentioned once it's online!

Best,
Johannes

[sialam]

Hi Johannes
I'm still working on the code you sent me trying to understand each part of it, I'm not sure if I understand everything correctly but also I am configuring the tool, the positioner and everything according to our setup.

I attached our old code which has almost everything already configured according to the post you shared here https://forum.robotsinarchitecture.org/index.php/topic,115.0.html , anyway we cant make that one work. I also attached a draft of how we want the process to run. Which is basically leave the positioner first axis always at 90 degrees, then rotate continuously rotate the second axis and let the kuka robot almost all the time at 90 degrees form the surface of the working piece.

Taking a look at the code you sent me I believe that I might have to change the orientation planes according to the object, process direction and robot tool, right? anyway I will dig more into it .

We are completely new to rhino and Grasshopper, so that is why we are taking sometime in not just making it work but actually understanding the workflow, sorry if that is a but annoying. For sure we Will share with you guys the link of the article.

Kind regards

Syed

[sialam]

Hi Johannes

I've been working in the code and got better results but my toolpath seems to be wrong aligned, I assume that the transformation done ( rotate, orient, rotate) in the code has to be coherent to my turn table and process directions right? how do I evaluate this. I'm trying to understand the whole set of operations.

I put a green rectangle on the part of the code I am talking about, They yellow rectangles represent the code I changed in order to get what seems a better orientation of my whole process. (turntable, piece).

I hope this is a clear explanation.


If not please let me know.

Thanks

Syed

[Johannes @ Robots in Architecture]

Hello Syed,

That was a bit tricky, the challenge is that when you calculate an angle, you get some value in degrees, let's say 355 degrees and 5 degrees. When the turntable moves from 355 to 5 it will go 350 degrees in negative direction. What you want it to do is to move from 355 to 365, i.e. just 10 degrees.
I made a quick C# script for that, but treat it carefully as I'm pretty sure that there are border-case where it does not work. I only tested that with your current setup.
The rest was pretty straightforward. Just note that there are some positions where the robot runs into A5 limits. Probably some normals of faces are a bit off in the 3D scan, smoothing the scan might help for that.
Also, I would strongly suggest to use ReduceMesh to reduce the complexity of mesh geometry you import into Grasshopper.

Best,
Johannes

[sialam]

Hi Johannes

Sorry for my late reply, Friday we needed to do some stuff and I was not able to work on the programming part of the project. Any how here I am and  I will download the file, scan another part and test it.

I believe we can also reduce the mesh when scanning, I will look at our options in order to have a native file from the 3D scanner, any how I will also test the ReduceMesh in Rhino.

I'll start to work in the scans today and get to you, I appreciate your help.

I'll keep you posted.

Kind Regards
Syed

[sialam]

Hi Johannes

These past days have been very intense, we faced an early shutdown of our lab due to health regulations during the pandemic. Hence we have to prepare a few things and got a bit disconnected from the project itself to solve other issues.

Anyway, we have been working with the 3D scanning pre-processing, location of the coordinate system of the scanned object. Reduction of the Stl file, recognition of the Area of Interest ( for cladding purposes). Tool Calibration to achieve repeatability and accuracy with any nozzle and different powder feeder speeds. ( please take a look at attached image).

In the mean time I wanted to thank you Johannes, Karl and every member of the forum. Every sentence of information is truly valuable. We are taking a week break to rest but hopefully we will be able to catch up  soon continuing our discussion and development of this exciting applications.

In the meantime I hope everyone stays safe and sound with their most beloved ones.

See you soon guys!

[Johannes @ Robots in Architecture]

Hello Syed,

That sounds all super interesting, enjoy the break and then all the best with your project in a hopefully less complicated year 2021!

Best,
Johannes

[sialam]

Hi Johannes

I hope you are safe and sound. Starting great the new year!

I saw your video with Karl Singline, it was very interesting thanks for dedicating time for us.
We are eager to show our project and highlight kuka prc advantages after finishing it. We are very close to that stage and during the "break" we where working on three different patterns for our tests. Our purpose is to create a methodology from the ground up in order to clad plates, pipes, and 3D amorphous shapes.

As it was expected we are starting from the easiest a plate. then moving to the bit more difficult ones which are the different possible cladding patterns. In the attached image I hope I explained myself on the differences and what we are aiming to use as parameters to control the patterns.

I am also attaching the files for helix and patch patterns, I was wondering what are your thoughts? do you believe the way we are tackling is correct? the program is the same we just are creating the curves and helixes. Daniel, my colleague is working on creating a general case for the helix in which we can modify the length and pitch with grasshopper.

The one we have been struggling is the one in which we want to clad and arc of lets say 30 degrees skip 60 degrees and then another arc of any given length. We tried to join the curves but have no luck. We also though about creating different layers and on each layer have a drawing of the curve then sent them to the robot, but this is an approach that we will try soon.

Just wondering if you believe that our way of simulating the pipe, creating the entities and doing our programming is a good choice in terms of how to handle the problems.

Finally, I'm happy to announce you that we are back in the lad and we will soon start the tests of all the programming done by Daniel, we will keep you posted.

Have a nice day.
Syed

[Johannes @ Robots in Architecture]

Hello Syed,

I took a look at the file, beyond the robot sitting on the turntable I don't see any particular problems.
Just take care not to calibrate the base as a normal base, but as an offset base!
Regarding the question with the arcs, could you clarify that a bit? I think I don't know enough about the process to understand how the segmented arcs would fit in.

Best,
Johannes

[sialam]

Yes you are right, we need to recalibrate the base. That was an error in our side  :-\  .

Regarding the arcs, is a kind of simple approach in which if we only want to clad 30 degrees of a circle then skip the next 60 and start the cladding again for another 30 degrees or so. This being done in a pipe. We had problems in selecting multiple curves and then creating the path. I'll ask Daniel to put together a better explanation but  Let me know if I explained my self better on how we pursue the pipe cladding for the laser.

Also, Johannes I was wondering if there is any possibility of us having a meeting whenever possible for you, Daniel is the postdoc working in the programming, yesterday he watched your video and pointed out the part in which it was shown the use of a creaform 3d scan and the mxAutomation module to carve a pumpkin. It it of great interest for us to learn more about this approach.

Ours is different because we:

• Scan the part
• save the stl file
• preprocess the file ( Cleaning it)
• import the file to rhino
• simplify the geometry using rhino tools ( as you suggested)
• create the toolpath with the program in grasshopper 
• dry run
• execution

As it is now, it works for us and we are doing part location manually with a few cues for us to orient correctly the part. We have done dry runs before our suspension of the lab for the pandemic protocols.

But Daniel pointed out that what you have achieved is the "ultimate" application. Nevertheless, we haven't reach that point because we do not have any experience with mxAutomation and we are pretty new with rhino and grasshopper, but very very eager to continue our learning.

We find out this 2 posts from you and Karl pointing out some further and very useful information regarding this topic.
https://forum.robotsinarchitecture.org/index.php/topic,1067.msg2995.html#msg2995
https://forum.robotsinarchitecture.org/index.php/topic,952.msg2618.html#msg2618

In the second post Karl mentions a possible beginners tutorial, is there any possibility that this will happen?

I hope we can engage a bit more and possibly have a zoom meeting. We would like to discuss how can we potentialize our collaboration and  learn more about the software and the possibilities we have for our automated cell. We believe we need to learn lots but we want to make the best use of our hardware, and your software.

Please let me know if there is something we could do.

Thanks Johannes

[Johannes @ Robots in Architecture]

Hello Syed,

Sure, let's have a call soon, send me an eMail and we can arrange a time!

Best,
Johannes

[sialam]

Hi Johannes it was great to have a more personal word with you.  Daniel and myself are both very happy and we worked on what we talked, we where able to locate and only select the part of the surface of the pipeline we want to clad. We created points, lines, then used the Drape command, then meshBoleanSplit to only work with what we needed to. We also reduced the mesh to compare ( the cladding surface I mean).

Finally the path is generated but some how there seems to be a few issues, the first one is that the tool doesn't seem to be maintained at the top part of the positioner to maintain it at 90 degrees with our cladding surface. The other issue is on the simulation, if you look closely to the Scan of the part and the Cladding surface they do not match in the simulation but they do on the non simulation models.

Do you think this is due to something we did wrong or do we have to find a way to always sync the planes to be normal to the tool? By the way at this moment the tool is always the same we changed the scanned par to a cylinder that we want to use.

I also attached the program files in case you want to take a more detailed look.

We believe we are pretty close but well... still some issues hehe