Functional Workflow of a reprap?

What gets transferred from the PC to the reprap?? Is that g-codes? Does that mean that g-code files can be shared? It looks like stl files are shared, not g-code. Maybe that is because the stl files allow for easy modification of part position on the build tray.

Does the arduino process the g-code into x,y,z motion and plastic flow?

Is the CAD-like front end responsible for generating the g-codes, or whatever data gets transfered to the reprap?

The reason I ask is that I work with a lot of CAD packages, and I would love to try porting the g-code software from reprap into an open source add-on for one of these CAD packages that has a great API. That way I could, effectively, add a 3d print button to this CAD package. The CAD package I am thinking of has a better 3D environment than the one in the reprap software.

The add-in would insert the reprap's build envelope onto a CAD model and then utilize the CAD software's ability to do a draft check to make sure the model is buildable by reprap.

I am looking forward to building a reprap soon. Well, maybe a repstrap soon.

Quote

What gets transferred from the PC to the reprap?? Is that g-codes?

Yes.

Quote

Does that mean that g-code files can be shared?

No, because different machines have different nozzle sizes, different possible layer thicknesses and a few other varying parameters.

Quote

Is the CAD-like front end responsible for generating the g-codes, or whatever data gets transfered to the reprap?

Currently, there are about five different toolpaths to get from STL to GCode: [forums.reprap.org]

There's nothing stopping you from crafting a "Print" button for your CAD application of choice, though. You just have to add a parameter file for each individual machine.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

CrawlerLogger Wrote:
-------------------------------------------------------
> What gets transferred from the PC to the reprap??
> Is that g-codes?

Yes on Mendel.

Does that mean that g-code files
> can be shared?

They can for identical machines extruding identical plastic, but in practice everybody has there own preference for filament diameter, speed and temperature, etc.

>It looks like stl files are
> shared, not g-code. Maybe that is because the stl
> files allow for easy modification of part position
> on the build tray.

STL specifies the shape but not how to make it so by sharing STL people can chose to print in whatever resolution and plastic they want.

>
> Does the arduino process the g-code into x,y,z
> motion and plastic flow?

Yes.

>
> Is the CAD-like front end responsible for
> generating the g-codes, or whatever data gets
> transfered to the reprap?

No CAD programs produce the STL. The Reprap host, Skienforge or one of the many other slicing program convert it into g-code. There are lots of ways to slice an object, different infill densities and patterns, etc.

>
> The reason I ask is that I work with a lot of CAD
> packages, and I would love to try porting the
> g-code software from reprap into an open source
> add-on for one of these CAD packages that has a
> great API. That way I could, effectively, add a
> 3d print button to this CAD package. The CAD
> package I am thinking of has a better 3D
> environment than the one in the reprap software.

The g-code creation is best as a separate program so you can use any CAD program you like and any slicing program you like.

>
>
> The add-in would insert the reprap's build
> envelope onto a CAD model and then utilize the CAD
> software's ability to do a draft check to make
> sure the model is buildable by reprap.

Not a massive benefit as it is trivial to check if an object fits the build envelope by looking at its dimensions.

>
> I am looking forward to building a reprap soon.
> Well, maybe a repstrap soon.

Edited 1 time(s). Last edit at 06/18/2010 02:59PM by nophead.

---

[www.hydraraptor.blogspot.com]

So if gcode is sent to the reprap, it should be easy to use an alternate controller for the reprap??

Also, whatever controller is used should also be able to control other build platforms, such as a cnc router, or larger rapid prototyper, right??

Does that mean that the electronics are identical between the reprap and the makerbot??

Quote

So if gcode is sent to the reprap, it should be easy to use an alternate controller for the reprap?

Several different flavours of controllers exist already. Most of them are arduino-based, but not all.

Quote

Also, whatever controller is used should also be able to control other build platforms, such as a cnc router, or larger rapid prototyper, right?

As already said, gcode is specific to each machine, each toolhead and each tool used. BTW., what's the "controller" for you? Typically, "controller" means the small computer integrated into each machine.

Quote

Does that mean that the electronics are identical between the reprap and the makerbot?

I don't see a neccessary conjuction here. The gcode interpreter is implemented in firmware, i.e. a computer program, not in wires, resistors and transistors. That said, MakerBot currently uses a set of electronics almost identical to one of the options for the RepRap, IIRC. They're exchangeable.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

My preferred controller is any PIC from Microchip. I already have experience with them and equipment to program them. I suppose it wouldn't be too hard to switch to the atmel ucontrollers.

To clarify my question about the gcode sent to the reprap, are all the gcodes for a complete build session sent at one time to the reprap or is it one gcode at a time?

To clarify my question about the similarities between reprap and makerbot electronics. If I built one of these, could I build the other using the same motors and electronics. Is it just a matter of having the right config file for the hardware you have. Meaning that it doesn't matter what motor you use, or plastic you extrude, etc. so long as you do the calculations to setup the config so that the software knows it needs to step an axis X number of steps to move 1 inch, etc. And that you slice your model appropriately. ??? It seems that it could be abstracted that way.

Quote
CrawlerLogger
If I built one of these, could I build the other using the same motors and electronics.

Yes, but the MakerBot is not really a RepStrap machine, but you certainly can use it as one.
If you want to use it as such I would recommend purchasing separate Motors and Electronics and then selling the MakerBot.
That way you really can build a Mendel for the estimated price of $520 listed in the wiki!

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

I notice that the build documentation recommends using dual shaft motors, but I don't understand why? What is the second shaft used for? Is there plans to incorporate rotary encoders on the steppers at some point in the development? Or can motors with the shaft on only one side work?

Quote

Is there plans to incorporate rotary encoders on the steppers at some point in the development?

The beauty of steppers is, they don't need any rotary or position encoder.

Quote

Or can motors with the shaft on only one side work?

I've yet to see a situation in the RepRap world where the second shaft is actually used. Perhaps double shaft motors are recommended because they have the same price as single shafted ones.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Does it recommend dual shaft motors or just recommend a motor that has dual shafts?

At one time it was cheaper to get the dual shaft NEMA17's for Zapp Automation but I don't think that is true any more.

Motors with one shaft definitely work.

---

[www.hydraraptor.blogspot.com]

I saw a entry for a Dual shaft stepper (as in one shaft but it comes out both sides as a means of enabling the shaft to be gripped for filling down without putting any stress on the stepper motor itself. However I have not seen any use of the extended shaft

David