>I am thinking here of users running the code on an existing CNC machine with an extruder attached.

How does that work exactly? How do the non standard codes thet control the extruder speed and temperature actually get to the extruder if you are using an existing machine?

---

[www.hydraraptor.blogspot.com]

blerik: i'll add that in for sure. good work.

ian: thanks for the suggestions, i'll try and implement them

nophead: they'd have to figure that out themselves. one easy solution is to use the arduino electronics with their existing CNC machine. nobody has done it yet, so we cant give you an exact example, but the potential exists.

also, its important to implement them as custom commands, so that someone could use this as a real CNC controller if they want. for example, i'm going to try and use my mcwire machine as a PCB router and it would be nice to be able to use all the pre-existing Eagle -> GCode converters.

Zach,
So what does making the comms to the machine G code actually achieve? You still can't drive an existing CNC with RepRap without replacing the electronics. You can't drive RepRap with an existing CNC control program because they accept G code and output it on a parallel port, they don't send it down a USB port.

You can feed G code files like those from Eagle to your machine but it is a lot easier and more flexible to parse those on the PC and output via the RepRap host bot interface as somebody has already I think. That has the advantage of working on the old and new electronics.

---

[www.hydraraptor.blogspot.com]

Hi Nophead

Most CNC machines have PLC interfaces these days. M functions can be trapped & acted on in the PLC. I have a small machine that will shortly have a common interface to both the single Arduino and a PC based CNC using 2 parallel ports. I believe I can set up the CNC to provide temperature control using a spare analogue or PWM output.

The advantage to me is I can use a single 3 axis system for both replicating and milling. Initially I was concentrating on making it a pluggable switch over and that may well be the way to go. However the G code option allows me to use acceleration and deceleration with the drives and the possibility of using servo drives. Plus the CNC has full jogging and other controls for setting including MPG which is a boon when setting the Z axis. I have also used the CNC for many years and very familiar with it.

---

Regards

Ian

nophead Wrote:
-------------------------------------------------------
> Zach,
> So what does making the comms to the machine G
> code actually achieve? You still can't drive an
> existing CNC with RepRap without replacing the
> electronics. You can't drive RepRap with an
> existing CNC control program because they accept G
> code and output it on a parallel port, they don't
> send it down a USB port.
>
> You can feed G code files like those from Eagle
> to your machine but it is a lot easier and more
> flexible to parse those on the PC and output via
> the RepRap host bot interface as somebody has
> already I think. That has the advantage of working
> on the old and new electronics.

Listen man, not everything has to be the absolute perfect solution.

GCode fills a missing niche in the RepRap technology. There are quite a few pieces of technology out there that generate gcode. Creating a basic gcode parser on the arduino is possible, and mellery and blerik stepped up and made it. It works well, and it can get the job done. Would you prefer I slap blerik in the face and tell him that I only want perfect solutions? No, I want to print and if someone brings me a solution that is one step closer, I'll take it. Plus, these are nice guys.

Is it the best route? probably not.
Will it be able to handle every gcode known to man? hell no.
Does it do a satisfactory job and allow people to quickly use gcode on their reprap machine? yes.

I'm not entirely sure what the alternative you want is. The current version of SNAP cannot handle all the commands that gcode can do (even our limited version of gcode). for example, feedrate and 3-axis DDA moves. what you're proposing (parse gcode on the host) means that we have to come up with a completely new host communication protocol. that in and of itself is a huge undertaking.

Nobody is saying that this is the ultimate reprap solution. People here have a desire to be able to use gcode on their reprap machine and they are implementing it in a way that doesnt require drastic changes.

This firmware is *only* for using gcode on your reprap machine. Its not for driving other CNC systems, nor for use with other CNC applications. Its not designed for that and to bring it up its ridiculous.

If you have a better way (that people can easily replicate... no "i found this piece in my junkbin"), please show us, document it, and prove it works. Until then, please let us get back to work.

"If you have a better way (that people can easily replicate... no "i found this piece in my junkbin"), please show us, document it, and prove it works. Until then, please let us get back to work."

Whoa! Little harsh there.

"So what does making the comms to the machine G code actually achieve?"

sorry if i reacted strongly to that. all i really mean was that if you are going to criticize peoples work, you better have a solution or an alternative to back it up.

in addition to that, we're going to great lengths here to build something that *everyone* can build. if that means doing surface mount stuff, expensive stuff, or using hard-to-get parts, then it doesn't help much.

sorry if it was seen as personal, but it really wasnt. i respect and admire nopheads work alot. infact, i've adopted some of it in the arduino, and am subscribed to his excellent blog.

> Will it be able to handle every gcode known to
> man? hell no.

well my newest version comes pretty close, though i updated to hardy and that did bad things to java and gcc-avr... gotta fix that first

I've placed some python code in svn at trunk/users/vasile/stl2gcode. It takes an stl file, converts it into povray format, slices it into png-formatted layers and then outputs gcode for each layer.

You'll need stl2pov to make it work. I built a .deb file if anybody needs it.

I haven't tested it on a physical object because I haven't finished my reprap yet.

But, I'm fairly sure it's deficient in a few areas: (1) I haven't done any scaling, so objects will be stretched or squashed along all axes. (2) I haven't delved into the gcode, so I imagine that needs some serious tweaking.

The good news is it slices and produces gcode. Personally, I don't want to make stl files in AoI. I want to describe things in python or lisp or perl and have a program generate pov files. This code is a step toward making that feasible. Code is GPLv3. Patches most welcome!

Just throwing this out there: I wonder if it might not be simpler to adapt an existing open source Gcode generating program, instead of writing our own? One such seems to exist: [gcam.js.cx] , although it will require some degree of extension (probably not too much) to add support for thermoplastic extrusion machines such as the reprap as well as the CNC mills it currently supports.

Quote

I wonder if it might not be simpler to adapt an existing open source Gcode generating program, instead of writing our own?

This would of course be the best solution, but I think it is reasonably safe to say that if this *could* be done, it *would* have been done.

Our particular needs (slicing and dicing) are sufficiently different from the way you'd run a milling machine that it will probably take more than a a small extension to make it work. Once you've made the software break the model down into layers and generate useful infill, you've done most of the work to writing your own CAM system anyway.

Indeed, it could forseeably take a little longer, as you'd need to learn and adapt someone else's code; seldom an easy task

Am I missing something, or does skeinforge pretty much fill the requirements Zach was asking for here?

I was thinking the same, though I haven't read what zach was asking, just the last few posts here. all nopheads parts have been made with skeinforge, which are indisputably the best objects anyone has printed.

(Expanding on another reply)

I'd be glad to share my 20+ years of GCode use.
Absolute Vs Incremental positioning is simple but the difference can be devastating....

Incremental means to move a given distance. x1 means move one unit
Absolute means go to that position...x1 moves to position x1 from wherever your at now.

Absolute is like "go to the oak tree" while incremental tries to get you to the oak tree with "go north 3 steps, now east 4 steps"

Incremental programming is very dangerous. Make a mistake and every move after that is in the wrong position. Absolute is self correcting and only the move in error is effected.

Look at
[www.raczynski.com]