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

#61
Hello,

The Multi-State Tool is mostly for visualization and some IO convenience. If the gripper has got its own library for operation, I would try to hack that into the Java file. So that rather then setting an output in an IOGroup, you toggle the gripper.

Best,
Johannes
#62
Support / Re: Handle large files with PRC
August 07, 2024, 04:03:45 PM
Hello,
When we got started in 2009 we used KUKA CamRob which could process CSV or BIN files, but that doesn't exist anymore. Something similar is possible with the OrangeApps PointLoader, which is pretty affordable, in my opinion, and works with KUKA|prc.
The "best" (but most expensive and by far hardest to integrate) solution would be KUKA.CNC which comes with its own pathplanner that is optimized for CNC applications. So while PointLoader is basically the same as running the KRL file (with problems when the path is spaced too tight) KUKA.CNC improves upon that.
We can also generate KUKA.CNC G-code from KUKA|prc.
Best,
Johannes
#63
Support / Re: MacOS KukaPRC Alternate Code Generation
August 01, 2024, 07:39:07 PM
Hello Jason,

As you wrote in the email, the HL component only shows up with your license installed. I'm pasting that here as well, in case it helps anyone!

"In GH, go into File/Special Folders/Component folder which should open a Finder window, go into KUKAprcGH and place the license file there as KUKAprcLicense.json (without the university name). Then restart Rhino and it should work!"

Best,
Johannes
#64
Support / Re: Connection with the stepper
July 29, 2024, 11:40:01 AM
Hello Michal,

There are many ways as you have already outlined them. In our work, we added a simulated external axis to the robot, set the extrusion value as E1 and then had a program running on the robot that would send the current E1 value to the stepper. However, you need to ensure that the stepper can follow that fast enough as you are sending absolute position values. You could also get the current speed of E1 and send that to the stepper, which avoids some problems, but at the expense of accuracy.

With an analogue output you can theoretically encode like 16m positions (assuming 24bit) but you will have to cope with signal problems etc. Coupling digital outputs into a signal might be easier.
You could consider getting an EtherCAT Arduino shield, that way you don't need many cables.

And yes, you would probably set the parameters via a Custom KRL component. You'll need to make sure that the values are set in the advance run so that the robot doesn't stop whenever your values change.

Hope that helps you get started!
Best,
Johannes
#65
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
#66
Thank you! My email is johannes@robotsinarchitecture.org, let's continue the conversation there!
Best,
Johannes
#67
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
#68
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
#69
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
#70
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
#71
Support / Re: Custom Variables
July 16, 2024, 01:41:31 PM
Excellent, thanks for the update!

Best,
Johannes
#72
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
#73
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
#74
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
#75
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