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

#1
Hello,

We had such solutions, I believe Tongji University had a gantry setup that we initially supported. We have users with two external axis (X, Y) which works fine, I think with Z it was a bit hacky.

Best,
Johannes
#2
Thank you! My email is johannes@robotsinarchitecture.org, let's continue the conversation there!
Best,
Johannes
#3
Hello,

As far as I remember - for some reason I don't often use analog outputs - you set the value in a normalized fashion as you observed and it scales it to the appropriate values by itself.
So with a 0-10V analog output 0 is 0V and 1 is 10V. I would definitely recommend to test it with a multimeter, though, just to be on the safe side.

Best,
Johannes
#4
Hello,

The netstandard.dll is no longer necessary in the more recent versions. Please download a more current release from the member section. As you don't seem to have access yet, I need to know which institution you are affiliated with, and then I will unlock your account!

Best,
Johannes
#5
Hello,

What do you mean by changing the library? I guess that it is looking for the folder location from my PC, so you will have to right-click the component and change the path to the KUKAprcGH library.

Best,
Johannes
#6
Hello Jesse,

From my perspective, I obviously love the software development aspects of robotics. However, developing a "universal" software as we're doing is tricky business-wise because the money lies in the applications. So my recommendation would be to develop tools that solve specific issues in specific industries and can therefore be sold for a lot of money.
Ideally, that would be for an industry that is relevant where you are living so that you can be there on-site, as for remote jobs, you are often compared with companies working out of low-wage countries.
Again, that is just the limited perspective from me and the people in my bubble.

Best,
Johannes
#7
Support / Re: Custom Variables
July 16, 2024, 01:41:31 PM
Excellent, thanks for the update!

Best,
Johannes
#8
Support / Re: Custom Variables
July 12, 2024, 10:03:58 AM
Hello,
What exactly would you like to achieve? The main purpose of a DAT file is a nicer separation of logic and variables (in my opinion, at least), so you could declare those variables also in the SRC file if that is needed. However, if the scope of the DAT file is global, you could access those variables also from your SRC program.
I am not sure how the Python script fits in here, does it generate the parameters for your printing process and saves them to a DAT file?
Best,
Johannes
#9
Hello,

There are a LOT of things here, I'm happy to help with the technical details but for the pathplanning you will have to be more specific.

1) A singularity is not necessarily terrible, usually the worst thing that could happen is that the robot goes into an E-stop due to excessive speed when (usually) A4 spins. I would not recommend using the Dynamic Value for a 2-axis positioner. I've attached an example (dkp_orientation.gh) that may be helpful for creating your own orientation strategy.

2) That's a very specific question that definitely needs a proper example, otherwise I would just guess what you are trying to achieve. I see what you mean with the inner and outer distances, but how to approach such a problem is very much up to your specific process. From your screenshot I'm assuming you are using additive manufacturing? So you could try to reduce the extrusion speed when the spacing is very tight.

3) An example for a custom DKP is included (customdkp_2.gh). We don't support it by default, so a scripting component is needed and you may have to adjusts the paths to the KUKA|prc libraries.

Best,
Johannes
#10
Support / Re: plane to frame with python for prc
July 02, 2024, 07:54:43 AM
Hello,

I sent the reply a bit too quickly yesterday because there are some extra steps. Internally KUKA|prc works with a different Plane definition, and the resulting commands also need to be formatted for GH. So generating a LIN movement with a plane would look as below:

            KUKAprcCore.Geometry.Plane ghPlane = KUKAprcGH.PRC_GH_Methods.PRC_GH_Methods.PRC_RHtoPRC_Plane(pln);
            KUKAprcCore.PRC_Classes.PRC_CommandData cmd = KUKAprcLibrary.PRC_Commands.PRC_LINMove(ghPlane, 1.0, "C_DIS");
            KUKAprcGH.PRC_IOClasses.GH_PRC_CommandData ghCommand = new KUKAprcGH.PRC_IOClasses.GH_PRC_CommandData(cmd);

An example made in Rhino 8 is attached!
Best,
Johannes
#11
Support / Re: plane to frame with python for prc
July 01, 2024, 05:51:04 PM
Hello,

Your Python code is only generating a string, so you could write that into a file and run it.
For KUKA|prc you need to bring it into a KUKA|prc component.
The easiest would be just to get the XYZABC values as doubles and plug them into a Frame component (or you do the three rotations yourself, the Frame component doesn't do much more).
To create a linear movement by code, use KUKAprcLibrary.PRC_Commands.PRC_LINMove(Plane pln, double velocity = -1, string interpolation = "C_DIS")Let me know if there are any problems!

Best,
Johannes
#12
Support / Re: plane to frame with python for prc
July 01, 2024, 07:39:54 AM
Hello,

In general the code "looks" plausible, but I guess that is the thing with AI-generated code, there could still be issues. Some things to consider are that KUKA|prc by default uses X as the tool-axis. Take a look at the "Frame - KUKA|prc" component, where you can toggle between the tool axes (also that option is in the settings if you want to use the Z-axis everyhwere). The second thing is that there are multiple ways to express the same coordinate system. So just because the ABC values differ, it does not have to be incorrect. So turn your ABC angles into a coordinate system and compare the coordinate axes.

Best,
Johannes
#13
Hello Chris,

That's weird, could you send me an example - ideally only baked planes, no logic or plugins - so that I can take a look?

Best,
Johannes
#14
Hello,
Before we go into any KUKA|prc details, please ensure that the turntable is correctly set up. To do so, calibrate an Offset Base with three points, enter a Cartesian movement mode, and jog the E1. If the robot moves along with the turntable (keeping its position in relation to it), we can proceed to KUKA|prc.
In your problem description with the bust, it's unclear what the problem is to me. Could you please provide some more details?
Best,
Johannes
#15
Hello,

You can switch the tool axis to Z in the settings if it annoys you. In general, using the X-axis makes the XY planes in GH easier to use.

But I understand that it's not an ideal solution in either way.

Best,
Johannes