Menu

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.

Show posts Menu

Messages - Johannes @ Robots in Architecture

#1291
General Discussion / Re: Rotatory table example
December 15, 2014, 07:17:07 PM
Hello Mario,

The component that creates a series of isocurves along a surface predates the turntable (and linear axis) by quite a while, so I never made it work with an external axis. This is why you don't see any movement happening. With the regular movement components (e.g. LINear or PTP) you can manually enter a rotation value via the E01 input.

Do you actively use that component or just used it as a filler? It's important for me to understand what components are frequently used so that we focus on improving those.

Best,
Johannes
#1292
General Discussion / Re: Rotatory table example
December 15, 2014, 04:35:14 PM
Hello,

Sure, it's attached to my post!
Please note that I would consider the turntable support in the current KUKA|prc version "beta", it's actually quite improved in the coming KUKA|prc release (which may go out to some early testers shortly before Christmas or very early 2015).

IMPORTANT: The attached file will only work if you have got a valid KUKA|prc member license installed.

Best,
Johannes
#1293
Support / Re: KRC1 files
December 07, 2014, 08:13:31 PM
Hello Taity,

The member version already supports automatic file splitting, if you send me an example file (GH and 3DM) I can have it output the code so that you see if it helps with the KRC1 memory limit or not.
My eMail address is johannes@robotsinarchitecture.org

Best,
Johannes
#1294
Hello,

