Topics

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 ?

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

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 !

I realize that my table is turning in the wrong direction.
The gear ratio was set to a negative value (like all other axes on the robot, actually), but the table turns in the opposite direction as the simulation.
I just wanted to point that out because it could be a cause for failed millings for other people.
In short : for use with KUKA|prc, the gear ratio on the external axis must be set to a positive value.

I'm looking for better acceleration settings for milling as I keep getting areas where the tool plunged and exited in diagonal instead of straight.
This has nothing to do with trajectories defined within KUKA|prc. I I used "Reduce toolpath for instance, it could "round-off my trajectories, but here, it's really the robot that's not really going through all the waypoints.
I tried adding an extra point to "overshoot" the entry point and exit a bit further, and I still get this effect ; I suppose that the dynamic settings of the robot are still too "loose"...
If anyone facing the same problems has found just the right settings for this, I'd be glad to hear from him.

I am trying to fine-tune my tool ABC with a rotary planer, measuring the ridges between passes, and I'm just pulling my hair out.
I calculate the slight angular deviations from measuring precisely the height of these ridges in the wood I'm planing.
When I change the angle of my tool accordingly in KUKA|prc, I expected to see the ridges disappear, but it was like I peed in a violin as we say in France : no change.
So I checked the src files and noticed that when I was close to the vertical of the base, the small deviations were ignored : the SRC file has the same ABC values as for a vertical tool.
If I make a more pronounced angular change, then it registers...

Hi folks !

Please check out the first video of my Youtube chanel : https://youtu.be/jFdxNP097-4

Most milling jobs imply taking a rectangular stock from the shelf and milling out material to obtain a more complex shape.
One of the stated goals of my company Xylotica is to bring value to discarded wood ; therefore, I am designing a workflow to transform odd logs into useful objects.
In this case, a decorative planter.

Feel free to comment.

I'd like more control over the aspect of the simulation geometry.
In particular, I'd like the meshes to display transparent.
Sadly, Rhino ignores the transparency settings of the wiewports display mode for the standard KUKA|prc display.
So I tried to do my own custom preview, using data from the "GEO" output of the Main KUKA|prc component, and adding a transparency value.
There are three branches in the "GEO" output :
-One for the meshes,
-One for the colors (which has the same list length as the meshes)
-One for the trajectories (curves)

I can't find the logic of distribution for the colors...

I wish it was possible to extract current axis values from a LIN command.
This would allow to create an "Axis movement" command to "unwind" axis 4 and/or 6 : keeping all other axis values the same but re-setting 4 and/or 6 to zero.
I know I can retrieve them from the analysis, but trying to use it creates a recursive data stream (of course).
So there needs to be a component that runs the inverse kinematic engine before the main component (using the same base and tool inputs).

Or maybe there's a workaround I haven't thought of ...

Best

I'm setting up my turntable at last.
I've checked out the Turntable example file and watched Karl's videos, but I just can't make sense of what I see in the attached file.
The position and orientation don't seem to reflect the input values for the root XYZ and ABC.
Could there be a bug with the "Custom turn-table" component ? Or is it me ?

I've never needed analog output until now that I have a HSD spindle.
On the KSS, the values I can enter for the Analog output that controls the spindle speed range from 0 to 10.
With KUKA|prc, the values I can set in the "STATE" input for the "ANALOG OUT" component range from -1 to 1...

So what's the trick here ?

I started a thread on the RobotForum about automatic tool Z re-calibration :
https://www.robot-forum.com/robotforum/thread/39818-how-to-setup-an-automatic-tool-height-adjustment-system/?postID=178254#post178306

Could this be somewhat integrated in KUKA|prc ?
Something like a  "Z check" component ?

In the same spirit, a fully functional "tool change" component would be handy, instead of describing all the actions like :
-Go to this frame to drop current tool
-Move slowly to current tool's support clip
-Output to "1" for tool release
-Retreat to safe frame
-Go to new tool's location
-etc...

One would simply specify the new tool to load/check , and the corresponding SRC code would be written automatically

Hi Johannes,

Could you please add the KR210 r3100 Ultra to the robot components ?
There is already the KR210 R3300K and the KR210 R3100-2, but they are different machines.

Here's the beast, attached.

I wish the robot and tool were displayed, even when there are no values in the "CMDS" input.
It would be displayed with the "Start" position as defined in the KUKA|prc interface.

I wonder why the speed values are not printed out to a panel from the PTP component (or LIN component).
Also, this might sound like a silly question , but the % value for the PTP speed, errr... what is it a percentage of ?
Max speed of the flange ?
If so, this hardly makes sense because this depends on a lot of factors (extension, posture,...)
In fact I also wonder about LIN speeds because the resulting speed I observe have large variation despite being set as constant.
These variations can come from :
-Frequent direction changes
-Changes in the density of frames along the trajectory
-General tendency of stock market in Burundi
In short, I find that setting speeds on a robot is kind of an illusion of control. The darn thing is just going "generally faster" if you set a high value and "generally slower" if you set a low value.
I find that it makes speed-dependent processes difficult to get right.

I attached a "mock-up" of a possible evolution of the "Analysis" window.

First and foremeost, I think that priority should be given to respect the execution speed (or percentage of execution speed selected by the user), and that the framerate should always adapt.
In other words, the framerate should always be as high as possible for a given simulation speed , and that for two reasons :
-Who would set a crappy framerate on purpose anyways ?
-Who would want the simulation to not reflect the intended speed ?

If, despite a slower framerate, the simulation can not reflect the desired speed, then there should be a WARNING ! sign because it is not accurate, and accuracy is a desired attribute of a simulation.

Then I added a regular slider to make a "rough" positionning, and would use the white dotted line to make more accurate positionning.

The traditionnal buttons would be used to  "Play" and "Stop" of course, but also "go to start" and "go to end", which is not easy to do with the present interface.

Best,

As can be seen in this video : https://drive.google.com/file/d/1Ho-iwbalFSGNHlq_XM3w4A15cBDn9PeS/view?usp=sharing

The animation stops randomly, and it needs to be prodded by the "dotted slider line" to resume.

I think it would be nice to have an option  for not displaying the path which lies before the current animation frame (the one that has already been traveled trhough).
That would probably speed the animation as less and less path has to be drawn, and in some cases make things clearer.

What do you think ?

Sorry for this question not directly related to KUKA|prc, but : once a program is selected, how can I jump to a certain line ?
The "Escalator" slider is super slow in a program with over 25 000 lines...

I have set a specific value for the "Rapid" input in the "Fusion" component, but I can see that value defined nowhere in the .SRC file
I wish that there was an input to over-ride whatever process speed is defined in the .xml file exported from fusion, and that the "Rapid" input actually affects the speed of travel in the "hops" between actual milling.