3D printing robot

Technically, any extruder should work. The trick will be keeping the extruder speed matched to the robot speed -- even an Agilus is going to have longer accel/decel ramps than your average desktop 3D printer. You're going to need to generate the robot's realtime TCP speed as an output to the extruder speed control, and do a fair amount of tuning. You'll also need to set up the extruder tip as a very precise TCP. If you can avoid orientation changes during printing, all the better. Backlash compensation will be... interesting.

Well, your average slicer outputs G-Code, usually made to the loose RepRap standard. So what you need is a way to convert G-Code to KRL. I've dabbled in writing a parser that would convert simple G-Code to KRL, but never really took it very far.

There's the KUKA.CNC option package, which I haven't used, but I've been told that it allows a KRC4 to run G-Code natively. I'm sure there's some caveats on that, but it's something to look into. I think the tricky bit would be coordinating your extruder, since most G-Code in industry is intended for milling spindles, which don't normally change speed dynamically during a cut path.

I don't have any direct experience with PowerMill or its alternatives, so I can't speak to them very well. I've heard good things about the Grashopper&Rhino combo. Search the forum archives for posts by "neeboy" -- as I recall, he had some luck with this on an old KRC1.

One issue will be coordinating the extruder -- aside from the fact that you'll need each motion step to coordinate with a set amount of extruder motion, you'll also have to handle the accel/decel ramps. In regular 3DPs, the former is handled by the slicer, and the latter is handled by the machine-specific firmware.

Robots also prefer sparser motion files than CNC/3DP machines. The former want a small number of points, filling in the paths on their own, while the latter generally run on a very large number of very small motions. One of the main things a converter has to do is smooth out this profile -- just converting G-Code into an equal number of robot motions tends to create very herky-jerky motion.

I just picked up an extruder from these guys:

http://www.micron3dp.com/

using a fieldbus stepper motor driver(IE beckhoff EL7041/7021), and as skyefire said, matching output rate to robot velocity is key. I am doing this in external PLC, but I am confident you can do it in the SPS as well. RSI might help make it smoother as well. There is a pretty good example of an agilus doing this in a project at Kent State University. We are also using a large servo controlled(bak-dohle brand) one on a KR120. Its not going to give you perfection like a gantry machine, but there are many more interesting possibilities that the robot opens up(not just layer based structures, but 3d....)

wes_mcgee - what is the output diameter of your extruder?

as mentioned one software package that costs (it will probably set you back a small fortune) is Kuka.CNC, then you can execute G-code natively on the robot.
in general G-code is very simple, it is just text file with plain syntax. actually even though it is called "G" code, it is not only "G"-code, there is bunch of codes (N, M, G, F..). each of them can have many options.
https://en.wikipedia.org/wiki/G-code

G-code is used to convey positional data and offsets, this can easily be written directly into motion commands
F-code is information about feed rate (hence affects velocity).
M-code is used to do miscellaneous functions such as tool commands, etc (used to control outputs, change tool and base for example)
N-code is line block information (used when looping)

So if you are skilled in string manipulation in whatever language, you can write your own translation utility what will translate G-code to KRL.
or you can create own G-code parser in KRL as well

Quote

my issue now how to make those gcode coverts to krl. or any software that we can use know even if it cost a price.

RobotWorks www.robotworks-eu.com is a SolidWorks Add-On program which has a purchased option for 3/5-Axis CNC Import. It will take a G-Code CNC program and produce a robot path program from it. KUKA program format is supported.

I am also told that the next release will have some type of support for 3D Printing applications, but I don't know much else about it. I suspect it will be import an .STL file and produce a robot path program....maybe. Don't know much.

Quote from vvelikov

wes_mcgee - what is the output diameter of your extruder?

The micron3dp one comes with 0.4-0.8, though I think I may drill it out a bit. We also have a bak-dohle with 4-5mm and a large one with 8mm. I am going to put a reducer in the larger one to shrink it down a bit. Typically the plastic expands as it comes out, so it makes a pretty large bead that takes a long time to cool at that size.

@emben:
here is the link to simple software for visualizing and converting g-code to KRL: https://cloud.mail.ru/public/e8699d1ab99b/WLRC.rar
link fould here: http://робот-н.рф/solution
Unfortunately it is in Russian language as the author is a russian - may be he will translate it in english if asked?
Anyway it is pretty simple to use and i am sure that you will figure it out and best of all - it is FREE to use

I've been testing out roboDK recently. Not yet well known. But it's free and from what I understand it can deal with G-code.
It works on Mac and PC, it's in english it's a good milling software too, very easy interface to use.

Have a look here: http://www.robodk.com/examples.php

Hi,

this was made with an Agilus.

