Messages

1

Support / Re: mxA， The $PRO_ACT singnal of the Automatic External interface is not active

« on: May 25, 2022, 09:13:35 PM »

Hello,

Can you please make a tiny, simple test program where the error occurs on your setup and send it to me?
Then I could test it on my end and see if the same thing happens!

Thanks!
Johannes

2

Support / Re: Can you help me align the base ?

« on: May 24, 2022, 08:51:30 PM »

That very much depends on the application. For high-accuracy milling I usually calibrate the XYZ values of a long and a short tool (the higher the difference in length the higher the accuracy) and then use the vector to calculate the right ABC values.
I can send you the code, but to get you started you could also just send me the XYZ values of a short and a long tool and I will send you the ABC values back.

Best,
Johannes

3

Support / Re: WAIT INPUT

« on: May 24, 2022, 08:49:00 PM »

Awesome, thanks for the upgrade & glad that I could help!
Best,
Johannes

4

Support / Re: Can you help me align the base ?

« on: May 23, 2022, 11:05:17 PM »

Excellent, glad that it worked!
Thanks for the update!

Best,
Johannes

5

Support / Re: mxA， The $PRO_ACT singnal of the Automatic External interface is not active

« on: May 23, 2022, 11:04:36 PM »

Hello,

Hmm... That is very strange, we have definitely let mxA run for much longer than that.
Is the problem also happening with the KUKA test program?
Can you try setting your laptop's Power Options (if it's a laptop) to High Performance, so that there is less chance of any hardware going to sleep?

Best,
Johannes

6

Support / Re: Calibrating KP1-V500 with KUKA|prc

« on: May 23, 2022, 10:00:36 PM »

Hello,

Can you please send me the file and label/internalise the different options as they are on your PC?

Then I can check for differences! It also doesn't hurt to use the Recompute function, just to see if that makes a difference!

Best,
Johannes

7

Support / Re: Calibrating KP1-V500 with KUKA|prc

« on: May 20, 2022, 08:57:54 PM »

Hello Alex,

Sorry for the late reply, I'm on holiday and therefore not as quick as usual.
Reversing the rotation axis of the turntable should flip the rotation direction as well - see the attached example!
Otherwise the approach would be to look into the machine data file, but let's keep that option for later.

Best,
Johannes

8

Support / Re: WAIT INPUT

« on: May 20, 2022, 08:22:16 PM »

Hello,

Without an example file that is hard to trouble-shoot, but I guess that you used the "Merge" command to put the series of commands together?
Now movement commands have often gone through a series of operations that introduces additional data structure, while Wait commands consist of just a single component and its output.
If you put the data into a panel, it shows you the branch name on top, e.g. "{0;0}". A wait command may just have {0} and would therefore be put first.
The "Simplify" and "Flatten" options could help, either use them as a separate component or by right-clicking an input - for example by enabling "flatten" for all inputs of the Merge component.

Please note that this is a GH thing and not directly related to KUKA|prc.

Hope that helps - if not please attach a simple example to illustrate your problem!

Best,
Johannes

9

Support / Re: Calibrating KP1-V500 with KUKA|prc

« on: May 17, 2022, 06:27:39 PM »

From the XYZABC it looks like you would like the tool to more or less stay at the current position, right?
So if A moves by 8 degrees, then E1 does the negative -8 movement.
Is it possible that the real and simulated turntable turn in different directions? So instead of -8 + 8 = 0 you get 16?

Best,
Johannes

10

Support / Re: Getting rid of those ridges

« on: May 16, 2022, 08:15:11 PM »

I've only got my own experience in that C_VEL tries to keep a constant speed at the expense of accuracy. We've had success on larger-scale 3D printing where constant speed is important but a few mm difference do not matter. Unfortunately the C_VEL parameter is without units (0-100) so it's hard to quantify.
Have you tried the S-movements yet? Might be smoother for you!

Once business is rolling you could invest in KUKA.CNC, I have heard great things about its toolpaths (and terrible things about the integration process). But it's one of the most expensive tech packages.

Best,
Johannes

11

Support / Re: Getting rid of those ridges

« on: May 15, 2022, 02:21:24 PM »

You can right-click the symbol/name of each movement component and change the chosen interpolation method.

I see that ; there is even a "no interpolation" option.
The trouble is that it isn't very easy to manage because again, the option is not accessible as an input.
If it were, it would be easy, in a list of LIN movements to have a coresponding list of "Interpolation methods".
Then depending on , say, the angle between successive movements, one could chose between methods.

It would be possible to change the approximation parameters via the Custom KRL component, if needed.

As a workaround, perhaps I might try it out. It's just string formatting after all...

Regarding defaults, the controller keeps the last value, as far as I know.

