EMC2 Based Repstrap

Here they are. All packaged up pretty too.

These have been tested with EMC in simulator mode and some have been tested from the command line to actually talk to the arduino.

You can run each from the terminal by hand if you just want to play with them.

I'm thinking I'll move on to the HAL driver now.



Does anyone else out there actually run EMC2 too?

Alright, got the first cut of the user-space driver and it's associated hal files and virtual control panel.

You can see the VCP embedded in Axis in the screenshot. (The temp value is not yet being read from the arduino, but that will be trivial now that all the plumbing is in place.)

You can also see, the the gcode window, all the M Codes. They all execute successfully now.

Next step is to actually read the temp from the serial port and then I'll hook it up to some real hardware!

There. It works. EMC2 gcode interpreter calling my M-App which tells the arduino what to do. Plus, user-space HAL driver polling the arduino for the current temp and reporting that to the HAL then a VCP integrating that data right into the GUI.

Now I guess I should get back to finishing my extruder so I can do more than change the temp and read the temp.



-----------------------

You know, I think we need to add a command to the arduino firmware that will just do a status dump when called. That way I can wire in more status stuff. I'd like to see ooze-stopper position, actual heater pwm, target temp, extruder direction, extruder pwm... probably some other stuff too.

I think EMC gives you some fancy HAL signal logging and charting. It might be nice to be able to graph all those values and see their interplay.

Looking good so far! If you really wanted status dumping, I'm sure you could hack some (or more) of it into the arduino firmware yourself. You can look at the existing temperature reporting code to see where to start; it shouldn't be too hard

As for EMC2 users... if there weren't any before, there would seem to be a reasonable chance of getting more now.

It would be nice to have projects like this and skeinforge hosted somewhere easily accessible and linked from the wiki, rather than having to scour past forum posts for download links.

Yeah, I've already been looking into the firmware. I bring it up here more to keep communication active and to fish for ideas.

Speaking of ideas: I'm thinking the status report should be a nice XML structure.... No, not really, that's just another sad attempt at humor.

As to the place to put these sorts of things; I just saw that Enrique has SVN write access:

[reprap.svn.sourceforge.net]

Maybe if I'm nice I can get the same. I suppose I should also start a builders blog with the other folks to chronicle my developments. At least then stuff would be all in one(ish) place.

Oh, another thing. I'm running my EMC simulator in a vmware image.

Enrique, or anyone else, would you like a copy for testing g code in?

Give me some idea of demand and I'll see about cleaning it up a bit and putting it somewhere to download.

I will absolutely 100% be interested in this, but I have to get my milling machine running fully before I can convert it to a milling machine/RepStrap hybrid. It will be a few months...

Hi Ian,

I just found an article about how to change the comment character, from:
[www.ahha.com]

"If you wish to run macros using comments in parentheses, the comment character must be changed from a semi-colon to a left parenthesis

Hi

It sure would.

As ahha's UK agent I guess I should have known that already!

---

Regards

Ian

I hacked/cleaned up a gcode output from Skeinforge and got it to load and backtrace in Axis. Here are some screen shots.









Edited 1 time(s). Last edit at 05/23/2008 09:30PM by Brendan Erwin.

M108 P[TEMP] - Dwell until extruder temperature reaches P (+-1 degrees). Also has the side effect of setting the target extruder temperature. (implicit M104)

This code will be used to 'pause' execution while the extruder reaches the desired temperature. When implementing, keep in mind that this might be used to set and wait for a temperature that is either higher or lower than the current.

-------------

The other option, rather than taking up another M Code slot, would be to change the meaning of M104 to this. Honestly, I think that is the better plan, since I can't really think of any reason to set a temperature and then run off extruding before the set temperature is reached...

Enrique, Nophead, Zack? (or anybody else..) What do you think?

I currently sometimes wait for the target temperature and sometimes not.

If I wait I have to wipe the nozzle afterwards. If I had the anti-ooze valve I would probably always wait.

---

[www.hydraraptor.blogspot.com]

Hi Nophead,

Is it possible to have the extruder off and travelling on a safe loop right in between filaments until the extruder reaches target temperature?

What I mean is, you could go right between the extruded perimeter and the infill. There is still extrusion there, but it is less than the middle of an extrusion and the leftover from the nozzle could fit in there. That is the way 'comb hair' operates.