regards

Quote from Toolsoft

Hi,

this was made with an Agilus.

regards

Hello How are you I am walking the same path of all you, we want to print furniture in a real scale using a robotic arm as a huge 3D printer, in our lab there is an KUKA kr16 (KRC2), I wonder if you can elaborate bit more about your setup, how did you communicate the extruder with the robot, where did you embedded the Logic of the Controller ?. we are having hard time for deciding the reliable and easy route to follow. our naive Idea was to use the Ramps for driving the motor and keep the PID in the extruder, creating a a routine for communicate the robot and the extruder. if anyone give me a inside I will be very grateful

The root issue here is going to be the same as creating any 3D Printer from scratch: keeping all the axes (including the extruder) fully synchronized. With a robot, keeping the arm axes synchronized is handled by the KRC, but keeping the extruder synchronized to the robot arm becomes more complex.

The key is going to be control of the extruder motor. You're going to need a stepper motor controller, something big enough to handle an extruder on the scale you're talking about (I don't think a NEMA-23 stepper will handle loads on this scale). But the stepper controller has to receive orders for direction and speed, and these orders will have to be synchronized with the robot's motion.

What's going to make this difficult is that the robot's TCP velocity is constantly changing -- acceleration and deceleration ramps, axis speed limits, singularities, and so on. You will need a means to tie the robot speed to the speed of the extruder motor, in real time. You can probably do this through the SPS, although live analog output of $VEL_ACT is another possibility.

But before any of that, you need a means to connect the stepper driver to the KRC. This is going to depend on the stepper driver you end up using. Probably the simplest interface, for a stepper driver similar to the Pololu-type drivers used on RAMPS, RAMBO, and other 3DP boards, would be a Fieldbus multi-bit dry-contact (relay style) output device. Which one you would need to buy would depend on what your I/O options on the robot are. KRC2s come with DeviceNet included, and you can buy simple DeviceNet slave modules and connect them easily enough, but since your KRC2 is second-hand, it might have some additional Fieldbus options installed. You'll have to investigate that yourself.
Using the standard Pololu AMIS driver as an example, it takes 12 control inputs, so you would need a 16-output Devicenet slave module -- I've always been partial to the Turcks like these: http://www.clrwtr.com/PDF/TURCK/TURCK-DeviceNet-Stations.pdf
You'll probably also want an 8 or 16-bit input module for feedback, and some analog input modules for getting back the extruder temperature.

I have KRC2 and the following stepper motor: http://www.bzt-cnc.de/en/shop/…-schrittmotor-fl60-42a-3n

Which steps would you suggest to connect it to the CombiCon DeviceNet port at the MFC card?

You're jumping a few steps, here. First,, you have to decide on the stepper motor controller you are going to need. That will depend on the amperage and step requirements of your motor, and the speed at which you expect to need to drive the motor to achieve your target extrusion rates, whatever they are.

After you select a stepper controller, you will need to look at its interface control options before making the determination of your I/O interface.

Thanks for the response!

We have a Powerlolu Stepper Motor Driver, which is currently controlled by Arduino.

Do you have experience in connecting this driver directly to DeviceNet on KRC2? Or would you suggest to use Arduino and trigger it through the CAN High/Low signal in DeviceNet?

i don't think you are going to see much experience in mixing industrial and hobby products...

Hobby products use lower signal voltages, signals are meant to cover only short distances and are not nearly as immune to interference (unless explicitly conditioned by particular design). Absence of conditioning allows to use fast signals for things requiring pulse trains for example (either step control or PWM). if needed MCUs can generate pulses that go all the way into tens of MHz.

Powerlolu is using Allegro chip A4989, it is just beefed-up version of Pololu stepper.

Industrial products are generally using I/O that are conditioned (protection, filters) at a cost of update time. This is NOT a downside, it is design feature (trade off) allowing long wires in noisy environment. Usually response time of industrial I/O is on the order of 5-10ms. When faster signals are needed (normally positioning applications), special I/O are used (high speed counters, pulse train outputs). But robot is using its own drives and feedback for positioning so you don't get high speed I/O on the robot (except the fast measure inputs). In addition to the mentioned I/O filters, there is also DeviceNet update time and KRC interpolation cycle. In short, this is good to turn on/off relay, lamp or solenoid but it is by no means meant to produce fast signals suitable to drive stepper drives.

PLCs (specially small ones) often have few high speed I/O that can run up to some 100kHz for example. Larger PLCs may have faster inputs avaliable (say up to 1MHz or similar) which allows using high resolution encoders.

you may want to minimize interaction between robot and arduino to simple handshaking, but ket arduino handle fast signals (unless your stepper is going to mover very slowly).