Messages

How could I repeat a set of commands in a rectangular array ?
If I use the rectangular array component it creates in fact not one transformation but as many as there are elements in the array, therefore the "Transform Command" component from KUKA|prc complains that there's multiple commands AND multiple transforms...
Aren't robots and Grasshopper meant to ease repetition ?

Hi Johannes,

The issue with the speeds for Carthesian offset is still not fixed.

The "Safe plane" component still ignores the "start" option.
Therefore, it only does the offset at the end of each commend branches.

The 3-Point component creates a normal plane geometry, so you should be able to use the "Plane Origin" component on it!

-Facepalm-
I thought it was a special class...
This opens-up a lot of options indeed ! Then, in effect, the KUKA-prc "3-Point to plane" component is almost identical to GH's "Plane 3 pt" with just O / X / Y replaced by O / Z / X ?

Now it's my turn to not fully understand what you mean :)
Maybe the confusion comes from my usage of the word "Base" ; I really meant "KUKA|prc frames".
I define my frames mostly with "3 points to plane" (which should really be called "3 points to frame", actually).
I generally don't use the "Frame" command, except when defining a base outside the GUI.

So when I want to set a tool orientation, but then just move the TCP to a different point, I'd like to have a component that works like "Plane origin".

PS : no more file attachments to messages ?
I tried to put a Google Drive link, but it doesn't seem to work.

I wish there was a similar component as the GH "Plane origin", but for KUKA|prc frames.
I find it sometimes tedious to define each frame with 3 points when all I want is to place the tool at a different location, but keeping the same orientation.
I know I can use "Transform command" for this, but it requires defining the vector between current base and new base plus a transformation... heavy !

[Some kind of high-level view of when it is preferable to use one or the other.]

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.

Thanks ! I'll give it a try.
What I need to grasp is the use case for CVEL vs CDIS.
Some kind of high-level view of when it is preferable to use one or the other.
I'm still struggling between a jerky robot with too little interpolation and a fuzzy robot that smooshes my shapes...

Regarding my first statement, I was confused by the fact the LIN component has no interpolation option (black label on the bottom) until it gets fed with inputs.
But indeed, as soon as it is, it defaults to C_DIS.

You are right regarding the tool offset : I see how taking out the interpolation just before the offset might create a tool mark.
Maybe you could propose a new tool offset type that would "overshoot" tangentialy the last frame along the trajectory and THEN offset in the tool axis.
The input would be the "overshoot" distance + the "Offset" distance and it would add a little CIRC movement to blend the trajectory and the offset...

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...

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...

[again]

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 ?

Back to turntable issues.
I use a "Master" definition with many milling strategies ; some of them using the turntable, and others not.
I just switch from one strategy to the other, and that will automatically set a bunch of relevant options and parameters.
But having the "Rotary axis" settings inside the main component forces me to fiddle in there each time.
In many occurences, I forgot to change these settings and narrowly avoided sending a bad .src file to my cabinet...

As you know, I feel the same way for ALL the settings which are inside the main component, but having a turntable and using it in production really makes this example stand out.

Looking at the .src structure, I realize that there is a "C.DIS" at the end of each LIN command, and a C_PTP at the end of each PTP command.
Does that mean that these values can be set differently for each and every command ?
KUKA|prc only allows to make a global setting ; isn't that a limitation?
Moreover, as you said, different jobs might require different values. Isn't that a good reason to expose them as inputs, and not be "static" inside the main component ?

Other subject : I suppose that if I enter no value, the controller uses defaults stored somewhere.
Where would that somewhere be ? I'm curious to know what lazy values give me so aweful results ; it will help me decide what new values to set in the hope of making decent stuff with my Orange beast.

[would it be really bad to set these values to zero]

Thanks for clarifying. I have read the documentation about these values in the KSS document, and the first time it mentions C-DIS is some tangled explanation about replacing LIN - CIRC with SLIN - SPL - SCIRC...
From my personnal interpretation, this "Aproximation" business is a way to make it easy on the motors / avoid abrupt direction or velocity changes.
But would it be really bad to set these values to zero ? I mean, what's the worse that could happen ?
Isn't the whole point of having a NC being able to make precise stuff ?

Just to double-check: So you are having three points.

Yes, exactly : that doesn't work.
Similarly to milling specs (spindle speed, feed rate, and depth of cut,...) for a given material and end mill, I'd like to have some feedback from people who have found good values for :
C-PTP
C-DIS
C-VEL
C-ORI
CP
PTP
...for the purpose of milling wood.
The results I have right now with the defaults are just terrible :
-Ridges at the end of loops
-Sharp edges/features on my parts being "eaten-up" by interpolation