EMC2 Based Repstrap

I'm wondering if there is interest out there in using an EMC2 controlled mill as a RepStrap? That's the course I'm taking and I realized there might actually be some general interest in some of my work.

The basic plan is this:

Build an extrusion head using the Arduino based hardware and attach it to the mill.

Write (read: hack together from existing stuff) some firmware for the Arduino that can control the temp, extrusion rate, and fan. The firmware will expect to be controlled via the serial port.

Write implementations of the various M Codes used by the G Code generating slice/dice applications. (Is there consistency here between Enrique's Skienforge and the "official" software back-end?)

Watch it go!

Seems simple enough... I suppose that means it will crash and burn.

----------

If there is interest I'm sure I could publish the Firmware and M Code implementations for others to use.

----------

An aside: Has there been consideration to using EMC2 as an official part of the project? Its a very mature motion control system and, if my assumptions are correct, is extensible enough to drive a RepRap.

Hi,

Good idea, I am interested! It could help a lot for people who are into subtractive prototyping to get into additive prototyping too.

BTW, why is there a need to write any implementations if the Arduino is already capable to read g-code?

Adam

Since I'm hoping to have EMC2 handle the motion (since it is already in charge of my steppers) I'll need to have the arduino running just the extruder and fan alone. Then, to get EMC2, who will be interpreting the gcode, to talk to the arduino I need to write implementations of the various m codes being used.

In other words, the Arduino won't be reading the g code.

Ok, got it now. Do not you think it would be easier to use original electronics to run steppers? Or do you need more then 2A for coils?

Because if you use the Arduino, there's no reason to use EMC2 at all.

EMC2, like the Arduino firmware, is a GCode interpreter which generates pulse trains to direct your steppers. I imagine there are various good reasons for this, not least because EMC2 is reliable and mature, well supported, various UIs, etc etc.

If I was building from scratch I'd use one of the already figured out platforms, yes; but I'm attempting to simply bolt-on the extruder to my existing cnc mill.

The idea is to provide a "rep-path" for those who already have a cnc mill/router.

Sounds brilliant. I'm trying to follow a path similar to you, and this development would be super useful.

I am assuming you realise you can't just feed the g-code from Enrique's programs, or the RepRap host (unless your machine is a Darwin and material is PCL or PLA), to EMC2 and expect it to work. You will need to parse out the paths and add machine control and then write out new g-code for EMC2.

---

[www.hydraraptor.blogspot.com]

Why can't I? As long as I implement the RepRap specific M Codes I think it should work.

EMC handles the interpretation of all the motion and will call out to my apps for the custom M Codes for extruder control.

What am I missing?

If your machine is the same topology as a Darwin and you use use PCL or PLA, then the RepRap host G-code will work but if your machine or materials are different you will have to be prepared to hack the Java.

For example, the RepRap host wipes its nozzle between layers. That would be completely different motion on a moving head machine compared to moving table.

I don't think Enrique's g-code has any details like head lifting on moves, nozzle wiping, etc, in it. Certainly the old version I am using doesn't.

I parse the g-code for paths and then add raft generation, nozzle wipes, different temperatures on different layers, fan control, etc, myself. It would be easy to convert that back to g-code of course.

---

[www.hydraraptor.blogspot.com]

I hadn't thought of the nozzle wipe. I'm hoping that the new ooze-stopper design will be the standard and I won't need to wipe. AFAIK that was the only special motion being generated so it will be really nice if I can forget about it.

Extruding and cooling both happen at the tool-head so I think that will translate just fine.

Raft generation, different temps, fan control, etc. are all things that should be controlled by the CAM software, IMO.

To draw an analog from the cnc milling world, the CAM software takes into account the type and dimensions of the material being used, the type and size of the tool being used, and combines that with various machining strategies to develop a machine specific execution plan for a given model.

The particulars of extrusion diameter and extruded material seem to be in the same category as the size and type of tool and type of material.

The raft generation, inter-layer cooling, extrusion temps seem to be like the various machining strategies.

Right now I think that what you have by combining Enrique's code and your post-processor is a CAM application as I've described.

Yes but the slicing is complex, slow and largely machine and material independent, which is why I want to keep it separate, and the rest is very simple but specific to machines and materials.

If I had to re run the slice algorithm every time I wanted to change the layer temperature I would never have made the progress I have done.

---

[www.hydraraptor.blogspot.com]

Right, the slicing should output an intermediate description simply because it is so expensive. I think we are in agreement on this point.

Slicing does have to take into account extrusion diameter, right?

Here is the workflow as I see it:

CAD -> STL

STL + Extrusion Diameter -> Sliced Intermediate

Material Data + Sliced Intermediate -> Final G-Code

The good news is that, given a standard extrusion diameter, we can pre-process into the intermediate format and move those representations around.

What I'd like to see is for Enrique's code to output the intermediate format and then we can create a finalizer that embodies the experience you've gained. i.e. Material specific temps and feedrates, raft strategies, etc.

These are the M-Codes I found digging around in Enrique's code. The categories are mine.

== Toolhead Control ==
M100 - Set extruder speed to P
M101 - Turn extruder on
M103 - Turn extruder off
M104 - Set extruder temp to P
M105 - Read extruder temp
(Add Fan Control here.)

== CAM Notes? ==
M108 - Set extrusion diameter.
M109 - Set extrusion width.
M110 - Set layer thickness.
M111 - Set infill bridge width over thickness.

== Commentary? ==
M112 (slice) - The skein has been sliced
M113 - Initialization is finished, extrusion is starting.
M115 - Indicate that a loop is beginning


I understand the toolhead control codes, but what is the purpose of the others?

I know some of the M Codes are used to communicate stuff to various parts of the tool-chain Enrique built. The question is more properly how do they fit in the workflow I laid out? And do any of them need to be implemented in EMC?

Edited 1 time(s). Last edit at 05/21/2008 02:02PM by brendanjerwin.

= The Plan =

== M Codes ==

Unless I learn something new about the M108+ codes used by Enrique, I think this is the list of M Codes that will need to be implemented in EMC/new firmware:

M100 - Set extruder speed to P
Will instruct the Firmware to maintain a given feedstock mm/min. (NOTE: this is different from the meaning here: [reprap.org])
Firmware will have to know motor RPM and mm/rotation.

M101 - Turn extruder on, forward

M102 - Turn extruder on, reverse

M103 - Turn extruder off

M104 - Set extruder temp to P

M106 - Fan on

M107 - Fan off

(I'd like to get some consensus and standardization around the various M-Codes. How do we accomplish that?)

== Arduino Firmware ==

Steal a lot of stuff from the existing firmware. Build serial communications protocol to talk with the host applications.

== HAL Driver ==

In addition, a user-space HAL driver will be developed that will provide the following to EMC:

- Current Actual Extruder Feed Rate
- Current Actual Extruder Temperature
- Various Faults (I think these can be "wired" to the e-stop in EMC.)

(Since this will need to access the same serial port the M-Apps write to I think this stage will require that the M-Apps and the driver both speak through some sort of daemon that will own the serial port.)

== Control Panel ==

A pyvcp (Python Virtual Control Panel) which will display the outputs from the Driver. This can be nicely integrated into Axis.


Arduino / EMC integration already done: [axis.unpy.net]

Hi Nophead,

Indeed the latest skeinforge chain still does not have head lifting on moves, nozzle wiping or a raft.

The features since the beanshell version include multilayer shells, in other words adding extra perimeter layers. Also filling in the direction of any bridges on a level. Combing hair around holes. Adding diaphragms every so often across the whole shape, in other words making some sparse layers solid. Stretching the filament in the opposite direction to the expected contraction. None of this should break code working with the old skeinforge, and any of the new stuff can be turned off

brendanjerwin,

Indeed the M100 through M107 codes are the same for skeinforge and reprap, and if they aren't I'll change the skeinforge code. My plan for standardization is to follow the reprap machine M codes whenever I see them described. Codes M108+ are skeinforge specific and you made a good implicit point that we may need new machine codes, so I'm going to increment all the skeinforge specific codes in my next release by twelve, so that they'll start at M120. I will add an M110 which is used by Nophead's gRead.py to see that skeinforge generated the gcode, and add a word indicating the generator. So in other words, the gcode line will look like:
M110 (skeinforge)

Ideally in future reprap and skeinforge will use the gcodes in the same way, but until then an indicator will be useful. Using M110 for the indicator means that Nophead's code will still parse the new skeinforge.

For fitting gcodes into a workflow, you can insert whatever commands you want into the gcode stream. The parsers ignore whatever they don't need, like all the extra skeinforge commands. You can insert temperature commands, movement commands into the gcode stream if you wish, or parse the stream and add them later, both ways work. If the commands are inserted into the gcode stream, the advantage is that any gcode viewer can see the results.

Cheers,
Enrique

I have to ask: Why use M Codes for these mark-up type things? Couldn't a comment with a defined structure work just as well and leave the M Code 'slots' available for actual machine commands?

I'm concerned because 1) The M Code slots are a limited resource, and 2) RepRap intends to have many tool heads.

In some of the CNC stuff I've seen the practice of adding meta-data in the form of comments seems pretty common.

Also, I do know that in EMC, if the application to implement a given M Code is not in the correct directory then the program will fail.

Wrote the first M App. M104 for temp control.

Turns out it's really easy! I'm currently using the official Arduino firmware, just don't bother hooking it up to steppers. Hopefully we can change the official fan control M Code to a user defined one and then there shouldn't be any reason to have to create another firmware.

The attached is a python script that simply passes the value given to it on to the arduino over the serial port. It works if called directly from the terminal on my Mac, I'll give it a try on my EMC box soon.

It (and all of the M Apps) requires pySerial. (BTW, the macports version didn't work for Python25, download directly from SourceForge)

Edited 1 time(s). Last edit at 05/22/2008 12:28AM by brendanjerwin.

Hi Brendanjerwin,

Great point about putting commands in comments. I did not know that was the best way for tool chain messages, I've never actually used gcode before.

I'll convert all tool chain messages into the form '('. Except for M110 which will be kept, but deprecated and always accompanied with a line below with the new command '('.

Cheers,
Enrique

Hi Enrique

Fanuc is probably the most common Gcode format. The one I use has ; (semi colon) as the delimiter

G01 Z-10. ; Comment ignore

This would also be acceptable:-

G01 Z-10. ; Comment ignore ;

Mach3 uses G01 Z-10. ( Comment ignore )

My suggestion is if possible you make the delimiter an option in the setup window so any make of machine could accept your code.

---

Regards

Ian

Hi Ian,

I thought parentheses were always considered comments. Would a line like:
(I am a comment, please ignore me.)

be ignored? Or do you mean for the Fanuc it have to be:
;I am a comment, please ignore me.;

Is there some kind of comment style which is recognized by all machines? I don't mind commenting out an entire line.

Cheers,
Enrique

Enrique,

I've also got this going on: [forums.reprap.org]

Perhaps you can side step the whole problem of dealing with comments by adopting a format other than g code? Assuming my format settles on XML you could add whatever inter-tool-chain attributes you want in your own xml:namespace. Then there would be no chance of the sort of interference we just ran into with the M Codes.

Ok, here is the final set of M Codes to implement as M Apps:

M100 - Set extruder motor control PWM to P

M101 - Turn extruder on, forward

M102 - Turn extruder on, reverse

M103 - Turn extruder off

M104 - Set extruder temp to P

M105 - NoOp : Needed so the g code interpreter doesn't barf.

M106 - Fan on

M107 - Fan off

M110 - NoOp : Needed so the g code interpreter doesn't barf.

Hi Enrique

Unfortunately different flavours of G code seem to use different comments
That was why I suggested the delimiter might be a parameter.
Certainly I have one that uses ";" and another that uses "()"

There may be others perhaps some one else can jump in. What does EMC use?

---

Regards

Ian

EMC uses parenthesis "()". [www.linuxcnc.org]

It uses the RS274NGC standard for G Code. I believe it is something of a lowest common denominator and that there are post-processors that convert it to some of the more specific dialects. So, IMO, if you have to use G Code, use RS274NGC. (But I still think you should consider dropping G Code as the direct output and go to the Intermediate Language scheme.)

Hi Ian,

What would happen if had a line like:
(;comment)

A machine using the RS274NGC would see that as a comment. A Fanuc would see that as:
(

Would the Fanuc skip over a line with only a parenthesis? Or would it crash and burn

Enrique

Here is the full set of M-Apps. The are not really tested yet, but if anyone is brave enough they can give them a try!

nophead Wrote:
-------------------------------------------------------
> If your machine is the same topology as a Darwin
> and you use use PCL or PLA, then the RepRap host
> G-code will work but if your machine or materials
> are different you will have to be prepared to hack
> the Java.
>
> For example, the RepRap host wipes its nozzle
> between layers. That would be completely different
> motion on a moving head machine compared to moving
> table.
>
> I don't think Enrique's g-code has any details
> like head lifting on moves, nozzle wiping, etc, in
> it. Certainly the old version I am using doesn't.
>
>
> I parse the g-code for paths and then add raft
> generation, nozzle wipes, different temperatures
> on different layers, fan control, etc, myself. It
> would be easy to convert that back to g-code of
> course.


Sorry to post so far along in this thread but the Reprap host software has the option to shut off the wipe and cooling function in the preference tab. ABS works very well for myself also on my Darwin with the host software..

What you guys are working is great by the way I cant wait to get my Arduino electronics up and working.

Bruce Wattendorf

hey,

sorry about delaying so much. the latest version of the arduino firmware will use M106/M107 to turn fan on/off.

expect it this weekend (or tomorrow)

Awesome!