Messages

Sorry, I cannot reproduce it. I just deleted my member version and installed the most recent Community Version from the package manager - it's showing up just as before. The version is the same as yours, so "1.0.8810.26816".
Maybe the issue is somewhere else. What kind of output are you getting from the script component?
Also double-check that you don't have KUKA|prc installed twice, so once in the package manager and once in the Components Library.

Best,
Johannes

Hello,
I only added a robot and it looks fine on my end. I don't believe that there has been any fundamental change between since the community version has been last released and the current state of the member version (relating to the three lines of code in the C# component).
Best,
Johannes

Hello,
Please take a look at the attached example. The KUKA|prc code is a bit special as we never intended someone else to interact directly with it, so you've been warned ;)
Best,
Johannes

Hello Ojas,

I looked at your file and didn't see any unreachable positions. I still don't fully understand the constraints on your process so it's hard for me to offer suggestions for improvement beyond obvious aspects such as reachability - sorry!

Best,
Johannes

Hello Ojas,

If the turntable is oriented correctly you do NOT need to compensate the position of the planes. The turntable will basically act like a mobile base coordinate system, i.e. it will move the planes around with it.
Make sure that you have calibrated your base in a way that it is linked to the turntable - so you will get XYZABC values that are in relation to the root of the turntable, not in relation to the root of the robot. If you calibrate such a base on top of the turntable, the values will be pretty small.
Finally, the turntable has to be a linked coordinate system. There should be an arrow going to the turntable in WorkVisual, if I remember correctly.

Best,
Johannes

Hello,

Here is an example that I believe gets close to what you want to achieve. It's very close to what I originally shared.
Some things to consider: You may need tweaks to get a nice continuous rotation, currently it will probably move back and forth on the top rotary axis. Also, I changed your tool values so that it is processing it from the side. If you face directly the robot, you run into tons of singularities.

Best,
Johannes

Hello,

Have you looked at that example?
It orients the TCP with the DKP so that it is vertical. If I understand your use-case correctly, it should be quite similar.

Best,
Johannes

Hello,
Sorry for the slight delay in getting back to you.
OxyPlot should be in "C:\Users\%user%\AppData\Roaming\Grasshopper\Libraries\KUKAprcGH" and not directly in the Libraries folder.
Also check via the PackageManager command in Rhino if KUKA|prc is also installed via that, so that it's around twice.
Best,
Johannes

Hello,
That points to a missing Oxyplot library. Did you use the regular installer or copy files manually?
You could also try to search for Oxyplot in your component library, maybe another component is also using that library and GH is getting confused.

Best,
Johannes

Hello Ojas,

You would need to set up a custom turntable for that to work, with the default geometry, 0 will always be on top of the turntable.

Best,
Johannes

Ah, now I get it. In the example, the angle is taken from the normal vector of the closest face on the mesh.
Basically a Cartesian movement is defined via a coordinate system, in Grasshopper referred to as a "Plane". In the Vector tab, there are multiple ways of defining a plane, such as via an origin point and two vectors (X, Y) or via an origin and a normal vector. Or you choose the "preset" orientations, like Plane XY, YZ, XZ.

Best,
Johannes

Hello,

What do you mean by "do not have coordinate frames in Grasshopper"? Because in your screenshot you can see the small coordinate systems. Generally there is no way in KUKA|prc to ONLY provide XYZ values. However, Grasshopper itself takes some liberties, so when you take a point with XYZ values and put it into a plane component (or an input expecting a plan geometry) then it turns that into a coordinate system with its origin at that point, and X facing in global X and Y facing in global Y.

Also, in that example we are using a milling spindle where we gain the rotation around the tool axis as a degree of freedom to optimize reachability (see the Orient Plane component). That is only useful if you have a symmetrical tool, otherwise that would also introduce weird behaviour.

Best,
Johannes

Hello,

For KUKA|prc the G-code import component can turn the extrusion values into an ON/OFF value for a digital output, to an external axis, or to a variable. This is taken from the help text:

Sets how the extrusion speed is output. Entering ""E1"", ""E2"" etc. will map the E value to an external axis. Entering ""D1"", ""D2"", etc. will map a Boolean on/off value to a digital output. Entering any other string will map the extrusion velocity (E value divided by toolpath segment length) to a variable, that needs to be create at the robot, e.g. as a global variable in $config.dat

So that is how you can get the data to the robot. How you get it to the Arduino is up to you. If it has to be PWM there are EtherCAT modules from Beckhoff, but they are 24V, so will fry your Arduino unless you get the voltage down. Easier would be an analog 4-20mA output, where there are several instructions online for reading such a signal with an Arduino. Unless it's built into your robot already, you'd also have to buy a Beckhoff module for it.
Very "clean" would be an EtherCAT shield like that: https://www.bausano.net/en/ethercat-arduino-2
In any case, all of that probably works, it mostly depends on where you feel most comfortable investing your time. I personally would take the EtherCAT shield but you will have to delve a bit deeper into WorkVisual for it to work.

Best,
Johannes

Hello,

Speed changes are only applied if the speed changes. So if a PTP movement has got the same speed as the last one, it won't generate a line of code for the speed.
It should look like that: BAS(#VEL_PTP,5)
For a LIN movement in your example it would be the $VEL.CP=0.00936 setting the speed to 9mm/sec. Just to cover both speed settings.

You could also manually put that into your test file, in that case 5 signifying 5% of speed.

Best,
Johannes

I guess your PTP speed is only initially set via BAS (#PTP_PARAMS,5).
Please try setting the speed for the PTP component before the rotation. Note that speed changes will only be written into KRL if the value changes, so if you set it for all components it will only add a line at the first occassion.
Best,
Johannes