Messages

Hello,

Fusion should usually be very straightforward, you just need to export the right postprocessor by right-clicking the component. Beyond that I never really had any issues. Here's an example project: https://1drv.ms/f/s!AtgYyPhhrKrMneNhFJ6yUSOacMDy6g
And in the regular PRC there should be the NC Import component (see screenshot), I just haven't brought it into the new PRC yet, which I believe you are using - the one where the robots are more accurately colored!

Best,
Johannes

Hello,

Hmm... Where are you missing the old NC import?
Are you referring to the preview release of PRC, or the current, regular member version?

Best,
Johannes

Hello,

Can you send me the GH file where this happens? The tool offset code is basically the same since 5 years or so and I've never heard of that issue.
My guess would be that there is an invalid plane or something that causes problems on the GH side.

I'll have to send you a preview of the next PRC sometimes, which contains a few of your suggestions like the changes tool offset component and the relative graph!

Best,
Johannes

Hello,

I just checked again, the problem is that I've updated the component but not the example. Instead of the Boolean, please provide either a negative or positive double. A positive number overrules the Fusion-generated speeds (e.g. when you want to do a quick test "in the air").

Sorry for that!
Best,
Johannes

Hello,

The forum is fine, thank you for pointing that out!
I've implemented that rrequest (http://forum.robotsinarchitecture.org/index.php/topic,903.0.html) and must have messed up somewhere. However the problem seems to be fixed on my end.
Do you need that component urgently, or just out of interest?
I may be able to send you an early release if it's urgent.

Performance-wise I couldn't give you a clear answer,  Dynamo definitely has got the slower 3D viewport than Rhino, so things seems a bit sluggish at times. Componentwise the 3D rendering is quite different, so there can also be difference. KUKA|prc wise it's the same logic, so there shouldn't be huge differences.

Best,
Johannes

Hello,

There are a few things you can try, you already mentioned setting $APO.CDIS, however note that the highest value will be half the point distance - so if your points are closer than 40mm, your 20mm won't really have an increased effect.
If you want constant speed, consider setting the movement to C_VEL and using a high $APO.CVEL value (oercentage).
Also you could try using a spline movement, though I'm not really a fan of it.

However, the main issue is probably the A4 turning, which means that you are probably close to a singularity, i.e. the robot is stretched, in your case likely with A5 close to 0.
If you have a symmetrical tool like a pen or a milling tool, then rotate the planes around their tool axis, e.g. with the Orient Plane component. Alternatively change the position of your toolpath if you can, e.g. moving it up or down in relation to the robot.

Best,
Johannes

[KUKA|prc for Dynamo - Preview]

KUKA|prc for Dynamo - Preview



We are proud to present a public preview of KUKA|prc for Autodesk Dynamo. To encourage testing, we are providing a full-featured license of KUKA|prc to everyone, with a license valid until March 31st, 2019.  The current release is optimized for Dynamo Studio 2017 (Dynamo Core 1.3). Dynamo is available as a free evaluation software.

When testing the software, please expect problems and issues. We are kindly asking you to provide feedback through the forum!

KUKA|prc for Dynamo - Installer: http://robotsinarchitecture.org/wp-content/uploads/2018/10/KUKAprcDynamo_20181018_PublicPreview.exe
KUKA|prc for Dynamo - Tutorials by IP RWTH Aachen: https://www.ip.rwth-aachen.de/teaching/dynamo-tutorials/
KUKA|prc for Dynamo - Additional Sample Projects: http://www.robotsinarchitecture.org/wp-content/uploads/2018/10/KUKAprcForDynamo_Samples.zip

Following the testing period, KUKA|prc for Dynamo will be made available as a free version with reduced functionality and a full version for all members, in parallel to the Grasshopper version at no extra cost.

Hello,

Are you using it with KUKA|prc or another software?
In any case, the error message tells you that there wasn't any communication happening for over 3 seconds.
Reasons for that may be a bad/overloaded connection (e.g. via WiFi), or possibly problems with the network cable or network adapter.
You could also take a look at the Task Manager if e.g. your PC's load is very high.

