Messages

Hello,

To be honest I couldn't think of any operation where you would need a full circle, so we tried to define the arc in the simplest, most accessible way via three points - which does not allow full circles. However I just had a good idea on how to implement that in a nice and visually good way - stay tuned for one of the next releases :)

Best,
Johannes

Hello,

Thanks for letting me know, the Play component usually needs the Core component to be executed once, so that it knows the time of the project. I'll look into saving the last known value, and/or providing a more descriptive error message!

Best,
Johannes

Hello,

I got the file and see the problem, however it is mostly related to the tool path planning. The problem is that you are moving "around" the piece so as you say the axes wind themselves up. I would recommend doing each cut (from one singular point to the other) separably, rather than going full circle. If needed, add AXIS movements to unwind the axes. Mind that you can set some axes to infinite rotation, but you will then have issues with the cables of your spindle.
I hope you don't mind that I've attached a screenshot of your toolpaths to the post, so that other users can get some idea of the issue.

Let me know if you run into issues when implementing my suggestions!

Best,
Johannes

Hello,

Hmmm... As I wrote in the eMail, your robot seems to have a problem at 145.1 degree for A3, while A3 should actually go up to 154 degree, as per the manual.
Before I didn't read my own screenshot properly, because it says that setting it to 0 means that the checking is disabled. My guess is that someone edited that and accidentally switched numbers, going for 145 instead of 154.
Can you send me the $machine.dat file from the R1/MADA directory? Maybe rename it to machine.txt so that your eMail client doesn't complain about strange file endings.

Best,
Johannes

Hello,

Glad to hear that! It may be a good idea to get in touch with the KUKA hotline and ask them to send you all the relevant PDF-manuals for your robot (i.e. at least the manual for robot, controller and software). They may ask you for the robot and controller serial number, so look that up beforehand.
Newer KUKA robots come with a "Parts & Docs" DVD that contains the manuals for all the robots, software and controllers (but only relating to KRC4 and newer, so not that helpful for you).

Best,
Johannes

Hello,

It seems you didn't get the manuals along with the robot :)
The screenshot from the manual is attached!

Regarding the brightness the KRC2-KCP is just quite dim - however I've seen some KCPs that were brighter than others, so maybe they use different screens sometimes. I doubt that you could do anything from the Windows side in that regard, though.

Best,
Johannes

Hmm.. That is really strange... Is that where you checked the axis limits? (see attachment)

Hello,

Can you send me the file?
For unwinding you need to define an axis position. I've noticed that a few robots had a wrong A6 limit of -360 to 360 instead of -350 to 350, so maybe that went wrong...
Thanks,

Johannes

Hello Egor,

Thanks for your message, I've checked your file and it seems that you've approached some of the issues a bit more complicated than they have to be. I've also upgraded it to the most recent KUKA|prc version. If you send me an eMail to johannes@robotsinarchitecture.org I can send you a license for a few months - usually it is only available to members. Note that if you open it now, you will get a bunch of error messages until you've updated KUKA|prc. The file is attached.

Before the very specific problem, here are my replies to the general issues:

2.) Collision checking: While you are right that the robot can move to a given point with multiple postures (called STATUS, in the case of KUKA robots, e.g. 010, defining if the robot reaches backwards or forwards, if A4 is flipped etc.) it is NOT possible to smoothly transition from one posture to the next on the workspace. This is only possible with e.g. a seven axis robot like the iiwa, which can move its extra axis while the tool stays at exactly the same position. Therefore, collision avoidance (as you would like to have it) is not possible, you have to adjust your parametric toolpaths to avoid collisions (the beauty of Grasshopper being that you adjust your toolpaths and immediately see the effect on the robot, e.g. via the Axis graph).
Some kind of collision avoidance is possible if you use a symmetrical tool, like with milling, where you can rotate around the tool axis without changing anything. The easiest way to change that rotation is via the orientation point.
I hope you understand that it would be disastrous if you program a toolpath and then all of a sudden the automatic collision avoidance activates itself and by itself changes the posture of the robot.

3.) There is a slight misunderstanding, you do not need to manually click Apply all the time, whenever you change anything, the .src file updates automatically. If you do not want that automated behavior, you can right-click the core-component and choose "Expose Filename and Save Settings". You can then define the projectname with a string input, and use a "Button" component to save it manually.

Besides that I checked your file and everything seems OK. I did check your toolpath with the new KUKA|prc and your toolpath strategy windows up the tool to a maximum of 350.39 degrees, i.e. just a few degrees over the maximum. The easiest way to circumvent your problem is to adjust the toolpath accordingly, or to set your A6 to infinite rotation.

One more important thing: You've used an extremely fine mesh for your tool, with over 30.000 triangles. Using Rhino's ReduceMesh command I've reduced it to 3000 triangles - this greatly improves performance, especially with a weak graphics card.

Hope that helps!
Best,
Johannes @ Robots in Architecture

Hello,

Please re-read my first post - you can use the KRC Configurator to make the USB drive show up in the regular user mode as well!

Best,
Johannes

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

Hello,

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

Best,
Johannes

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

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

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