I have absolutely no idea what "typical" settings are use for milling.
Since milling can involve sharp edges, I would expect these values to be quite small, but exactly "how" small is still OK in terms of robot jerkiness : that's what I'd like to know.

Also, you might give the SLIN movements a try, they can be a bit smoother. It's an option in the Code Generation settings.

I don't want smoother. I want control over where it can be smooth, and where it shouldn't.
I checked the KSS doc. on SPLINE blocks, and as always, I came out even more ignorant as before.
It's always blunt, sterile description...
Even this Chinese video does a better job of explaining : https://www.youtube.com/watch?v=yIv9Yr9ynOE
Could you point me to any well-made documentation on these types of movements ?

If I get the idea behind this option, if it is pressed, all the movement types will be converted to the new "S" type and inserted in spline blocks, is that right ?

Please don't take this the wrong way, but if you need expert access to all values, you will need to interface at the code level. Here's an example for a LIN component with basically all input. You may need to set the correct path to your libraries for it to work.

Best,
Johannes

12

Support / Re: Getting rid of those ridges

« on: May 15, 2022, 02:10:11 PM »

I notice that, even though I heve no interpolation method set in the LIN component, my LIN movements end-up having the "C-DIS" option in the .src file
Could that be a bug ?
I also notice that LIN movements for tool offsets don't have an interpolation option in the in the .src file (which makes sense).

What would make sense is that , when there is a tool offset, the interpolation method be "no interpolation" for the LAST LIN movement just before the offset.
That could solve at least the ridge problem I had on my beer bottle cap milling...

If I create a toolpath consisting of two linear movements with no interpolation and add the tool axis offset, this is what I get:

Code: [Select]

LIN {X 18.16, Y 8.094, Z 50, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0}
LIN {X 18.16, Y 8.094, Z 0, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0}
LIN {X 40.16, Y 17.019, Z 0, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0}
LIN {X 40.16, Y 17.019, Z 50, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0}
With interpolation it looks like that:

Code: [Select]

LIN {X 18.16, Y 8.094, Z 50, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0}
LIN {X 18.16, Y 8.094, Z 0, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0} C_DIS
LIN {X 40.16, Y 17.019, Z 0, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0} C_DIS
LIN {X 40.16, Y 17.019, Z 50, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0}
I'm a bit torn regarding that, but you would like me to manually get rid of the last C_DIS before it rises up?
While I see that it would help with your issues, there will also be users who do NOT want the tool to briefly stop.

Best,
Johannes

13

Support / Re: Getting rid of those ridges

« on: May 15, 2022, 02:03:19 PM »

I generated two .src files (I could never understand why they are not simply called .krl files) :
-One with KRC2-style movements
-One with "S" or "Spline" movements

First, I am surprised that there are no Spline blocks. Isn't that what actually tells the controller that the subsequent movements are spline "segments" and that they should all have curvature continuity ?
Then, I found that the "S" segment movements each require their $VEL statement, whereas the old-school movements use the last value found in the code... not that it's a big deal, but it does make the "S" file larger for no good reason...

While the "S" in e.g. SLIN stands for Spline, as far as I know, they just signify a new algorithm for the pathplanning. In online teaching they are now the default. But you can put them into a Spline block if you want to.
There are some things that work a bit differently from what I remember, but at least for me I've never felt that the S-movements are significantly better.

Best,
Johannes

14

Support / Re: Getting rid of those ridges

« on: May 13, 2022, 10:19:03 AM »

Hello,

You can right-click the symbol/name of each movement component and change the chosen interpolation method.
It would be possible to change the approximation parameters via the Custom KRL component, if needed.
Regarding defaults, the controller keeps the last value, as far as I know.
Also, you might give the SLIN movements a try, they can be a bit smoother. It's an option in the Code Generation settings.

Regarding why to blend: Without blending there is no way to make a polyline with a smooth movement - the robot would briefly stop at each control point. This is a fundamental challenge and not something related to KUKA robots in particular.

Best,
Johannes

15

Support / Re: Getting rid of those ridges

« on: May 12, 2022, 05:55:36 PM »

Hello,

For milling you probably aren't going to use C_PTP, so C_DIS and C_ORI is where it's at, mostly.
Unfortunately I cannot really help you with any hard numbers. My guess is that as always there is no "best" solution and you would have to optimize for a specific use-case, which might then be less ideal for another use-case.
The logic for C_DIS is that it's the distance in millimeters from where the TCP starts blending. So with C_DIS set to 2, it will leave the toolpath 2mm before the the next position. The maximum blending is half the distance, so if you have got two positions that are 1mm apart, it should blend after 0.5mm, even if C_DIS is set to 2mm.
Again, this is just my understanding of these values, and I might be wrong.
I believe the same logic applies to C_ORI but with degrees - but I'm even less sure on that one and didn't check the manual properly.

Best,
Johannes