EMC2 Based Repstrap

One suggestion I was going to make. Enrique's scripts are like a cam programme. An early one I used had a useful function. If a file called Start.txt and a file called End.txt existed in the Gcode directory they were appended at the beginning and and of the final G code output file. If they did not exist nothing changed.

This helps using an existing CNC machine and enables you to use tool offsets and work offsets to set the machine up. Start on my machine would be:-

In this scheme that same functionality would be in the machine and materials strategy file. I think it is better there, where is is tied to both the machine and the material, since I can imagine, for instance, that ABS might take longer to heat all the way through than CAPA.

I suppose, if the number of materials grows too large and the machine strategies are the same across enough of them then we could create a default machine strategy file, but I'd rather wait for that problem to occur before doing that.

Also, if there are very machine specific things that need to be done I'd imagine that being taken care of in the post-processor that makes the final machine instructions.

Good suggestion with the start and shutdown files. I'll add a feature to the program to add Start.txt or start.txt to the beginning and End.txt or end.txt at the end. I'll look for both cases so it'll work even if the file system doesn't handle capitalization properly, like some windows versions.

Once I get the integration of EMC to RepRap done, how cool would it be to add a handler for STL or the Gnu file type (what is that again?) that brings up a version of the skeinforge tool-chain and spits out G-Code right into Axis?

That would make the EMC+Skeinforge experience almost exactly in parity with the official java host software I think.

I've wired up a fairly recent version of Skeinforge more directly into EMC/Axis.

Now a GTS file can be opened directly from Axis and Skeinforge will do it's thing.

I'll add a GUI to it so that you can tweak the Skeinforge settings and (hopefully) perform some translations to the model before slicing and dicing. (you can currently adjust the settings by calling the Skeinforge modules individually just like normal)

Amazing! I know that myself and a lot of other mill users will be able to get a lot of use out of the work you're doing here.

I'm not very familiar with EMC2 (yet!) - does it have easily changeable configuration settings, so that I could have one environment for RepRap, and another for milling, and switch between them? Also, is it still possible in the current incarnation of your script to import Gcode that was generated remotely? These new developments are really cool, but unfortunately I don't think that the computer I'm using to actually operate the machine will be quite up to the task of slicing/dicing. I'd like to be able to generate the Gcode for a particular object on my main desktop and then just copy it to the computer where the actual printing operation will take place.

EMC does have easily selectable configurations. I'll be providing an example ini file for the RepStrap once this is all said and done. EMC gives you either a selector or the option to just make a launcher that sits on your desktop. (I like to add mine to the top bar though.)

The different configurations can have different virtual control panels and user-space HAL drivers loaded and can have different helper applications (FILTERS) configured. for instance, my mill configuration will not respond to GTS files.

Yes, you can certainly process down to gcode and then just open the gcode directly. I don't preclude opening gcode files, just added another file type.

Right now my glue does some post-processing of the output of Skeinforge but Enrique said he'll be doing a plugin system so I expect my code will get absorbed into that structure. Anyway, what that means is that your workflow of "process on the big computer and print from the little one" should work just fine.

BTW, I'm not sure you should worry about your EMC machine's performance; that screencast was running in a VM... It seemed to be acceptable performance.

I am building a McWire cnc, I want to use a dremel to do milling with emc2. I want to buy the arduina and related electronics to drive the stepper motors. I don't want to buy a separate parallel port based board to drive the steppers with emc2.

What course of action and software do I need to take get emc2 talking to the arduina?

I don't think you can. EMC2 drives the steppers by using the digital output pins to create the actual drive pulses. It needs a real-time capable interface which the serial to arduino doesn't do. But, if you don't already use EMC2 then just use the g-code arduino firmware directly. That firmware is a g-code interpreter so there is no need to use EMC2.

Then again, you should be able to get a basic parallel port breakout for less than an arduino, so if you are not planning on extruding then don't use the arduino at all. There is no reason the stepper driver boards at rrrf.org wouldn't work with EMC2...

In short, EMC2 and the g-code Arduino serve the same function; use one or the other but not both unless you need the arduino to drive an extruder.

I'm following the same path you guys are: cnc mill --> repstrap. In my case, i'm interested in retaining my mill's ability to use the reprap extruder as a toolhead.

I currently use my mill for board milling, etc. Its a converted harbor freight micro-mill model ( Seig ).

I dont current use EMC-- I use turbocnc, though, I dont have a problem moving to EMC instead if I need to.

Obviously the "standard" approach would be to treat the exruder like a spindle, and use M-codes to control it. I presume this is what you guys are doing?

When I got to thinking of this problem, i started thinking about how the controller will coordinate the extruder with the motion, to extrude at the same rate as the motion. This would become an issue when the motion profiles are in the accelerating mode ( ie, when the actual speed is still ramping to the nominal speed in the G instructions ).

