Recent Posts

11

Support / setting origin at robot when using rotatry table?

« Last post by evo85210 on July 05, 2019, 02:40:10 PM »

I've noticed that once i've used the rotary table component, the origin become the top surface center of the rotary table, is it possible to keep the origin at the robot base?
-----
edit:
never miind, found the settings in the core component, would be nice if there was a option on the rotary table component, so I don't have to enter the values twice

12

General Discussion / Re: Need a Cheap Source Robotic Arm

« Last post by Johannes @ Robots in Architecture on July 05, 2019, 08:59:25 AM »

What is your budget? "Cheap" is very relative.

Best,
Johannes

13

General Discussion / Need a Cheap Source Robotic Arm

« Last post by ihanema on July 05, 2019, 08:17:12 AM »

Hey everyone I'm Iha
I'm looking for a cheap source robotic arm. Now I have so low budget so I just want to save my budget for next thing.
I need it for my project.
Any suggestion would be appreciate

Thanks in advance

14

Tutorials / Quick Getting Started for KUKA Sunrise

« Last post by Johannes @ Robots in Architecture on July 04, 2019, 12:10:43 PM »

As there are more and more iiwa users, here are some quick instructions to get you started with KUKA|prc (new, "v3" Version) and Sunrise:

Go into the KUKA|prc settings, Advanced/Code/Sunrise/Download Sunrise Library
The generated ZIP file contains a number of directories, copy them into your Sunrise project.
It should look somehow like in the attached screenshot.
Set up your tool and base in the Sunrise Workbench, make sure that the XYZABC values are the same in the KUKA|prc simulation and at the actual robot. Take care that Sunrise by default displays radians in the Workbench but degrees on the smartPad. KUKA|prc expects values in degrees.
Now modify the following lines to fit your base and tool in the PRC_RunXML.java file:

Code: [Select]

String toolname = "PolierVib"; //SET TOOL NAME
String tcpname = "TCP"; //SET TCP NAME
ObjectFrame baseFrame = getApplicationData().getFrame("/BASE1"); //OPTIONAL: SET BASE COORDINATE SYSTEM
When you run the program on the iiwa, you will get a file browser window. You can then select the XML file that was generated by KUKA|prc from e.g. a USB stick or a network share. You could also hardcode the path if you wanted to.

The UDP and SmartServo programs work in a similar way, but they need a realtime Ethernet (UDP) connection between robot and Grasshopper/KUKA|prc, so you need to set the right IPs, ports, and firewall settings.
Note that if you are not using the SmartServo tech package, you may need to delete the PRC_RunSmartServo.java file, otherwise Sunrise will complain because it’s looking for missing libraries.

Also, the iiwa has some limitations that are not linked to KUKA|prc, e.g. that the motion blending needs to be at least 4mm. So you need to set that as the C_DIS value in the KUKA|prc advanced settings, in order to get motion blending.
In general, very high point density can be problematic.

Hope that helps a bit!

Best,
Johannes

15

General Discussion / Re: fronius with kuka prc

« Last post by Deshazo3U on July 02, 2019, 08:29:26 AM »

HI
I have encountered the same problem as you, how did you do it. Can you share the file with me? Thanks in advance bluestack!

I am also having same issue. Please provide an relevant solution.

16

Support / Re: Error during ECat stack initialization?

« Last post by nsenske on July 01, 2019, 02:51:43 PM »

I'll try all of that today. Thanks for getting back to us.

((Sorry meant the X66 port as the KLI port! We aren't plugging anything into EtherCAT at the moment.))

17

Support / Re: Robot is scaled to 4 times the size of a 25' Project!

« Last post by Johannes @ Robots in Architecture on July 01, 2019, 09:58:17 AM »

Hello,

All KUKA robots work in mm, which is why KUKA|prc always assumes your project to be in millimeters as well.
So in Rhino you will need to copy/paste your geometry into a millimeter project or change the units of your original project.
We decided that it would be better to make this a responsibility of the user, so that we don't have accidental dual conversions or rounding errors on our end (think https://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_of_failure). As you mentioned, the mismatch in scale can be seen clearly in the simulation.
Hope this clarifies it a bit!

Best,
Johannes

18

Support / Re: Error during ECat stack initialization?

« Last post by Johannes @ Robots in Architecture on July 01, 2019, 09:51:58 AM »

I just checked, are you SURE that the X65 port is the KLI port?
On the Agilus - if I remember correctly - it's the EtherCAT port, which would explain your EtherCAT problems. X66 on the side would be KLI.

Best,
Johannes

19

Support / Re: Error during ECat stack initialization?

« Last post by Johannes @ Robots in Architecture on July 01, 2019, 09:49:26 AM »

Hello Nick,

I'd start by activating the old project again, that previously worked - just to make sure that the problem is software and not hardware related.
Then do the changes step-by-step, first the controller name, then the RoboTeam etc.
Also, verify that any connected EtherCAT periphery (EK1100 etc.) is correctly powered with the LEDs on.
As you connected the robots via Ethernet, did you make sure that they do not use the same IP address? I don't think that would have an impact on EtherCAT, but who knows...

Finally, a cold-boot from the Shutdown menu, with re-load files ticked, is never a bad idea.

Best,
Johannes

20

Support / Re: Error during ECat stack initialization?

« Last post by nsenske on June 30, 2019, 07:51:33 PM »

Hi Johannes,

We thought we had the eCat error fixed once we successfully jumped the X55 connector. The message away and were able to run automatic programs for a few days. It was working great.

The problem returned when I started configuring the controllers for Roboteam. I did two things on both controllers. Not sure what caused the error, but now they both have it again:

1.)   I renamed both controllers from the pendant Start-Up wizard to KUKA1 and KUKA2. Previously, they were named after the controller serial number. We are eventually going to have students working and I wanted to make the machine ID more clear.
2.)   I connected the controllers to an ethernet switch via CAT5 on the X65 (KLI) connection.

As prompted, I saved the changes to the RDC and then performed a controller restart with the file refresh / update option checked. After reboot, the SYS-X44 error came up. Once again, we can't run programs in AUT.

**********

I tried the following to attempt to fix the issue. None of these worked:

1.)   Checked the X55 connections; both seated correctly. Same error with them plugged in or not. (hardware likely not the cause as it affected both systems after the software change)
2.)   I unplugged the X65 connections and renamed the controllers back to their original names and reset, etc. (tried to return it to the earlier state)
3.)   I changed the X44 restart value in KRC\Roboter\Config\User\Common\ECAT_SYS_X44.xml from “manual” to “auto”, restarted etc.
4.)   I opened the current project in WorkVisual, removed the X44 interface and re-added it. eCat came attached to it by default. I deployed the project and restarted the controller.

I'm not certain whether I need to fix something else in WorkVisual, like you said. Perhaps we aren't properly running the shutdown sequence to recompile / deploy the files?

Do you have any ideas for things we could try?

Thanks!
Nick