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

#1276
Support / Re: KR6-10 R 900 - Axes 4 Error
December 14, 2015, 08:30:32 AM
Hello,

Are you 100% sure that you are using the same XYZABC tool and base values for physical robot and the simulation? That would be the easiest solution why your tool is oriented differently. Instead of the standard Kress-spindle, use a Custom Tool, enter the XYZABC values that you measured at the robot, and see if the simulation changes. You do not have to provide a mesh for the Custom Tool, it is only used for visualization and collision checking.

If that is the case, please let me know which version of KUKA|prc you are using (it tells you so in the first screen of the settings) and send the Grasshopper/Rhino file, as well as the generated SRC file to johannes@robotsinarchitecture.org

Best,
Johannes
#1277
General Discussion / Re: "Link" not working
December 13, 2015, 06:45:40 PM
Hello,

I just tested it in a KRC4-VM and could reproduce your problem.

Best,
Johannes
#1278
Support / Re: KR6-16 Arc A3 limit seems to be wrong
December 13, 2015, 06:26:32 PM
Hello,

If you've got a particular position that causes the problem it makes trouble-shooting much easier.
Just send me a Grasshopper file with just that single position (which shows up as valid in PRC, but doesn't work with your robot) as well as your exact tool and base values and I can double-check with KUKA SimPro if there is any difference between KUKA|prc and the official KUKA software.

Best,
Johannes
#1279
General Discussion / Re: Log group ARHHHH !
December 13, 2015, 06:21:54 PM
Hello,

Is there any particular thing you need administrator access for? With the additional drives being accessible I personally only use elevated user groups when I have to change system settings, or - more often - when I want to edit a KRL file directly.
I'm sure that there is some hack to get around that, but to be honest I haven't ever been bothered enough by the user groups to look into that.
Sorry that I wasn't able to help you with that. You can try to get in touch with KUKA regarding your issues, but I don't think that they could provide you with an official solution either.

Best,
Johannes
#1280
Support / Re: KR6-16 Arc A3 limit seems to be wrong
December 13, 2015, 06:14:48 PM
Hello,

There can be a few reasons for that, first of all of course that there is an issue with the simulation - however I just checked the code and it seems to be identical to your screenshot.
You can also set software limits for each axis, so it is entirely possible that e.g. someone before you restricted the robot for a particular task. If you see that, be careful about changing it back the the default position as that person may have added mechanical stops as well.
Also, KUKA|prc only calculates the programmed positions. If you also want to see the positions between that, you would have to enable the LIN interpolation in the settings. Finally, if the tool and base values of the simulation and reality do not match up, you won't get a reliable simulation.

Best,
Johannes
#1281
General Discussion / Re: Log group ARHHHH !
December 13, 2015, 06:07:56 PM
Hello,

I remember that somebody mentioned it being possible to override with KRC2, but not KRC4 - never tried it as it makes sense to use the user groups, at least in our context.
However if you just want to access the other drives, or the USB stick, there is an easier way around that: Switch to the Windows side (user group expert, Minimize HMI) and go to C:\KRC\UTIL\KRCCONFIGURATOR. There's the KrcConfigurator.exe which you can use to make e.g. the USB drive accessible and writable to the regular user group.

Best,
Johannes
#1282
General Discussion / Re: Auto-pilot
December 13, 2015, 06:02:26 PM
Hello,

With KRC4 you switch the key, enter AUT mode, switch the key back, then enable the drives (the I in SIR, so that S and I are both green) and can then start the program.
With KRC2 you have to turn the key into AUTO position, which is in the upper left corner - make sure not to use EXT (Auto extern).
Be aware that you will still have to keep the program start key pressed until the robot has reached the first axis position, same as with T1 and T2.

There is a chance that AUT mode was disabled on your robot or that you your safety setup interferes with it.

Best,
Johannes
#1283
General Discussion / Re: "Link" not working
December 13, 2015, 05:52:57 PM
Hello,

Thanks for sharing!
I'm not aware of any official list, but you are more likely to run into a problem with your own files, rather than the system files. KUKA|prc names the project and the definition (first line DEF) identically so that if you copy an existing file it will overwrite the old one. But you could e.g. manually rename the *.src file and then run into these issues. Maybe that's even what happened to you? Though link could be a system file as well.

Best,
Johannes
#1284
Tutorials / Re: Surface Milling Tutorials
December 05, 2015, 12:40:02 PM
Of that particular example?

Here you go!
Best,
Johannes
#1285
General Discussion / Re: Milling questions
December 05, 2015, 12:31:34 PM
Hello,

I would strongly recommend to add safety movements to avoid such problems - the Toolaxis Offset is generally a good idea as it shifts the tool by its tool axis. If you add process three surfaces with the Divide Surface component it is going to output three lists of movements. Just plug them into the Toolaxis Offset component and by default you will add an offset movement at the beginning and at the end of each list. For the robot, flatten the three lists into one list and you're good to go.

If you only want to mill in one direction, I've created a quick example as both regular components and as a cluster. As you're using the member version I've used that, but it should also be useful for anyone with the current free version. Just ignore the error messages and turn the planes into LIN movements.

Hope that helps,
Best,

Johannes
#1286
Hello,

Hmm... In the most recent version you can already click into the analysis graph and the robot skips to that position.
So basically you would like a separate "Play" button in the Analysis graph?

Best,
Johannes
#1287
General Discussion / Re: Plasma torch anyone ?
November 30, 2015, 07:51:25 AM
Hello,

Hmmm... I know someone in Argentina who uses KUKA|prc for that, send me an eMail and I can put you in touch.
Your robot may already have a few digital inputs and outputs that you can use to control the torch, otherwise additional IO elements are not very expensive to add. It's just important that your torch has got some interface that allows you to trigger it via a digital signal.

Best,
Johannes
#1288
Support / Re: And now... electric problems
November 30, 2015, 07:46:38 AM
Hello,

I'm sorry to hear that - as I mentioned, the same happened to our (actually really good, electrician) if that is any consolation.
Generally I try to avoid giving any advice regarding the electrical or safety installation outside the robot, as that is not really my area of expertise and I don't want to endanger anyone with bad advise...!

Best,
Johannes
#1289
Support / Re: Setting X11 up for use with KUKAprc
November 26, 2015, 10:31:25 AM
Hello Christian,

IBN mode is basically the same as T1, so you always have to keep the confirmation key on the back pressed.
There should be a printout with all the wiring diagrams included with your robot. In 99% of cases you can also just rely on the generic wiring in the PDF for your controller. I've attached it to this post, refer to page 54. You have to bridge E-Stop External Channel A (pin 2) with Test Output A (pin 1), E-Stop External Channel B (pin 11) with Test Output B (pin 10), etc. Just be aware that running a robot without proper safety is dangerous and of course not recommended.

I can issue you a trial version of the new KUKA|prc as I believe that the R700 version of the Agilus is not included in the public trial version. Send me an eMail to johannes@robotsinarchitecture.org

Best,
Johannes
#1290
Support / Re: Robot origin and BASE coordinate system
November 14, 2015, 03:59:09 PM
Hello Dan,

That is "working as intended": Basically the base defines a local coordinate system through its offset from the robot's global origin. So you could either show that by placing the robot on the origin of Rhino and moving the toolpath, or the other way round. As robots - and their global origins - can be placed quite freely in 3D space we decided that moving the robot makes more sense than moving the workpiece. Otherwise you would also e.g. have a disconnect between your referenced geometry and the robot toolpaths.
The only situation where we rotate the workpiece along with it is when rotary axes are used, as it would be very strange to have the robot rotate around you in the simulation.

I hope that makes our decision clearer - as often with robot things there is no "right" way to do it, but many different ways that lead to the same goal.

Best,
Johannes