Great to hear that the Welsh School of Architecture got (or is getting?) a robot! Who is responsible for the robot from the faculty?
At the moment, we don't have the KR600 in our robot library, but we integrate new robot types for our members for free. Also with the free version you can define a custom robot, just make sure not to use too many polygons (the Rhino command ReduceMesh is very useful!).
Anyway, regarding your question on milling: We have done quite a few projects with milling and KUKA|prc (like e.g. a monumental sculpture at the Red Bull Formula 1 Racing Track, realized by two artists: http://www.robotsinarchitecture.org/931/recent-robot-news) and very recently actually a wood project where we milled 400 nodes (the video is not public yet, but send me an eMail to johannes robotsinarchitecture.org and I can privately forward it).
The issue is how to generate the toolpaths. As of now - to my knowledge - there is no proper Grasshopper milling-toolpath plugin available, so you can either define the toolpaths yourself using Grasshopper components, or get the data from elsewhere. As you want to do unique joints, the parametric GH-way is probably the way to go. The member version of KUKA|prc also contains a postprocessor for SprutCAM which allows you to create toolpaths in SprutCAM and turn the 5-axis G-Code into KUKA code within KUKA|prc. The postprocessor-approach also works for many other applications, at one point we did a Slic3r postprocessor for 3D printing.
If you can share a sketch of your design I can give you some more accurate feedback, my eMail is listed above.

Best,
Johannes @ Robots in Architecture
#1295
Hello All,

As there have been some questions, here is a possible workflow towards achieving a KUKA|prc simulation that is as accurate as possible.

...mount the tool on the spindle. Go to Start-Up/Calibrate/Tool/XYZ 4 Point
...remember the number of the tool!
...choose a point anywhere in the robot's workspace (e.g. sharp tip of another tool, wood if you want to be extra-careful) and move the tooltip there.
...press Calibrate, then move the robot away, change its orientation and move it to the same point from another direction.
...at the end the robot will ask you for the load data, either enter it or use the default values
...it should now show you the average error of your measurement (sharp tips go down to 0.1-0.2mm if you are good, regular cylindrical tools probably in the area of 0.5-0.6mm) and the XYZ values (i.e. the offset from the flange in each direction).

...to set the orientation of the spindle, go to Start/Up/Calibrate/Tool/ABC World.
...choose 5D
...align the tool vertically, i.e. facing downwards as accurately as possible (there are more accurate ways than ABC World, but it's the easiest)
...press calibrate and confirm the load data
...Write down the XYZABC values of your tool as well as it's tool number

...to define a local coordinate system, go to Start-Up/Calibrate/Base/3-Point
...set a number for the base
...for the tool, choose the number of the tool that is currently mounted
...move the tooltip to the origin of your local coordinate system (from any direction, only the tooltip counts)
...press calibrate, then move the tooltip to a point in the X direction of your local coordinate system (the further the more accurate)
...press calibrate, then move the tooltip on a point on the XY plane (in the case of a rectangular, extruded stockmodel that would be anywhere on the surface plane, but preferably not too close to the origin. It does not have to be a corner point).
...Write down the resulting XYZABC values of your base as well as it's number.

...to use the same base in KUKA|prc, go into the KUKA|prc settings
...in the section "Base Settings" choose the right base number and enter your XYZABC values.
...click apply to save

...to create a custom tool, first model (or import it from somewhere) the tool and mesh it.
...join it into a single mesh (important! multiple meshes will for some reason slow KUKA|prc to a crawl). Consider using the ReduceMesh command in order to improve performance.
...place it in a way that the tooltip is at Rhino's global origin and X+ is along the tool axis.
...now get KUKA|prc's Custom Tool component and connect the mesh to its input.
...double-click the component and enter the number of your tool, as well as its XYZABC values.
...see also here: http://forum.robotsinarchitecture.org/index.php/topic,5.0.html

...having the same base and tool numbers as well as XYZABC values ensures that the simulation will be as accurate as possible.


This workflow applies to the very first projects only, once you know your tools' XYZABC values you just have to remember the number under which they were saved. In the case of milling you can e.g. try to make a Excel formula (or Grasshopper definition) that calculates the XYZABC values based on the length of the tool. You can also use a fixed base that is e.g. clearly marked on the robot's table and place your material accordingly, instead of calibrating a new base for every object.

Note that achieving a 100% accurate simulation is never possible, as the KUKA robot's algorithms are not public domain.
All the steps above are also described in the KUKA System Software manual. It is included with your robot as a PDF on the DVD - if for some reason it isn't, it should be possible to call the KUKA hotline and have it sent to your eMail address.

Hope this helps!

Johannes @ Robots in Architecture
#1296
Hello!

Well, there are very many ways, the easiest is probably the use the Approach/Retract components that you can find in the 02|Toolpath tab. They shift the first (if the START input is set to True) and the last (if the END input is set to True) position of a toolpath either along the tool axis, tangentially to the path, or along coordinates. For example if you have got a normal list of commands, then graft them and add the Approach/Retract, you get some sort of drilling pattern, i.e. the robot moves up, goes down to the point, goes up again, goes to the next position, etc.
The alternative is that you just move e.g the planes of the toolpaths to a safe height.
I've attached a file with two possible ways below!

Best,
Johannes @ Robots in Architecture
#1297
Support / Re: Milling problem
October 31, 2014, 07:12:30 PM
Hello Mikail,

I couldn't get the file to generate toolpaths on my SprutCAM - may be a slight version mismatch as I've got the most recent version but without the robot module. You can send me an eMail ( johannes robotsinarchitecture.org ) and I will forward you the fitting SprutCAM (postprocessor) settings.

Best,
Johannes
#1298
Support / Re: Milling problem
October 30, 2014, 07:37:59 PM
Hello Mikail,

Could you please clarify if you are using KUKA|prc to postprocess SprutCAM-GCode, or are you using SprutCAM to generate KRL code?
If SprutCAM is generating the KRL code, you would have to ask the SprutCAM team for support. What I can offer you is that you send me the SprutCAM file and I will try to convert it into KRL using our workflow via a custom postprocessor and KUKA|prc.

I would need...
...your SprutCAM file
...the XYZABC values and number of your tool
...the XYZABC values and number of your base

Best,
Johannes @ Robots in Architecture
#1299
General Discussion / Re: Brick laying
October 19, 2014, 03:58:27 PM
Excellent, glad to hear that it's working!

Best,
Johannes @ Robots in Architecture
#1300
General Discussion / Re: Brick laying
October 18, 2014, 08:41:18 AM
Hello Freddy,

In that case I'm 99.9% sure that the problem is with the tool and/or base calibration.
Do not just read the tool position of the robot and use its XYZABC values for the base, but do it the regular way via Calibrate/Base/3 Points, where you define the base with one point in the origin, one point in X-direction, and one point on the resulting XY plane.
Another thing to take care is the tool orientation, in your case it will be something like X = 350 (the length of the gripper), Y=0, Z=0, A=0, B=-90 (as it is oriented normal to the flange), C=0.
Again I have to emphasis that the XYZABC values have to be the same on the robot and in the simulation in order to get a meaningful simulation out of it. An even more important the base and tool numbers!

Best,
Johannes @ Robots in Architecture
#1301
General Discussion / Re: Brick laying
October 17, 2014, 12:51:49 PM
Hello,

No special postprocessor is needed, as KUKA didn't change the basic functionality much. You will most likely have to enable the "KRC2 compatibility" option in the output settings. Depending how old the KRC1 is it may require more changes to the header, please get back to us in the forum if it worked.
Ah, and advanced functions such as Spline movements won't work - I'd stay with LINear and PTP movements.

Best,
Johannes @ Robots in Architecture
#1302
Support / Re: wrong direction of the tool
October 16, 2014, 05:15:25 PM
Hmmm... Interesting! If you come across anything that might be a bug with KUKA|prc, please let me know, e.g. via johannes@robotsinarchitecture.org
Best,
Johannes
#1303
General Discussion / Re: 6 axis +1 external synchronuos
October 15, 2014, 11:33:37 PM
Hello,

You have to set the right base number and base XYZABC values in the KUKA|prc settings. As you are using a Custom Tool, go into the Custom Tool settings and set the right tool number and tool XYZABC values.
Finally, you can try to enable "Smooth Simulation" in the KUKA|prc Settings/Simulation Settings to see interpolated positions as well.
Now, if the simulation looks fine it *should* also work on the real robot. From your screenshot it seems that you've still got the default tool from the turntable example active.

Finally, what you can try to troubleshoot: Write down the XYZABC values of the first LIN position, activate the right tool and base, and then try to manually move the robot to that position. That should give you an idea what's wrong.

Best,
Johannes @ Robots in Architecture
#1304
General Discussion / Re: 6 axis +1 external synchronuos
October 15, 2014, 09:30:54 AM
That's actually good news as it means that the syntax is working. Now you have to troubleshoot to find the problem. What could be wrong...
...do you use the same tool/base number and XYZABC values on the robot and simulation?
...is the root point of the rotary axes set right? Right-click the component and set it like the calibrated turntable.
...through your editing you have set the linear axis E1 to 0.0, can the robot reach the rotary axis from there?

Then it should work. Please mind that I'll be out of the office the next days, so support may be slower!
Best,
Johannes @ Robots in Architecture
#1305
General Discussion / Re: 6 axis +1 external synchronuos
October 15, 2014, 08:21:53 AM
Hello,

That's most likely the problem. For the moment, the easiest way is probably just to do a search/replace on the KRL file.
E.g. search for "E1" and replace all with "E2", then search for "E2 0.0, E3 0.0" and replace with "E1 0.0, E3 0.0". I may be mistaken, but if I remember correctly the KUKA doesn't worry about the order of variables, i.e. if its XYZ or XZY.
On the long term, you can reconfigure the external axis from E1 to E2, or wait for a future KUKA|prc release for which we are planning to support more than one external axis.

Best,
Johannes @ Robots in Architecture