Cheers,
Enrique

Enrique,
I am not sure what you are asking. There isn't any space between filaments, or between infill and perimeter.

To be honest I have never understood how comb hair could work. When moving between runs the head is lifted so the filament will always take the shortest path even if the extruder dodges around holes.

I could try not lifting the head and just smear the ooze.

---

[www.hydraraptor.blogspot.com]

Hi Enrique

I am setting up a G code CNC machine with an extruder. On my control I cannot access the P word as it is actually delay time for pauses. Can I suggest the S word is used for temperature. This is spindle speed which is vaguely analogous to temperature. More important it is accessible on every control I have ever worked on and usually gives out a PWM digital signal and/or an analogue 0-10V DC which makes it very easy to control temperature.

---

Regards

Ian

Quote

On my control I cannot access the P word as it is actually delay time for pauses

Have I missed something fundamental here? I was under the impression that P was always a parameter of some kind, never the start of an instruction. It's used for both setting extruder speed (M100) and temperature (M104). If you can't use P as a generic parameter, then something is terribly wrong with your controller.

Ru Wrote:
-------------------------------------------------------
> On my control I cannot access the P word as it is
> actually delay time for pauses
>
> Have I missed something fundamental here? I was
> under the impression that P was always a parameter
> of some kind, never the start of an instruction.
> It's used for both setting extruder speed (M100)
> and temperature (M104). If you can't use P as a
> generic parameter, then something is terribly
> wrong with your controller.

Hi Ru

I am talking about an existing CNC controller running Fanuc compatable Gcode where a G4 P?? is a delay. This suggestion is so users with existing CNC machines can bolt on an extruder and with minimal electronic hardware added for extruder speed & temperature control have a Hybrid Mill/Reprap.


Most CNC machines have configurable M functions but not all of them allow access to the actual gcode Words such as X?? Y?? or P?? for use in those M functions.

However they all, as far as I am aware, allow access to the S word as it is used for spindle speed control.

I am suggesting a change to the Reprap Gcode standard which would enable any one with a 3 axis CNC join the reprap world without building a complete Darwin. I see the milling and fabricating functions as complementary.

Brendan Erwin is going down the same track I believe. He is using EMC, a software CNC control that seem to have a great deal of flexibility that runs under Linux.

I am trying to do the same thing with Mach3 which is a Windows software control. Looking through the customisation documents it does not seem to allow me to read the Pword for extruder sub routines.

---

Regards

Ian

Ian,

At the same time as I'm building the EMC integration stuff I'm also working on the SMIL file format and associated programs.

