Messages

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

Hello Mark,

Hmm... That's weird because 2% should still be very slow in AUT.
I think what you pasted below is the pseudo-code from plugging the movement components into a text box. Could you take a look into the SRC file?
Generally you would set the PTP speed in the component or in the settings. Just note that if you start with 2% speed and then set it to 10% anywhere in the program, it will stay at 10% until you change it again.

Best,
Johannes

Hmmm... I would try a PTP movement (with the same Cartesian position but the new E1 value) instead, then you should be able to control the speed via the normal PTP speed value.

Best,
Johannes

Hello Taj,

Most likely the speed values are taken from the input G-Code, using the F register for feeding speed and then turning it into m/sec that the robot is using. So ideally you would set the speed in your slicing software.

Best,
Johannes

Hello,

I looked at the G-code and the first part with XYZ movement would be that line:
G1 Z23.1000 F12000
Here, X and Y are not set, which are assumed to be 0.

The G1 gets turned into a PTP + LIN movement automatically in order to set the posture of the robot. This will only happen if the first movement you input is a LIN movement and then also only for the very first movement.

Best,
Johannes

Hello,

If you want to use external axes, you need to have a valid license - either from a membership (student or regular) or from a commercial license!

Best,
Johannes

Hello,
I only skipped through the G-Code file and didn't see anything that would set the tool axis - only the usual XYZ coordinates, extruder feed and TCP speed.
If it's only about the tool, then the easiest solution would be to switch the B value that is currently at 90 to -90. Note that you need to do that both in KUKA|prc and on the physical robot, as by default KUKA|prc only references the tool/base value and not the exact XYZABC values.
Best,
Johannes