Messages

Hello Toni,

Thank you for your suggestions!
I can look into the KRL-parsing, though at the moment it's quite busy here so I cannot give you a timeframe. In general, the KUKA Software SimPro / OfficeLite can read and simulate existing KRL files.
The save on/off suggestion is also good, it's just important for me to keep the component clean without to many inputs and outputs. I'll see if I can find a good position for a checkbox!

Best,
Johannes

Hello,

Your Agilus should have a number of digital outputs on its axis 4 (the connector where you screw off the cap). At least the valves (which are right next to it) are in my experience preconfigured, so you can just put a multimeter there and try out the first couple of digital outputs (Display/Outputs on the smartPAD) until you see a change in voltage.

The proper way to do it would be first look into the KRC4 compact controller. Inside there is probably an EtherCAT coupler like that: http://www.beckhoff.com/images/EtherCAT/EK1100__web.jpg
On the right side of the coupler you can add modules with inputs or outputs. Chances are good that there is already at least one installed. They each have got a number like EL2808 - go to the beckhoff.com homepage and try to find the one that gives you digital outputs,  like e.g. that one: http://download.beckhoff.com/download/Document/Catalog/Main_Catalog/english/separate-pages/EtherCAT/EL2808.pdf
As the next step, you have to configure the robot in a way so that he knows that when you switch the output 33 (or any number) you actually want to switch the third (or whatever) output of the Beckhoff terminal.
This configuration is done within the KUKA WorkVisual software (which is included with every robot). Do you have someone who knows how to use WorkVisual?

Before going into WorkVisual it makes sense just to try the first 20 or so digital outputs and see if something happens. Maybe whoever set up the robot already configured some outputs. Every Beckhoff terminal has got a number of signal LEDs on top that light up when the IO is on.

The standard Beckhoff digital output provides 0.5A at 24V which should be (more than!) enough for most LEDs. It probably still makes sense to use a relay, though.

On the KUKA|prc side it's easy, you just use the Digital Output component or - if you're using the trial version - write the code as you described into a Custom KRL Component.

Hope that helps!
Best,
Johannes

Hello Mikail,

I just checked how the comment system works, apparently a line like this is put into the file header:
&COMMENT testcomment

At the moment it's not possible to add that from within KUKA|prc (though you can of course just open the file in Notepad and add a line).
May I ask what your application would be for the comment line? For file organization?

Best,
Johannes @ Robots in Architecture

Hello,

E1 is the rotation value of the external, rotary axis, provide a value between -360 and +360.
To see the rotation happening, please plug a mesh of your piece into the input of the rotary table. With the current KUKA|prc version you will not see the toolpaths rotate (already implemented for the next version).
It may be easier to see if your shape isn't a rotational form or if it is placed off-center.

Best,
Johannes

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

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

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

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

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

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

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

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

Excellent, glad to hear that it's working!

Best,
Johannes @ Robots in Architecture

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

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