Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Johannes @ Robots in Architecture

Pages: 1 ... 48 49 [50] 51 52 ... 54
736
General Discussion / Re: How to import ,...
« on: October 15, 2014, 08:14:10 AM »
Hello,

Well, the tool is as accurate as you draw it - you can of course e.g. constructively find the accurate TCP, or even work backwards from the XYZABC values you got when you calibrated the tool on the robot.
On the other hand, a simulation is never going to be 100% accurate anyway, as also the physical robot is probably not 100% identical to the public 3D model, with some additional, internal calibration data ensuring accuracy on a "real" robot..

In the image, the mesh geometry that you have at the global origin is basically the source geometry for the tool (you can hide it in Rhino). It is then moved to the right position according to the robot's axis values and the tool's XYZABC values.

Hiding the robot works as with any Grasshopper component, i.e. right-click and disable preview.

Best,
Johannes @ Robots in Architecture

737
General Discussion / Re: How to import ,...
« on: October 14, 2014, 05:35:35 PM »
Hello,

With global origin I'm referring to the actual global origin of Rhino, not that of an arbitrary construction plane.
Just move the gripper manually to the global origin of Rhino, as I did in the modified file. When looking at your screenshot, the gripper seems more or less in the right position. I think I set the TCP of the gripper to the back of its clamps, if you want it to be at the front of the clamps, just move the gripper geometry and adjust the Z-value accordingly (i.e. measure the distance between zero point and the flange-mounting point of the gripper).

Best,
Johannes @ Robots in Architecture

738
General Discussion / Re: How to import ,...
« on: October 14, 2014, 04:45:32 PM »
KUKA|prc assumes the TCP of a custom tool geometry to be at the global origin of Rhino. On the robot you have to calibrate the tool to get the right XYZ and ABC values. The KUKA manual guides you through all the calibration steps (e.g. first get the right XYZ offset from the flange via "XYZ-4 Point" and then the ABC values via "ABC World").

Best,
Johannes @ Robots in Architecture

739
General Discussion / Re: How to import ,...
« on: October 14, 2014, 03:31:28 PM »
Hello,

You rather overcompensated by putting in rather arbitrary values in the tool settings and the moving the tool in space. I've fixed the file, take a look at the attachments.
Basically, it's important to remember that there are several ways how to calibrate a tool, especially in regards which tool axis is used (by default X).
So for now I've put the Tool Center Point (TCP) of the gripper to the global origin with X being the tool axis. As the tool is normal to the flange, B=-90, and A and C = 0.
The TCP is 255mm away from the flange, and if you take a look at the KUKA manual or the custom tool illustration, the axis normal to the flange is Z. Therefore, Z=255 and X and Y = 0.
One more important thing: You set the tool nr 0 for the tool - this is a very bad idea, as the tool 0 should be the flange (I'm personally unsure if you can even change it easily) with 0/0/0/0/0/0 for XYZABC. Set the same number and same values as you got when you calibrated the gripper at the robot. If you really got X=-1390, Y=430, and Z=-2180 for the tool, I'm quite sure that there is some error - that tool center point would be somewhere near the robots root point.

Hope this helps!

Best,
Johannes @ Robots in Architecture

740
General Discussion / Re: 6 axis +1 external synchronuos
« on: October 14, 2014, 10:05:34 AM »
Hello,

Excellent, I've replied to your eMail. It's a very nice setup you have there, just be advised that at the moment, KUKA|prc only supports one external axis. We are working on a new version that is much faster, more accurate, and supports more external axes and expect an early member version to be published sometime in very late 2014, early 2015.

Best,
Johannes @ Robots in Architecture

741
General Discussion / Re: Brick laying
« on: October 14, 2014, 09:16:13 AM »
Hello,

Glad you figured it out! When you posted it was very early morning here, so I didn't see the posts until now.
I'll get back to your eMail in a few minutes!

Best,
Johannes @ Robots in Architecture

742
General Discussion / Re: Brick laying
« on: October 13, 2014, 04:28:20 PM »
I believe the pick and place example already uses the Custom Tool component, so just plug in your tool geometry as a single mesh (i.e. mesh it, join it, and ideally use ReduceMesh to reduce its size = increase the performance). Then double-click (or right-click) the component to get into the settings and enter the according XYZABC values. If you've already calibrated the tool at the robot then you can take these values, otherwise take a look at the explanatory graphic near the XYZABC values, i.e. with Z+ direction being the normal of the flange, and X+ pointing downwards.

Best,
Johannes @ Robots in Architecture

743
General Discussion / Re: How can I get dat and src file from PRC?
« on: October 10, 2014, 10:56:42 AM »
Hello,

Well, this is something robot-related, i.e. nothing that is special to KUKA|prc. With your robot you should have received a DVD with all the PDF documentation, look especially for the KUKA System Software.

Here's the official definition of C_DIS:
Quote
A translational distance can be assigned to the variable $APO.CDIS. If the approximate
positioning is triggered by this variable, the controller leaves the individual block contour, at
the earliest, when the distance from the end point falls below the value in $APO.CDIS.

And here is C_VEL:
Quote
A percentage value can be assigned to the variable $APO.CVEL. This value specifies the
percentage of the programmed velocity ($VEL) atwhich the approximate positioning process
is started, at the earliest, in the deceleration phase of the individual block. The component
which, during the motion, reaches or comes closest to the programmed velocity value, is then
evaluated in terms of translation, swivel and rotation.

Basically the higher the value (distance for C_DIS, percentage for C_VEL) the smoother the movement will be, but it will also be less close to the programmed path.
I've attached a screenshot from an older KUKA manual.

And yes, only change the limit for A06!

Best,
Johannes @ Robots in Architecture

744
General Discussion / Re: How can I get dat and src file from PRC?
« on: October 08, 2014, 05:03:23 PM »
Hello,

I wasn't able to look at the entire video as my internet connection is quite slow in the train, but from what I've seen it's probably a wrong setting at the robot. Either the C_DIS value doesn't allow any blending of motions, or the robot is running in single-step mode. But then it would also show up like that with other files. Try changing the C_DIS value in the KUKA|prc settings if the single-step issue does not occur with other robot files.
Regarding the red coloring, that should be fixed in the member version which is several months ahead of the free version. For now, I would recommend just setting the axis limit for A6 to -360 to 360. The next major KUKA|prc release that will hopefully enter testing at the end of November will much more reliably simulate also processes that go past 180 degrees, e.g. winding.
Regarding your 3D model I would recommend running the ReduceMesh command, as it seems like a very high-poly model, which will negatively impact KUKA|prc and Grasshopper performance.

Best,
Johannes @ Robots in Architecture

745
General Discussion / Re: How can I get dat and src file from PRC?
« on: October 07, 2014, 10:07:42 PM »
Hello!

To get started I would recommend taking a look at the examples in the forum. The documentation is indeed out of date, though there are some additional files for members. But just ask if you run into any issues!
We intentionally made it so that even the free version generates fully working robot code - if you're using an example file, make sure that the "Save File" box is checked and set an Output directory in the settings.
However, there is no need for a SRC and DAT file, all the necessary data is contained within the SRC file.

What are you referring to as the "robot dimension"? Do you want to create a custom robot model?

Best,
Johannes @ Robots in Architecture

746
General Discussion / Re: Brick laying
« on: September 15, 2014, 10:35:25 AM »
Hello,

You can also prototype it with the free version, the member version is quite a bit faster and supports external axes, among other "member" features. But a proof of concept can definitely be done with the free version as well.
Of course we'd like to have you as a member of the Association, though - there just shouldn't be any pressure ;)