Has anyone thought of the notion of treating the extruder as an axis rather than as a spindle? It seems to me that this would ensure that the extruder oozes the right amount of goo in step with the motion of the machine. I had in mind using incremental mode ( G91 ) and then treating the extruder as a rotary axis.

Alternative solutions to the same problem would be to use G96, and then use the spindle as a spindle. This solution seemed a bit limiting to me, though, as it doesnt seem like G96 is as widely supported on CAM packages.

I think that the notion of "process on host1" and "build on a smaller machine,host2" makes a lot of sense. After all, RepRap _is_ a 3d printer, and thats how printers work.

Host 1 converts from the original format into a printer language (for example postscript), and then sends that to the printer. The printer does the rest.

If there was a post-script like language for reprap jobs:

(1) you could use a more powerful host for creating the job
(2) save a ready-to-run job and run it again later, or share it with others
(3) Other software could be modified to create the reprap language directly. It is enough effort to make stl then slice-dice that in some cases it might be easier to just make the language reprap needs directly.

the Arduino already connects much like that with the stepper boards and limit switches:
[reprap.org]

Step and direction lines for each stepper.
A single active low line for each limit 'switch', although it would only be a software change to use active high.

Parallel ports operate at between 2.4 and 5 V and normally don't supply much current, 2.5 ma is typical. They can sink more current, 20 ma, but it's still not a problem for the Arduino.

The Arduino has 5 v I/O and can sink or source up-to 40 ma so almost everything that works with a parallel port will work with it with no modifications to either device.

A possible (rare) exception might if the device output 2.4 v as a logic '1'. The problem is I don't known what the min voltage for a '1' is on the Arduino. I've heard of people directly connecting 3.3 V devices and if it uses CMOS TTL levels it should accept down to 2 V but I'd need someone to confirm this.

Even if it is a problem then it is only a small one fixed either by using an analog input(the down side being it couldn't drive an interrupt) or most CMOS TTL logic chips or pretty much any transistor could be wired to return the signal to 5 V.

Trying to think of any other differences, does anyone know if parallel ports have clamping diodes as standard?

Ru Wrote:
-------------------------------------------------------
> If there was a post-script like language for
> reprap jobs:
>
> GCode?

Possibly, though there are some other details to work out:
(1) how to handle extruder directives(temperature feedrate etc)?
(2) how to handle nozzle wipe directives?
(3) waits between layers
(4) other?

I'm a fan of using gcode since my machine already does this, but a 'standard' way of encoding all of the operations needed to build an object would be nice. has anyone already proposed a list of m-codes for extruder operations? nozzle wipe directives could be handled with a user-customized block of codes to move and wipe, but that makes it harder to build the gcode in a way that's machine independent. An mcode that generates a nozzle wipe might work better. but then you have to move the x and y axes, and i'm not sure m-codes normally do that....

I can recommend reading the following threads:
[forums.reprap.org] which is about standalone repraps and [forums.reprap.org] is a teribly long and rambling thread about the use of gcode with a reprap. I'm pretty certain it covers the points you list above. I'll not repeat nor summarise here, as I don't have the patience to re-read 200 odd old posts. You may find some of it interesting, or useful.

Skeinforge, which would appear to be the current favourite reprap CAM tool, has various facilities to allow user- and machine-specific customisations.

More complex things (such as a nozzle wipe) could be done in a macro fashion, where a user supplied block of code is automatically substituted into the gcode output; a sort of poor-man's canned cycle.

Nozzle wipe may well just go away once the solenoid valve becomes commonplace, anyway.

Quotebut a 'standard' way of encoding all of the operations needed to build an object would be nice

There have been various discussions about intermediate data formats which sit between STL and gcode. Nothing has been standardised yet. [forums.reprap.org] is one such discussion.

Defining such a standard is not an easy task... at this stage it is simply more convenient for the people who use such a thing to just roll their own solution. I don't doubt one will arise in the future. It probably just needs someone to write a nice toolchain that makes use of such a thing, that everyone else likes and uses themselves

Keep in mind that the EMC2 Based Repstrap is intended to retro-fit a reprap extruder to an existing EMC2 controlled machine (mill or router I imagine). Therefore, stepper drivers have no bearing on the conversation (since they should already be in place and controlled by EMC.)

Did you ever post the HAL driver or .gts import code? My mill isn't quite ready to have an extruder hooked up to it yet, but once it is, I think your work will be most useful. Have you got your mill extruding yet?

I like the work you have done very well !
I have an emc2 cnc 3axis working and hope to extrude !
I'm very happy when seeing this forum.
Where are you in implementation ?
I can do some test with my emc2 CNC !

There's: [dev.forums.reprap.org]
but I get my hopes up and the thread dies. I don't know enough about EMC or MACH to step in. My diy cnc is almost ready for a head and some software so I'm interested in both of these threads.