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 - frenezulo

#1
Support / Re: Slow collision checking
July 29, 2014, 09:51:55 AM
Hello Johannes,
thanks for clarifying this!
One more question. The STATUS value in PTP MOVE determines what configuration will be used? It probably relates to status bits description on the page 65 in this manual: http://forum.robotsinarchitecture.org/index.php?action=dlattach;topic=20.0;attach=11 . Is that right?
So if I don't define the STATUS value, KUKA|prc chooses "the best one", but I can choose best configuration by my own by changing this STATUS, right?

Best regards,
Tomas
#2
Support / Re: Slow collision checking
July 28, 2014, 03:53:43 PM
Hello Johannes,
It's quite strange to me, but sometimes when I connect the slider and change the values (to change the positions of the robot), the profiler says it takes approximatelly 70 ms. But sometimes the values go to tenfold. I wasn't able to find, what's the reason for this, but I haven't changed anything else (eg. meshes, robot,...).

Thanks, I already found a way to change values and retrieve the results by script. I call it directly from Rhino Python Editor using calls based on this post on Grasshopper forum: http://www.grasshopper3d.com/forum/topics/automate-sliders-extract-model-data

Best regards,
Tomas
#3
Support / Slow collision checking
July 28, 2014, 10:32:41 AM
Hello Johannes,
together with the previous topic I also deal with problem of quite slow collision checking during simulation. I'm not sure if it is normal speed of the checking or if there is some problem at my side.
When the collision checking is off, the profiler measures approximatelly 5-10 ms at KUKA|prc CORE. When the collision checking is on, it rises to some 300-700 ms (sometimes 1.6 s). It happens even if I use simple meshes (block with 6 faces).

Is it standard behaviour? Why is it so slow even with these simple meshes?

Best regards,
Tomas
#4
Hello Johannes,
thanks for the explanation, it makes more sence to me now.

In the meantime, it came to my mind, that posting one position from some list at time would be the easiest way to overcome the described problem. So this is the same solution as you suggested :)

Thanks,
Tomas
#5
Hi Johannes (and others),
I have a question regarding the simulation slider and PTP move. I have several positions and when I want to simulate the movement between the positions (by script), I don't know what values should I prescribe for each position.
For example, I have 3 positions (and START and END position), so I made one slider with the extent 0-4 and remapped it to 0-1 extent. The positions change in these values: 0.41, 2.01, 2.81, 3.61. It doesn't make sence for me! Is it somehow possible to change positions in linear manner (by slider or other component)?

Best regards,
Tomas
#6
Support / Re: KUKA|prc with ghpythonlib.components
June 12, 2014, 11:51:24 PM
Hi Johannes,
thank you, I'll be looking forward to the news from you.
I'm not an Python expert to, but I was able to use other Grasshopper components in this way, so I was hoping to use KUKA|prc components. Hope it will be possible in some way.

Best regards,
Tomas
#7
Support / KUKA|prc with ghpythonlib.components
June 11, 2014, 10:33:19 AM
Hi,
first, thanks for this interesting tool, KUKA|prc. I've just started playing around with it and it seems promising for my intents.
I would like to use KUKA|prc components inside Grasshopper Python Script Editor (and Rhino Python Script Editor) using ghpythonlib.components. It seems, that these Kuka components are able to import, but I can't get it work. Even if I connect the same components to the inputs of the Python script (as seen in the attached image) with ghcomp.KUKA.KUKAXprcCore() component as to the standard KUKA|prc CORE, I can't get any output.
Do you know, where the problem could be?

Thanks,
Tomas