Best,
Johannes @ Robots in Architecture

747
General Discussion / Re: required software for milling with Kuka PRC
« on: September 14, 2014, 07:55:03 PM »
The video looks good to me, but now I got your file and it looks quite a bit more complicated to me.
To get something really accurate I would have to know what each of this operation means with that machine. Quite a few G-code operations are universal, but I'm not an expert on that topic.

N108 T2 M6
N110 G0 G54 G90 X-231.077 Y-50. C0. B0. S630 M3
N112 G43 H2 Z50.
N114 Z10.
N116 G1 Z-2.732 F120.
N118 X-181.077
N120 G3 X-131.077 Y0. J50.
N122 G1 Y48.75


I can probably fix you something up that quickly gets you the XYZ and feeding speed for each point, but going into more detail with e.g. the circular movements isn't going to be possible in the coming week as there is too much to do.

Best,
Johannes @ Robots in Architecture

748
General Discussion / Re: Brick laying
« on: September 14, 2014, 07:45:12 PM »
Hello,

Well, brick-laying is basically just pick-and-place, an example for pick-and-placing is here: http://forum.robotsinarchitecture.org/index.php/topic,3.0.html
The member versions contain separate components to actuate the digital outputs, though you can just enter the relevant code into the Generic KRL component of the free version (e.g. $OUT[4]=TRUE to set the gripper that is connect to output 4 to true).
Of course, you still have to define the position of the bricks, which can be quite elaborate, e.g. if you want to ensure that it's as stable as possible.

So from the robot side no problem at all once you've defined where you actually want to place your bricks!
Best,
Johannes @ Robots in Architecture

749
General Discussion / Re: required software for milling with Kuka PRC
« on: September 14, 2014, 11:40:04 AM »
I would suggest choosing a machine that is included by default with MasterCAM and has got all the degrees of freedom you require. Besides that, choose the one with the clearest syntax and easiest to read code!
Best,
Johannes

750
General Discussion / Re: required software for milling with Kuka PRC
« on: September 14, 2014, 10:12:33 AM »
Hello,

Well, the nice thing about Grasshopper is that you can implement your custom algorithms for e.g. importing G-code and turning 3 or 5-axis toolpaths into proper robot code.
At the moment, we have a component for SprutCAM, but a while ago we also worked on a postprocessor for VisualMill G-code (which should be similar to RhinoCAM). So it's definitely possible. The first step would be to send me an exemplary G-code file. If you can choose from multiple internal postprocessors, choose the one that makes the least messy code. Then I'll be able to tell you if that is easy to do or not!

Best,
Johannes

Pages: 1 ... 48 49 [50] 51 52 ... 54