Recent posts
#91
Support / Re: Offset 0,0,0 on custom bas...
Last post by Johannes @ Robots in Architecture - March 18, 2025, 04:52:14 PMHello 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
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
#92
Support / Offset 0,0,0 on custom base
Last post by OXIDO - March 18, 2025, 02:24:43 PMHello,
I am working with the DKP 400 turn table and we have an additional base at a height of 75mm. The positioning system of the turntable orient the robot but the point 0,0,0 is still on the turntable. I need to offset this point on our custom base. I have attached a gh file containing the robot and turn table positions, and a mesh of the base we need the 0,0,0 on.
regards,
Ojas
000 on new base on TT.gh
I am working with the DKP 400 turn table and we have an additional base at a height of 75mm. The positioning system of the turntable orient the robot but the point 0,0,0 is still on the turntable. I need to offset this point on our custom base. I have attached a gh file containing the robot and turn table positions, and a mesh of the base we need the 0,0,0 on.
regards,
Ojas
000 on new base on TT.gh
#93
Support / Re: Adjusting approach angle o...
Last post by tjroy - March 05, 2025, 07:01:05 PMOk I think I can work with that, thanks!
#94
Support / Re: Understanding G-code to KR...
Last post by federgarrido - March 05, 2025, 10:33:14 AMCool! I will give it a try. Thanks!
#95
Support / Re: Adjusting approach angle o...
Last post by Johannes @ Robots in Architecture - March 05, 2025, 07:31:00 AMAh, 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
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
#96
Support / Re: Adjusting approach angle o...
Last post by tjroy - March 04, 2025, 10:57:23 PMThanks for the response! I guess I meant more of "I can't find a way to specify what the coordinate frame should be at each point", mostly due to the point components only having XYZ location data. If there's a different method to use, rather than the drilling one, I'm all ears! Other than this slight hiccup, the drilling method has been working fairly well.
The existing point coordinate frames do match the Z axis of the normal vector they're related to, but I would think there should be a way to rotate the XY vectors about the Z axis, which is the best descriptor of what I'm trying to do.
The existing point coordinate frames do match the Z axis of the normal vector they're related to, but I would think there should be a way to rotate the XY vectors about the Z axis, which is the best descriptor of what I'm trying to do.
#97
Support / Re: Adjusting approach angle o...
Last post by Johannes @ Robots in Architecture - March 04, 2025, 07:41:46 AMHello,
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
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
#98
Support / Adjusting approach angle of Ku...
Last post by tjroy - March 03, 2025, 05:01:53 PMWe've got a toolpath set up that mimics the demo program Johannes posted here, which by and large has been working for us. However, I'm running into an issue wherein there doesn't seem to be a way to define the coordinate frame of the tool at the specified point. I've attached a screenshot below of what I mean, but as far as I can tell the program chooses the XYZ vectors of each point automatically, which is causing collisions that shouldn't need to happen. The point components do not have coordinate frames in Grasshopper at least, only XYZ locations, so I'm unclear what I'd need to change. Appreciate any advice!
#99
Support / Re: Understanding G-code to KR...
Last post by Johannes @ Robots in Architecture - February 28, 2025, 09:48:18 AMHello,
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:
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
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:
QuoteSets 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.datSo 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
#100
Support / Re: Coordinating Motion with a...
Last post by Johannes @ Robots in Architecture - February 28, 2025, 09:38:24 AMHello,
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
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