The idea is that Enrique could output to SMIL and then various post-processors could do the work of applying material and machine specific strategies and outputting the final machine control code (I don't want to say just g code since I think Nophead actually uses Python).

I have a quick hack that will convert the output of the current version of Skeinforge to SMIL already. My hope is that Enrique will make SMIL a native output. (And if not, at least just settle on RS274NGC with a single set of M Code extensions.)

Finally, today or at least this weekend, I expect to have the SMIL to EMC G Code translator done. After that how about I work with you to produce the SMIL to Mach3 G Code translator? I'd also like to see if I can help with getting info back out of the extruder to Mach; like the vcp I'm building for Axis. Are you using the Arduino electronics?

[forums.reprap.org]

It sounds like we have a need to go ahead and leave the current M Code in place. I suppose it IS a bit premature to assume that everyone has the anti-ooze in place already.

So:

M108 P[TEMP] - Dwell until extruder temperature reaches P (+-1 degrees). Also has the side effect of setting the target extruder temperature. (implicit M104)

This code will be used to 'pause' execution while the extruder reaches the desired temperature. When implementing, keep in mind that this might be used to set and wait for a temperature that is either higher or lower than the current.

brendanjerwin Wrote:
-------------------------------------------------------

Are you using the Arduino electronics?


Yes I am.

The only difficulty I have at the moment is talking to the Arduino Gcode firmware.

Zach's Processing host works but Chris Meighan's does not. The Arduino sees 1 command runs it and then accepts no further command. All this is using Windows which may account for the differences I am seeing.

Right this moment I am experimenting with Hyperterminal. If I send M101 nothing happens until I exit hyperterminal when the Extruder runs. It seems as if the Arduino does not recognise my line feeds possibly because of the Dos / Linux line end differences. Once this works sending a serial command from Mach3 seems fairly straight forward

---

Regards

Ian

Its actually a bit more complex than that:

If the temperature starts off lower than the melting point of the material then I wait 20 seconds to allow the filament time to melt. Obviously the 20 would be extruder specific.

I then run the extruder for a time which depends on the material and whether it was cold to start with to make sure the extruder barrel is full and up to normal pressure. I then wipe to nozzle to cut the bit off that has just been extruded.

The temperature is critical when making peelable rafts, etc. Also when extruding small objects it will overheat unless the rate is slowed down, and probably will need inter layer cooling delays in some circumstances. To do this we either need an elaborate thermal model or measure the object surface temperature. One way I am thinking of is with a thermal imaging camera. Hopefully just a webcam with a filter changed, but I haven't investigated.

This sort of thing requires two way communication with the machine, which is why I use a packet based (rather than streaming) protocol and a high level language at the host end. Is EMC and g-code up to this level of interaction?

---

[www.hydraraptor.blogspot.com]

Quote

I am talking about an existing CNC controller running Fanuc compatable Gcode where a G4 P?? is a delay

And the controller does not understand the use of P in any other context? I will politely describe this as 'poor design'.

Quote

Most CNC machines have configurable M functions but not all of them allow access to the actual gcode Words such as X?? Y?? or P?? for use in those M functions.

Ahh, now this I didn't know. But as I mentioned, we have two M codes (extruder drive speed and temperature) which require P parameters. It is not inconceivable that other toolheads will also require more of these sorts of parameters either. I envisage extruder and support heads running in parallel without head changing for example; this might well need another code for controlling support material extruder drive speed. Which other commands can you use as well as S?

There's only so much hacking you can do to support broken hardware before it starts to make the rest of your system a mess of hacks and counter-hacks...

Quote

Brendan Erwin is going down the same track I believe. He is using EMC, a software CNC control that seem to have a great deal of flexibility that runs under Linux.

I am trying to do the same thing with Mach3 which is a Windows software control. Looking through the customisation documents it does not seem to allow me to read the Pword for extruder sub routines.

Lets hear it for open source software, folks You could try chucking an email at the developers of Mach3, or whatever contact point they'd like you to use. The documentation may be lacking, or they may even be interested in future features (though this is rather less likely).

I would suggest making a gcode converter than changes current Mxx Pxx lines into something that your controller software can understand. I'd do this with a tiny little perl script... it would only take a few lines. It isn't a major development task by any stretch of the imagination.

As Brendan said, making your own (or adapting another) intermediate-format-to-gcode converter is going to be the way of the future.

Edited 1 time(s). Last edit at 05/24/2008 12:19PM by Ru.

nophead:

I'm gonna use these real requirements to test my overall design. Please keep them coming!

Wait for the filament to melt. That should be easy enough to do in g-code. Basically do M108 P230 followed by G4 P20 to wait. The number of seconds is actually machine (extruder) and material specific, right? That value would be part of the machine and material strategy that went into generating the G Code from the SMIL.

The run and wipe sequence would be determined by the machine and material strategy.

I'm not sure of the exact mechanism for reading the temperature. I was actually thinking along the lines of an IR sensor mounted on the extruder that could keep a constant read of the workpiece surface temperature. That data would be provided back to EMC via the same mechanism I'm using for the nozzle temperature reading.

If it does in fact require more complicated processing (like in the web cam case) then a user-space application could do the analysis and again provide the results back to EMC via the user-space HAL layer.

G-Code actually is a high level language (well, structured anyway). I know it doesn't look much like it because of all the cryptic codes, but it provides all the constructs needed for a structured language. Flow control, condition testing, variables, etc.

I do think it will be up to that sort of interactive control.

BTW, one of the things that EMC provides that will be quite valuable in the future is hard real-time control. It is capable of synchronizing axis movement against spindle speed for instance. (Used for rigid tapping and cutting threads on a lathe.) It can also calculate PID and directly control servo motors. It even recently had it's kinematics engine upgraded to be able to do 5-axis positioning. That will be very useful for pick-and place type applications in the future.

Nophead,

You described the extruded filament as being a squashed oval. So there should be a small cross shaped room at the top between two bottom filaments and two filaments above. Not much room to be sure, but more room than anywhere else in the filled part. I'm hoping it will be enough room for the leftover filament to go.

I didn't realize that the filament contracted so much when the head was lifted, that it would just ignore moves until it touched down again. Not lifting the head and just smearing the ooze would be a great experiment, if it works then combing could get rid of some stringers.

For determining interlayer cooling delays, it is straightforward to determine how long the extruder spends on a layer. So if we're lucky we could get by with an option to pause or slow the extruder for small, quick layers.


Ian,

For the temperature and other analog commands, any character is ok with me, my only preference is that we find a character than can work on all machines. P, S, or even a symbol like @ or # would be fine. Also, it would be ok if a macro was written at the top of the page to redefine a letter or symbol for some machines. For my skeinforge machine gcodes, I'm just following the specifications written up by Zach:
[reprap.org]

Blerik and Chris Meighan were also working on gcode, so they might also know why the P format was chosen.

If all else fails, the option to find and replace P with another letter could be added. But I'd like to try all else first


Brendan,

For an intermediate format, if you write a python script with a function to output a format from gcode, I'll link to it. My question is, why write another format when you could just add comments to the gcode? In case there is any confusion, the skeinforge slice and fill routines do not output the temperature or the raft, so you do not have to regenerate the time consuming fill if all you want to do is change the temperature, or change the raft, etc.. The gcode can be outputted after the slice, fill, stretch, comb, or fillet operations. The reprap java program does do more together, but I'm not developing that program and it has the option of turning stuff like the nozzle wipe off. Also, the reprap program generally takes less time to generate the gcode than to extrude, and the skeinforge program has been recently sped up to the point where it now also takes less time to generate than extrude.

If another format has a similar file size and capability to gcode with comments, I do not understand the advantage of it. However, you can reduce the skeinforge gcode size by a factor of about 8 by zipping it. If you want to write code so the Arduino or other machines can decompress zip files, or make a format that is easier to decompress, that would a great step forward.

Cheers,
Enrique

Enrique,

If the performance of the slice/dice operations has gotten fast enough then you are completely right, we don't need an intermediary format at all. (Ru told me to be prepared that I was wrong...) The idea with the SMIL stuff was to capture the output of the most expensive operations in a declarative manner to allow easier later translation into actual machine instructions. G Code wasn't quite the right thing for that since it is designed as a set of execution steps not construct declarations.

If the slice/dice is fast enough now we also have the opportunity for even cooler stuff. The machine and material strategies can be provided right at the beginning of the slice/dice. This neatly solves the infill percent problem I ran into. i.e. the geometry of the threads changes depending on the infill, but the infill is most closely tied to the material being used. It also allows you to make bridging decisions more intelligently. All in all, a much better place to be. (I believe the buzz-word for this in the CNC world is "knowledge-based CAM".)

So how about this:

I'll find a way to represent the machine and material strategy information in a declarative manner. Then you can simply use that when processing. (this means you can decide how to comb based on knowledge: extrusion size, material, anti-ooze or not.)

You output "standard" (read EMC flavored) G Code and I'll work with folks to provide post-processors to manipulate it into other dialects. (Like I said before, I can give you a VM with the EMC software running in simulation mode for you to test the G Code in.)

What do you think?

Enrique,
I have extrusion density set to 0.82 and infill perimeter overlap set to 0.5 so I suppose there is a little room, but not much.

The filament does not contract much but it stays in a line from the extruder to the source point so unless you double back, in which case it will go slack, but it wont stick to the layer below because it has cooled already. A lot of the time it just snaps and leaves blob rather than a string.

The way I have written my software any moves between threads are thrown away. In fact I don't extrude the threads in the order they appear in the g-code, or in same direction, or from the same start point if a close path. Since combing won't fix the problem in the general case of separate islands and the anti-ooze value should, I don't feel inclined to rewrite my code to find out if it works. Perhaps somebody using g-code directly can try it.

Yes I have played around with looking at the layer time and slowing down when it gets small. I had to do that to make Vik's winglasss stem. The problem is it depends on the how the layer cools. For example an open box or small separate islands cools much faster than a solid cylinder like the wineglass stem but might be a smaller area. I have access to the area of the layer, its perimeter and the length of the filament. I expect some heuristic based on those might work reasonably well. I currently don't have interlayer pauses because the ooze problem makes it hard to restart cleanly, but I do slow down and could reduce the temperature.

With a thermal image I could spot the coolest island and set the extrusion temperature to just enough to make that weld. I could also look at the max temp and slow down or pause it it gets too high.

---

[www.hydraraptor.blogspot.com]

Separation of concerns! [en.wikipedia.org]

The project will progress much faster with separate programs that allow people to work on the bit that they knowledgeable on independently.

The only reason I made rapid progress with build quality is that I could change the build algorithm without asking Enrique to add new parameters and algorithms to skeinforge. I am still changing it now on a daily basis so it is far too early too specify the material strategy information. It is much easier to experiment with all this stuff in Python script than it would be if it was captured in a declarative style.

---

[www.hydraraptor.blogspot.com]

Enrique,
BTW, why do you use GNU mesh format, rather than STL, as the input to your toolchain?

---

[www.hydraraptor.blogspot.com]

Nophead:

I agree that keeping things that don't have to go together apart is a good thing. And I recognize that the fact that you handled the machine and material strategy separately from the extrusion geometry helped you make great progress.

I think, primarily because of the infill % problem, that extrusion geometry is not actually properly separate from machine and material strategy though. So, long term, I believe, given the improvements in slice and dice performance, that they should go together.

If Enrique does provide well-commented and marked-up g code as an output you could still easily extract the extrusion geometry from the final result just as you've been doing up till now. It seems like the only difference would be that your parsing job would be a bit easier and more reliable since the comments should be rather descriptive. I would imagine that the comments would segment the g code out pretty much like the structure described for SMIL.

So, you and anyone else using the output from skeinforge, will have to "manually" provide machine and material strategy instructions, but eventually as things settle down, the CAM software should do it for us.

Brendan,

Thank you for the explanation, I understand now what you're trying to achieve. I agree that gcode is a clumsy way of making declarations, but with your excellent suggestion of putting the declarations into comments rather the M commands, they will at least be easier to read. Indeed I'm planning on using RS274NGC with a single set of M Code extensions, the skeinforge commands will be comments. I'm thinking of formatting the comments like:
( 0.7 )

Do you have suggestions on how they should be formatted?

For material information, I suggest starting with listing material properties for our thermoplastics. I could start a thread in the fabrication forum to list properties like melting point, tensile strength, etc.. I don't want to go farther than this right at the beginning because I haven't implemented different materials yet, and it'll take a while for me to see if and how I could incorporate different sets of parameters in the tool chain, without tying skeinforge together in a way that is hard to manage and change.

Making an export plugin system can be done now without complicating the tool chain. The way the tool chain passes around info now is with a pair of functions like:
def getExportText( gcodeText, exportPreferences = None ):

and
def exportFile( filename = '' ):

Right now I'm in the middle of implementing tower.py and after raft.py is a high priority, so it will be roughly at least three weeks before I can make an export plugin system, but you're welcome to start making post-processors now. You can write them with the output of skeinforge, which will not change much, and when they're done you can post them into the software/skeinforge thread & I'll include them in the skeinforge zip file. All I'll be working on is the hook to automatically export without the user having to run an extra script. Ideally, we would make very few dialects, that with well chosen macros and gcode formats would work on most machines.


Nophead,

It seems comb would take a lot of experimentation with the nozzle height and travel path, if it's possible at all. I did not think about how long it could be to implement. In time if some are using the skeinforge output directly, it'll be easier for them to do comb experiments if they wish.

I use the GNU mesh format because it includes the mesh topology, it indicates which edges are around each face. So it is easy for the skeinforge python script to get the triangle mesh from the GNU file.

The difficult work of converting STL into a triangle mesh is done by the Art of Illusion STL import plugin. I have no idea how that plugin works; but it works very well, it has succeeded in importing all the STL files I've tried so far. The triangle mesh it produces will have holes if the STL has missing triangles, but in the triangle mesh they are easy to spot. It is easy to convert the triangle mesh to a GNU Triangulated Surface.

I hope that in future we use the GNU mesh format as the primary format for all our models, instead of STL. This would avoid our many STL problems. If necessary, it is easy to convert GTS to STL, because a GNU mesh file has more information that the STL file.