Recent Posts

Pages: [1] 2 3 ... 10
2
I'm glad you enjoyed it! I understand what you mean. Any interesting projects I will post :) I like sharing and exchanging ideas or tips and tricks
3
General Discussion / Re: Cycle time?
« Last post by Nicholas Ziglio on April 02, 2020, 05:39:19 PM »
Wow, that is so kind of you! Would be great  :D
I just sent you an email :)
4
General Discussion / Re: Cycle time?
« Last post by Johannes @ Robots in Architecture on April 02, 2020, 12:22:09 PM »
Hello Nicholas,

I can provide you with a temporary license to get you started and then we can talk about further steps, OK?
Please send me an eMail!

Best,
Johannes
5
Hello Nicholas,

Thanks a lot for sharing, it's great to see what you've done!
Often there are questions on the forum and via eMail and you never know what projects come out of it, so your update really appreciated!

All the best,
Johannes
6
I thought some here might be interested by a couple of things I have done in this project.
I managed to automate the detection of new objects and have the animation display the picking of them.
I also used some python and machine learning to help the robot avoid collisions and optimize the picking and placing of components. I hope you enjoy. Feel free to ask any questions about it ;D

Thanks a million to Karl Singline for his youtube tutorials and Johannes for the amazing dedication and support on this forum!

https://youtu.be/v_jviyzkvs8
7
General Discussion / Re: Cycle time?
« Last post by Nicholas Ziglio on April 01, 2020, 06:54:04 PM »
Thanks, I'll have to make do with the analysis time then for now ;D
Would there be any way for undergrad students to earn a member version through contributions to the project?
8
General Discussion / Re: gcode import to PRC
« Last post by Johannes @ Robots in Architecture on April 01, 2020, 10:22:39 AM »
Hello,

The problem with G-code is that it's not universal, even if there are standard for it.
We initially developed the G-code import for SprutCAM and then added a specific import function for Fusion 360. The latter needs a custom postprocessor, which you can get by right-clicking the Fusion component.
The G-code for 3D printing was tested with Autodesk NetFabb, though it should also work with other software.
I've attached an example. A core aspect is how you want to drive your extruder. There are three options for the Extrusion Mode input..
If you enter E1, E2, etc. the extruder value from the G-code will be mapped to an external axis.
If you enter D1, D2, the code will toggle a digital output whether the extruder is on or off. You lose the speed information.
If you enter another string, it will map the value to a variable, which on the robot needs to be defined in the $config.dat. You could then e.g. scale that value and map it to an analogue output or something like that.

Best,
Johannes
9
General Discussion / gcode import to PRC
« Last post by sledzionac on March 31, 2020, 07:50:36 PM »
Hi everyone,

We finally got approval to purchase the full version of PRC from our school as we have developed a clay extruder for 6 axis printing. While we have been generating our own toolpaths through grasshopper, we were curious if anyone has been using Slic3r or any other standard 3D printing gcode generator to create toolpaths for the robotic arm to interpret. We were very interested once we saw "gcode import for 3d printing" in the list of commands, but weren't sure how to use it. From my understanding you need to have a custom post-processor written to generate gcode that will be compatible with this feature. Does anyone have any resources or know where to find a post processor that's already been written? I understand that MasterCAM has already done this, but we don't have access to this. While we do have access to Fusion, it was giving me errors when trying to convert gcode for 3d printing.

Thank you in advance for any help or insights you can offer.
10
General Discussion / Re: Cycle time?
« Last post by Johannes @ Robots in Architecture on March 30, 2020, 08:58:27 AM »
Hello Nicholas,

You can get the calculated time in the community version by looking at the end of the simulation graph (Settings/Analysis). In the member version you can also access it in Grasshopper via the Analysis component, e.g. for optimization.
If the simulation gets laggy, consider turning off the target frames so that only the toolpath is displayed.
However, take under consideration that KUKA|prc calculates the time based on distance / programmed speed, so it does not take acceleration and deceleration under consideration as those are not published for all robots. Depending on your toolpath this can be either a small or a very big difference. I mostly use the time for relative optimization, i.e. lower time is better, but you couldn't use it to finetune a choreography or something like that.

Best,
Johannes
Pages: [1] 2 3 ... 10