Shop OBEX P1 Docs P2 Docs Learn Events
Propeller gcode interpreter for CNC and 3D Printer — Parallax Forums

Propeller gcode interpreter for CNC and 3D Printer

RaymanRayman Posts: 14,854
edited 2011-11-10 08:55 in Propeller 1
From this other long thread (that I don't want to hijack too much), I want to make a Propeller version of the Thing-O-Matic controller (Arduino based).

This is all new to me, but I think this is the concept:

As I understand it, you can use software such as MACH3 on a PC to generate gcode that tells the tool exactly what to do. You then copy the gcode onto an SD card and stick it in the Prop controller. The Propeller will then send signals to the stepper controller to move the tool around.

The Thing-O-Matic just does 3D printing, but I'm hoping the Zen kit I've ordered will also double as a basic CNC machine for soft materials.

But, instead of just doing what the Arduino unit does, I'd like to add in extra functionality...

What makes sense?
VGA/KB/Mouse interface? - use a computer monitor to see what's going on and manually control
(or does TV/KB/Mouse sound better?)
Network interface? - use a PC web browser to to see what's going on and manually control

Or, does a little, say 3.5" touchscreen interface make more sense?
Is sound output important?

I think you could use a PC to control the system and not use the Propeller at all.
But, the Thing-O-Matic people seemed to think that a microcontroller based approach is better.
I'm hoping that more people feel the same way...

Maybe there's only a handful of people out there thinking about this too, but I'd like to hear any opinions on the right direction.

Comments

  • SapiehaSapieha Posts: 2,964
    edited 2011-02-23 06:16
    Hi Rayman.

    MACH 3 don't need Micro-controller Hardware. All that needs are Stepper controller's that are Parallel port driven from PC and has only signals to it - Forward/Back,.Step's, Half/full step's.
    Other that software are KCAM4.
    It is that ones I look on.


    Rayman wrote: »
    From this other long thread (that I don't want to hijack too much), I want to make a Propeller version of the Thing-O-Matic controller (Arduino based).

    This is all new to me, but I think this is the concept:

    As I understand it, you can use software such as MACH3 on a PC to generate gcode that tells the tool exactly what to do. You then copy the gcode onto an SD card and stick it in the Prop controller. The Propeller will then send signals to the stepper controller to move the tool around.

    The Thing-O-Matic just does 3D printing, but I'm hoping the Zen kit I've ordered will also double as a basic CNC machine for soft materials.

    But, instead of just doing what the Arduino unit does, I'd like to add in extra functionality...

    What makes sense?
    VGA/KB/Mouse interface? - use a computer monitor to see what's going on and manually control
    (or does TV/KB/Mouse sound better?)
    Network interface? - use a PC web browser to to see what's going on and manually control

    Or, does a little, say 3.5" touchscreen interface make more sense?
    Is sound output important?

    I think you could use a PC to control the system and not use the Propeller at all.
    But, the Thing-O-Matic people seemed to think that a microcontroller based approach is better.
    I'm hoping that more people feel the same way...

    Maybe there's only a handful of people out there thinking about this too, but I'd like to hear any opinions on the right direction.
  • RaymanRayman Posts: 14,854
    edited 2011-02-23 06:32
    Ok, I see it now, MACH3 is a GCODE interpreter. So, I think what I want to do is have the Prop controller do the same things that MACH3 does.
    I'll take a look at KCAM4.

    I suppose another approach for the 3D printing parts is to use the Thing-O-Matic software to generate the gcode and have the Prop process that...
  • jazzedjazzed Posts: 11,803
    edited 2011-02-23 07:01
    G-code pretty complicated. I wrote an interpreter a few years ago that implemented most of the codes, but ran out of Propeller memory before it could be finished. Still there was enough to do some X/Y table printing, etc... The PC application would read the G-code and send it to the Propeller an instruction at a time. Sadly all of that work was lost in one of my computer disasters. Here's a video of the system running: http://www.youtube.com/0x5555#p/u/10/p3lZaYeUGFg
  • RaymanRayman Posts: 14,854
    edited 2011-02-23 07:21
    Too bad you lost it, looks like you had it going there... Maybe gcode is more complex than I was thinking...

    Given that, and the fact that controlling the steppers needs a lot of I/O pins, I guess I'll need a 2 Prop solution.

    One Prop will take in gcode commands via serial port (either from PC or second Prop) and control steppers.
    Optional second Prop will be used for human interface.
  • jazzedjazzed Posts: 11,803
    edited 2011-02-23 08:04
    I used single pin control EasyDriver modules with one Propeller.
    They only have 2 speeds, but that choice left me with plenty of Propeller pins.

    I found the PC side g-code application but it needs to be rewritten for current platforms.
    As is, it needs some MSCommLib.dll stuff. It's more than a 5 minute job. Here's a snapshot:
    GcodeClientSnapshot.jpg
    585 x 543 - 42K
  • RaymanRayman Posts: 14,854
    edited 2011-02-23 09:10
    EasyDriver won't work for me because it's rated for 750mA max and the Zen steppers are 1.7A.
    As I read it, you need 2 pins, 1 for direction and 1 for step. So, essentially that's the same as the driver board I'm getting.

    So for 4 axes, that's 8 pins. Then you also want to monitor limit switches and proximity home switches and an E-stop switch.
    Also, it seems people want to enable the axis motors with a dedicated pin.
    Also, there's sometimes a spindle motor relay to control.
    We'll probably want to monitor and control the temperature of the 3D print head...

    I think it adds up to a lot of pins... I could try i2c expansion, but I'm not totally sure that's fast enough...

    I see there are 3.4 MHz I2C I/O Expanders from Microchip.
    I'm pretty sure that would be fast enough. But, jazzed has me worried now about how much memory a gcode translator will take up...
  • jazzedjazzed Posts: 11,803
    edited 2011-02-23 09:24
    I emailed a copy of my Propeller G-code interpreter to a forum participant once.
    I've asked via PM if he could send back a copy if he has it. We'll see.
  • sssidneysssidney Posts: 64
    edited 2011-02-23 09:34
    The standard toolchain for the thing-o-matic is replicatorg - http://replicat.org/. It uses skeinforge (http://fabmetheus.crsndoo.com/) to generate the g-code. skeinforge is included as part of the replicatorg download.

    I got my thing-o-matic built and running just a few weeks ago. Pretty cool except for that arduino. :)

    The thing-o-matic gets the gcode from either the USB or the sd card. I've only used the USB so far with no problems.
  • RaymanRayman Posts: 14,854
    edited 2011-02-23 09:57
    sssidney, thanks, I was just reading about Sanguino3G at the replicat.org website.
    If I'm reading it right, RepicatorG does a lot of the gcode processing on the PC and sends simplified commands over USB serial link or SD card.

    Perhaps a better approach for me (at least for 3D printing) is to process this binary code instead of text gcode.
    Then, I think I can use the Makerbot software directly...

    I'm not sure if that approach is workable for regular CNC work though...
  • sssidneysssidney Posts: 64
    edited 2011-02-23 10:19
    So the code stored on the sd card or that is send over the serial link is actual the S3G that is created by replicatorG...

    http://replicat.org/sanguino3g

    It would be interesting to write a small PC program to interactively fire these commands at the thingomatic.
  • JasonDorieJasonDorie Posts: 1,930
    edited 2011-02-23 11:56
    A shift register would be fine for monitoring the limits and e-stop, as well as the drive enable pins - None of those have to be set or read particularly quickly (at least, not as quickly as the step & direction pins). Even those, for a typical machine, likely won't be as demanding as you'd think. My machine is 8000 steps per inch, and the motors get useless at a little under 180 inches per minute, which is only 24,000 steps per second. A PASM driver would have no trouble hitting that, and I doubt it'd give a shift register much trouble either.
  • RaymanRayman Posts: 14,854
    edited 2011-02-23 12:45
    Thanks Jason. Good to get some real world input... I'll assume your system is better than mine and use 24kHz steps as upper limit to what I need.

    A shift register with latch is another option... That could also achieve 24 kHz. I'll have to think some more on the best approach for a 1-Prop system.
  • JasonDorieJasonDorie Posts: 1,930
    edited 2011-02-23 12:56
    My motor drivers were set to use 1/8th micro-steps, but I just recently reduced them to 1/2 steps (for better repeatability), so the step rate comes down correspondingly. So now they're actually 2000 steps per inch, or a max of 6kHz. My point is that micro-stepping may factor in to your design - If you want to support micro-step setups, you'd need to support correspondingly higher step rates.

    I've seen drivers that support up to 256 micro steps. For a cutting machine that doesn't make much sense, as the small steps aren't likely to overcome the static friction required move the head, but for a printer the forces involved are much lower - micro-steps might be useful. Blah blah blah... :)
  • RaymanRayman Posts: 14,854
    edited 2011-02-23 17:44
    I have a feeling I'll be dropping back on the microsteps as well... I find it hard to believe the motors can actually deliver on the 1/32 microstep option of the controller... But, I have to decide via switches what I want. But, here's a question...

    If I set the hard switches of the controller to say 8 microsteps and then give 8 pulse bursts in intervals to move the head, is this equivalent to single stepping?
  • JasonDorieJasonDorie Posts: 1,930
    edited 2011-02-23 19:41
    It's equivalent in that it'll move the same amount. The microstep case will likely move smoother, producing less resonance, though it'd depend on how fast you sent the pulses - if you sent them essentially "all at once" it'd probably be identical. (look at the "Step Response" graph on this page: http://www.euclidres.com/apps/stepper_motor/stepper.html if you're unfamiliar with stepper resonance).
  • RaymanRayman Posts: 14,854
    edited 2011-02-24 08:56
    After more research it seems that Mach3 is a very popular tool... Perhaps another avenue is to create a plug-in for Mach3 using their SDK that redirects parallel port output to an FTDI serial link. Then, Mach3 would talk directly to a Prop chip.
  • sssidneysssidney Posts: 64
    edited 2011-02-24 14:02
    Ray - what did you think of replicatorG/skeinforge?
  • RaymanRayman Posts: 14,854
    edited 2011-02-24 14:21
    That's what I plan to use for 3D Printing. I've heard it's a bit hard to use, but I like that it's all free. I just need some Prop code to interpret the binary gcode.
    I'm hoping they've posted the Arduino source code somewhere. With that, it should be trivial.

    Maybe I will make some kind of Windows test app to shoot codes to the. It'll probably be weeks until I'm at that point, but then I'll see if I can find "real" Thing-O-Matic owners (like you) to try the Windows app...

    I'd like to use Mach3 for CNC milling though...
  • Bill HenningBill Henning Posts: 6,445
    edited 2011-02-24 15:54
    A couple of potentially useful links:

    http://www.contraptor.org/arduino-gcode-interpreter

    http://www.dakeng.com/CNCconvert.html

    I am VERY close to ordering a 7" Zen myself...
  • RaymanRayman Posts: 14,854
    edited 2011-02-24 16:15
    Great! More the merrier!

    I just was reading about MODBUS and was excited for a moment because I thought it'd give an easy way to control steppers via serial port. MODBUS support is built into MACH3. Reset_Vector even posted some MODBUS code...

    But, then I figured out that MODBUS isn't used in MACH3 for stepping pulses, just for switches and so forth...
    Still, it is interesting and potentially very useful.
  • Adam WieslerAdam Wiesler Posts: 81
    edited 2011-02-24 17:02
    Very neat thread! I'm doing something like this, on my 2x3 CNC router. I am planning on using emc2, but hope to move it to propeller. I also got ahold of a Panelview 600 touch screen from Allen Bradley and hope to get that set up with it.
  • RaymanRayman Posts: 14,854
    edited 2011-02-25 06:26
    Spent more time looking here:
    http://www.machsupport.com/MachCustomizeWiki/index.php?title=The_G100/GREX_plugin_as_a_model_for_device_control

    at the G100 plugin for Mach3. Thinking some more about it, this is a perfect application for the Propeller. A cog can be dedicating to the precise timings given by Mach3.

    The connection to the Prop could be over LAN or PropPlug style USB serial.
    There is a bit of latency with serial to worry about, but I think that could be dealt with.
  • StefanL38StefanL38 Posts: 2,292
    edited 2011-02-25 10:32
    some time ago I looked into some freeware shareware CAM-tools.
    Meaning load a 3D-model of a mechanical part as input and get G-codes for driving a cnc-mill to create the part.

    The output was ALL very simple and basic gcodes 95% was driving linear even for circles which where divided into a big list of linear moves.

    So a gcode-interpreter that does not ALL gcodes but only the really important ones should easily fit into 32kB of RAM

    @jazzed: can you give a raw overview of the gcodes that you implemented into the prop-gcode-interpreter
    really just a raw overview

    was memory full after G00 - G04 + M00 - M20 or how many % of the gcodes did fit into 32kB?

    Anyway the gcode-interpreter would be something for BIG SPIN

    best regards

    Stefan
  • RaymanRayman Posts: 14,854
    edited 2011-02-25 15:25
    Stefan, I also have a feeling we don't need a full gcode implementation...
    I'll have to take a look at the Makerbot recommended software and see what kind of gcodes it spits out.
    Perhaps the Prop could use the actual gcodes instead of the reduced binary versions that it generates...
  • tingotingo Posts: 87
    edited 2011-11-09 13:28
    A quick question: will this controller work for a CNC mill / router, or is it too tightly connected to a 3D printer?
  • RaymanRayman Posts: 14,854
    edited 2011-11-09 17:30
    I'm hoping it will work for CNC... My original 3D printer bot got taken over by Arduino, but I'm hoping to make a new version that will be Prop driven and a CNC router for plastic...

    I think the g-code is essentially the same for 3D printing and CNC milling...
  • StefanL38StefanL38 Posts: 2,292
    edited 2011-11-10 02:02
    To give a quick view into G-Code:

    some examples

    G01 X100 Y 200 Z300 F50
    move tool to XY_Z-coordinate 100,200,300 at speed 50 mm/minute

    G02 X30 Y40 I5 J15 F120
    move tool in a circle clockwise startpoint of movement is 30,40, actual Z-coordinate center of circle is relative to startpoint x+5, Y+15 at speed 120 mm/minute

    What a 3D-printer does not need
    M03 tool-spindle on clockwise
    M07 cooling-fluid on

    what a 3D-printer needs instead
    a command for extruder spit out melted plastic on/off

    So the main things are the same some details are different.

    keep the questions coming
    best regards
    Stefan
  • wjsteelewjsteele Posts: 697
    edited 2011-11-10 08:55
    G Code is used to the motion of the head itself. M code is machine specific commands. For a 3D printer, there are commands (defined by the manufacturer, or in our case RepRap working group) to control the extruder, heaters, etc.)

    Bill
Sign In or Register to comment.