You could increase the timeout value in the mxA configuration, however 3 seconds is already very long, so I wouldn't really recommend that.

Best,
Johannes

Yes, sure - the early times! I need to ask David sometimes if there is any particular reason it's called Grasshopper... Never thought of that ;)

If you disable the speed coming from Fusion, it will work like LINear movements without a speed value, i.e. it will take the previous one, which is often the default value defined in the settings.
What I could do is replace the "Toggle Feed" Boolean input with a number input for "Override Feed" (i.e. if you provide a value there it will override the programmed speed values), thus keeping the number of inputs the same.
Would that work for you?

Best,
Johannes

Hello,

That is actually what should be happening, and in my tests it just worked.

For example at the end of the XML file I've got...
<linear5d to='-199 -0.01 2.039' normal='-1 0 0'/>
<arc dir='cw' to='-200.6 -1.61 2.039' center='-200.6 -0.01 2.039' normal='-1 0 0' feed='2000.000'/>
<rapid5d to='-215 -1.61 2.039' normal='-1 0 0'/>

...which translates to...
$VEL.CP=0.03333333
LIN {E6POS: X -199, Y -0.01, Z 2.039, A 0, B 0, C -105.953, E1 0, E2 0, E3 0, E4 0} C_DIS
CIRC {E6POS: X -201.731, Y 1.121, Z 2.039, A 0, B 0, C -105.953, E1 0, E2 0, E3 0, E4 0},{E6POS: X -200.6, Y -1.61, Z 2.039, A 0, B 0, C -105.969, E1 0, E2 0, E3 0, E4 0} C_DIS
$VEL.CP=2
LIN {E6POS: X -215, Y -1.61, Z 2.039, A 0, B 0, C -105.969, E1 0, E2 0, E3 0, E4 0} C_DIS

And you can override the speed by disabling the speed toggle. The postprocessor does not differentiate between the different movements, though, so you cannot batch-process those speeds, except by search/replace on the XML file.

Best,
Johannes

Hello,

Changing the base is currently not supported as we never saw it as a high priority. But I've now also come across a few projects that would have benefited from it.
I'll put it to my todo list!

Best,
Johannes

Hello Pete,

Nice project!
What I did to make it work was the following: You work in the "back" of the robot, so there really isn't a way to avoid A1 problems. So what I did is set the posture of the robot to "101", which has the robot "flipping over".
However, then the height is more limited due to the limits of A2, so I had to lift up the position of the wooden elements.
Also, when flipped over the reach is less, so I had to adjust the maximum distance of the rail in the settings.

So now the main thing to optimize via Galapagos could be the position of the rods. If you cannot adjust their position "physically" as freely as I did in the digital simulation you could put in constraints, so that e.g. Galapagos moves it only within the range that is possible.
That being said, you're probably quicker doing that by hand.

Best,
Johannes

Not with a six-axis robot as you do not have the required redundancy.

If you put the robot onto a rail (= 7 axis system), you could e.g. move the rail in a way that there is minimal A1 movement.
With a 6 axis robot you can just lay out the frames in an efficient way that improves reachability and reduces A1 movement. But there is no standard strategy or pattern you could use - that very much depends on what you are using the robot for.

Best,
Johannes

Hello,

I haven't come across any GH plugin that would do that for you in a reliable way, as those strategies are quite complicated and also do not fit that well into the GH way of programming.
Don't get me wrong, it's definitely possible to create milling strategy for individual use cases in GH and you can save great amounts of time through mass customization opposed to CAM software. But there isn't a script that will work well for "all" geometries, like in CAM software where you define the stock, the geometry, set a few parameters and get a working solution.

For "generic" CAM work we usually use Fusion 360, as it has got a nice interface and doesn't cost much (free for EDU). There is a Fusion 360 component in KUKA|prc, you can right-click it to export a postprocessor. Code generated through this PP can then be imported into GH and e.g. combined with your parametric geometry. Note that you need an additional "orientation" point as you get 5-axis G-code out of Fusion, that does not define the rotation around the tool axis!

Best,
Johannes