Shop OBEX P1 Docs P2 Docs Learn Events
G-code — Parallax Forums

G-code

idbruce:

You keep mentioning G-code and I recently bought a 3D printer so I'm getting interested in it myself. Could you suggest a good reference for learning about G-code? I've done some web searches but haven't found one that describes all of the commands that my printer seems to use (a Printrbot Smalls). I'm assuming that G-code refers to the Gxxx commands but there also seem to be Mxxx commands and maybe others. I'd like to learn about all of them.

Also, it seems you've decided that it is impossible to create a G-code interpreter for P1. Why is that?
«13

Comments

  • David

    I have a PDF file somewhere on my computer which is a very good reference for G-Code. When I have more time, I will look for it, and then find a link to the original. The document will contain information pertaining to both G and M codes.

    The p1 hits a memory barrier, in which you cannot contain the interpreter, all G and M codes, as well as the motion control code. Additionally, the P1 is resource short, such as IO pins, AD, DA, for all this stuff, you definitely need memory and resource expansion.

    The P1 comes close, but no cigar :) As JMG confirms my suspicions, the P2 should overcome the shortfalls of the P1, but then it becomes an issue of well written motion control code.

    Actually I will see if I can find that document now.
  • idbruceidbruce Posts: 6,197
    edited 2017-06-11 12:12
    David

    After a brief search, I could not find the document I was searching for, but this document, which applies specifically to a 3D printer, should get you started until I find a more appropriate document.

    2printbeta.de/download/Command%20reference_Echinus_V1.7a_English_V001.pdf
  • David

    Keep in mind that a 3D printer, only uses a handful of G/M codes which are useful to any given specific printer.

    If you take a look at Wiki (https://en.wikipedia.org/wiki/G-code), you will see that the list of G and M codes is quite extensive. As you know, to support each of these commands, requires memory and perhaps IO resources.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-06-11 12:35
    idbruce

    Seems like G-code should be doable in Tachyon Forth on P1 as far as I can tell. I already use a character interpret mode for some networked communications control where each character has an assignable execution vector when it is encountered except numbers which are built digit by digit including symbols. This mode wouldn't require much to "interpret" G-code and I have all kinds of steppers and motors I could hook-up and try them on. Is there a configuration that you have attempted with the P1? Do you have some useful sample G-code I can practice on?
  • idbruce

    Seems like G-code should be doable in Tachyon Forth on P1 as far as I can tell. I already use a character interpret mode for some networked communications control where each character has an assignable execution vector when it is encountered except numbers which are built digit by digit including symbols. This mode wouldn't require much to "interpret" G-code and I have all kinds of steppers and motors I could hook-up and try them on. Is there a configuration that you have attempted with the P1? Do you have some useful sample G-code I can practice on?
    How did I know that you would say it could be done in Tachyon? :-)
  • idbruce wrote: »
    David

    Keep in mind that a 3D printer, only uses a handful of G/M codes which are useful to any given specific printer.

    If you take a look at Wiki (https://en.wikipedia.org/wiki/G-code), you will see that the list of G and M codes is quite extensive. As you know, to support each of these commands, requires memory and perhaps IO resources.
    Thanks for the link. I take it that CNC applications use a larger subset of the G-code instruction set?

  • evanhevanh Posts: 15,126
    G's are the motion commands.
    M's are control switches - start the spindle, lock the clamps sort of things.

    Each machine is unique in exact interpretations. Generally those differences are not a major problem for the CAM software since there is also many spacial, tooling and materials specific details that also have to be handled at the same time.
  • I'd like to understand why it is important to interpolate gcode on a propeller. You first have to create a design in a CAD CAM software, then you export the gcode to a file that a CNC controller app can run to drive the machine. Two steps. Then during the course or designing parts and running the machine ( which I do every day ) there are LOTS of changes, corrections, additions, modifications, etc on new designs that must be done back in the CADCAM software then exported to gcode again. It is a back and forth process in many cases. The two are never independent of each other. Maybe there are cases where once the part is refined to point of mass production, I could understand using a Prop based gcode to run many of the same part. However, there are ALWAYS cases of breaking a tool and other reasons to need to stop and make adjustments then start up again from a certain line number. That being the case, why would someone ever care about driving the machine solely from the Prop when a PC with parallel printer port is dirt cheap AND you MUST have a CAD CAM software living somewhere ON a PC? Mach3 software is cheap/free controller software I used years ago, works very well. There is NO instance of a Prop gcode interpolater that would be better than mach3. With a Prop, you still would need an LCD display of some sort, buttons, etc. All of which require a good deal of work to create a decent GUI for running the parts. And STILL you are no where near as well off as if you had a PC. In what world is a CNC machine so isolated from the CADCAM software that is warrants this need to develop this gcode interpolater? Even a 3d printer MUST have a design and where does the design come from? Does someone send you the design as a gcode file? Why cant the design and machine controller be the same computer since how often is someone sending you a design/gcode and you are ONLY the cnc machine side? For a Prop based gcode machine, to get it dialed in you are spending a LOT of time to get this designed and built and tested. I know from experience of building a Prop pick and place that ran a CNC that this is a ton of work. AND, what is the gain? In the world of running a business and cranking parts for your product or as a machine shop making parts for others, there is no room for dilly dallying around to hack some gadget together. As a hobbiest to see if you can run gcode on a tiny cnc or 3dprinter? May be fun, but what is the real world application what makes your Prop/Powersupply/LCD/button/enclosure/stepper driver gadget have any value compared to mach3 and 3 gecko's plus a PC you can find in a dumpster? I argue that making a gcode machine is a waste of time except for as a fun thing to mess around with. It is a time vortex and a black hole to be avoided.
  • Peter

    The P1 works well as a machine controller, with numerous steppers and input signals, as I have used it for my spring bender CNC, but that was customized programming, and basically operating in a single threaded scenario. When using the P1 for synchronized motion, amongst numerous axes, it would be best to operate under a multi-threaded programming scenario, and using a machine language, such as G-Code, because of adaptability issues, for various types of machinery. When adapting support for G-Code commands, the memory is quickly taken up, as several members have discovered, myself included. Several have tried to adapt a scheme, in which they only support the commands which are important to their particular application, such as 3D printing, as compared to lathe or mill work, and of course, 3D printing is a unique application from the get go, because of the extruders, heated build platforms, and such.

    As it pertains to the memory barrier, perhaps Tachyon can fit all the commands into the P1, but I seriously doubt it, because there are a lot of issues, such as:
    G-Code input
    Parsing of input
    Trajectory and movement planning
    Actual movement
    Sensor monitoring
    Tool changes
    etc...

    That may seem like a small list, but it takes a lot of code and memory to support all of this stuff, and then if you do manage to get it to fit, then it becomes a matter of limited resources. Depending on the machine you are building, you must allocate your resources very very carefully, and even then, odds are that you will require IO expansion

    After attempting to port Teacup and reaching the memory barrier, as well as a resource barrier, I then decided to abandon that effort. I then attempted a two Propeller solution, dividing resources, as well as code. Once again, I abandoned that effort, due to a lack of well written, open source interpolation source code, written in C, without the use of interrupts. It was all a huge waste of time and money for me.

    In order to be successful with a P1 design, a huge amount of time and effort will need to be dedicated. I do not recommend attempting it :)

    If you should decide to attempt such a feat, I would recommend reviewing three of my threads, which will reveal some ideas, in depth discussion, traps, and pitfalls.

    forums.parallax.com/discussion/159950/the-teacup-port-a-work-in-progress-3d-printer-firmware/p1

    forums.parallax.com/discussion/155404/input-needed-combining-propeller-proto-board-prop-dip-40-and-adc-for-3d-printer/p1

    forums.parallax.com/discussion/160739/new-attempt-3d-printer-controller-and-firmware/p1
  • In addition to my previous comments....

    Let me state once again...
    The P1 works well as a machine controller, with numerous steppers and input signals,

    I am currently working on a P1 CNC application (forums.parallax.com/discussion/166498/discussion-laser-direct-imaging-of-pcbs-and-the-propeller/p1), in which I believe the P1 will shine, but this particular application, will have much simpler code, since it will not have linear or circular interpolation, trajectory planning, a G-Code interpreter, homing switches, etc..., just the bare bones.

    With just the bare bones, I am already looking at IO expansion, just to support a VERY simple interface.

    However, I have no doubt in my mind that the code will fit :)
  • I have no doubt that Tachyon can handle the G-code package and within the basic resources of the P1 including FAT32 support etc. As for I/O, well that is a matter of the hardware itself and you can slave motor chips over SPI and handle a great number of switch and sensor inputs via shift registers surely? Besides that I can slave Props quite easily these days over a single I/O line or RS485 and talk to them or program them via my networking layer and even directly access memory and I/O from another Prop. Tachyon is not "just a language", it's a whole software environment with all kinds of drivers built-in etc.
  • I think supporting G-Code on the Propeller is a bit if a red herring. It seems that the P2 will be well suited for machine control, as many people have pointed out. And that is definitely an area that it can make a name for itself. But I suspect that focusing on G-Code will be the wrong way to go about it. In large/industrial machines that use G-Code, I suspect there's already too much momentum with existing solutions for anyone to risk trying an entirely new (and therefore unproven) processor and approach. In the consumer 3D printer market, where cost is a significant factor, the community has already invested a lot of time and energy in both common hardware and software to help get those costs down.

    That's not to say that "G-Code on the P2" is a bad idea, just that I think the focus should be on the machine control part. Having a readily available set of drop-in modules/libraries that enable machine control will allow people to quickly handle a myriad of tasks, where processing G-Code is just one of them.
  • http://marlinfw.org/meta/gcode/

    That's a 3D Printer specific G-code reference. I'm running a really great one, driven by 8 bit control board.

    That set of G-code is supported and performs very well on: https://www.arduino.cc/en/Main/ArduinoBoardMega2560

    It's my opinion, Propellers should rule on this.
  • I'd like to understand why it is important to interpolate gcode on a propeller.

    It is important because it allows the Propeller to compete in a market where it currently does not have a foothold. The type of situation that you are referring to requires an operating system to run a machine. In the particular market of small CNC machinery or 3D printers, many of these systems are quite capable of running on the microcontroller alone, without being tied to an operating system, such as Windows or Linux, to further run software such as LinuxCNC or Mach3, which handle the interpolation.

    There is currently a fair market share for ICs running small machinery, 3D printers, and such. Why would a company with a powerful microcontroller just forsake that market and allow their competitors to just gobble up the available revenue?

    For the P1, I would definitely hesitate to pursue this market, because in my opinion, it is just too complicated, but if the P2 turns out to be half the chip I think it will be, then I believe this market is worth pursuing, because as pointed in another thread, by JMG, the competitors small microcontrollers have reached design limits.

    In no way am I suggesting that the P2 be limited to small machinery, I am just suggesting that the P2 attack the market of stand alone small CNC and 3D printer market. I think an effort similar to this chip might also be worth pursuing novaelec.co.jp/eng/MCX514_e.html
  • "The type of situation that you are referring to requires an operating system to run a machine."

    So does the generation of the gcode and part design.

    So if you MUST have an OS on a pc mac linux to design and generate gcode, then why is it important to have a stand alone gcode running Prop. If you must have a real computer to design the part, then you already have a real computer sitting there on a table. And if you do have a real computer, there is no comparison to using a very evolved cnc controller app to a prop based controller with much more limited capabilities.
  • Dave HeinDave Hein Posts: 6,347
    edited 2017-06-11 17:26
    There probably are situations where the gcode is generated by someone else on a remote compute, and it would be useful for the Prop to interpret the gcode itself. Then no other computer would be required. The Teacup software could probably be made to fit into the P1 with some effort, but there should be no problem fitting the code into the P2. As far as porting Teacup to Forth -- that sounds like a very painful process. The code is written in C, as are many portable applications. Maybe there is a standard Forth version of a gcode interpreter somewhere, but if it did exist it would require some effort to convert it to Tachyon, which is a non-standard Forth implementation.
  • potatoheadpotatohead Posts: 10,253
    edited 2017-06-11 18:04
    T Chap wrote: »
    "The type of situation that you are referring to requires an operating system to run a machine."

    So does the generation of the gcode and part design.

    So if you MUST have an OS on a pc mac linux to design and generate gcode, then why is it important to have a stand alone gcode running Prop. If you must have a real computer to design the part, then you already have a real computer sitting there on a table. And if you do have a real computer, there is no comparison to using a very evolved cnc controller app to a prop based controller with much more limited capabilities.

    Right now, there is a rapidly growing, smaller scale, very lean manufacturing market growing.

    Solid, simple, purpose made machines have a lot of advantages over ones that require a complex PC to perform the task.

    That firmware and 8 bit micro I linked as an example currently can out perform machines costing 5 to 10x more. I've got one in my home right now nailing some benchmark parts against a 6 figure machine. I'm gonna win that benchmark easily.

    P2 could be a very big win here. I'm entering this market as another career change. Demand is off the charts high and rapidly growing.

    Major league opportunity exists between the high end industrial and low end, let's say casual, hobby gear.

    It's one reason I really want P2 done!





  • potatoheadpotatohead Posts: 10,253
    edited 2017-06-11 18:21
    Oh, and I don't mean to say more advanced, PC based, etc... type CNC controls are bad, or anything.

    They aren't.

    It's all about cost / features / performance. The little micros can now do amazing things, and do so in lean ways.

    G-code is a high value thing. We use the bigger systems to generate it, largely due to the model data sizes. Sometimes, that's not so much of a factor on lean models, 2D, wireframe and so forth, but usually it is. B-Rep solids are the norm. Sadly, and ideally to be improved on here real soon, triangle mesh files are HUGE too.

    Once generated, the requirements for successfully executing the g-code are much less.

    And that is where the opportunity is.

    It's my opinion we may also find some secondary functions, such as backplotting, transforms, optimizations will make sense too.

    Currently, these efforts are complex as well. It takes a lot to make an 8 bit, or even 32 bit micro really perform.

    Doing this the Propeller way may bring some real advantages. We've seen seriously good motion control capability and the whole object, COG, methodology has proven useful when it comes to combining complex functions too.

    P1 is pin and resource constrained, though I do think it can do a lot of these tasks very well.

    P2 is looking to be a prime contender. I'm eager to see us get to real silicon. May make for very differentiated, cost effective product offerings in this space.

  • Heater.Heater. Posts: 21,230
    T Chap,
    ...why would someone ever care about driving the machine solely from the Prop when a PC with parallel printer port is dirt cheap...
    Sorry, that made me giggle. I have not seen a parallel port on a PC for getting on a decade. I have no idea where I would find one today.

    I would hate to have to use some kludgy USB to printer port solution for driving any kind of machine.

  • evanhevanh Posts: 15,126
    edited 2017-06-11 22:47
    I once wrote a G-code interpreter in BASIC that ran inside a very slowly executing dedicated 3-axis servo controller with DC motors. You could visually see the response times to the G-codes. Status, file transfer and menu control were all via a single 9600 baud comport. G-code files were trickle fed, so could be any length. We used ProComm or something.for operator interface. I'm a bit fuzzy now. I think it relied on a Ctrl-Z for end of file to switch back to menus.

    At any rate, the point here is it very successfully replaced a failed attempt at a PC + parallel + steppers solution.

    That one machine ran for many years before the business had the money to buy some faster, stronger production mills - which came secondhand with tape decks but got converted to use Ethernet.
  • rod1963rod1963 Posts: 752
    edited 2017-06-11 23:39
    Heater. wrote: »
    T Chap,
    ...why would someone ever care about driving the machine solely from the Prop when a PC with parallel printer port is dirt cheap...
    Sorry, that made me giggle. I have not seen a parallel port on a PC for getting on a decade. I have no idea where I would find one today.

    I would hate to have to use some kludgy USB to printer port solution for driving any kind of machine.

    Why Ebay of course. A used Dell Optiplex with a Parallel port can be had for $60, add a HDD and you are in business. Why buy new when 2nd hand is good enough.

    Or buy a parallel port adapter card for your current PC.

    Heck there are companies that still make motherboards with ISA slots.


  • T ChapT Chap Posts: 4,198
    edited 2017-06-12 00:24
    Parallel port/PCI slot, whatever. Not sure your point, who said anything about a USB to printer port. I have a http://www.camaster.com/ machine which uses a WinCNC controller via a printer cable and a PCI slot. Nothing kludgy about it.
  • To the original question... "Could you suggest a good reference for learning about G-code?"

    Try
    http://reprap.org/wiki/G-code
    

    It's a fairly complete list of gcodes for most 3D printer firmware variants, with a description of their use.

    dgately
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-06-12 03:45
    He's a reference that seems pretty thorough:

    https://machmotion.com/documentation/Software/Mach4/Mach4-G-and-M-Code-Reference-Manual.pdf

    BTW, without actually trying it, I see no reason that a Prop1 could not handle both the G-code interpretation and the machine control in multiple, linear- and circular-interpolated axes. I've done pretty much the same thing with an eight-bit, single-process controller (Zilog Super 8 ), programmed in Forth and assembly for controlling a four-axis mill.

    -Phil
  • BTW, without actually trying it, I see no reason that a Prop1 could not handle both the G-code interpretation and the machine control in multiple, linear- and circular-interpolated axes. I've done pretty much the same thing with an eight-bit, single-process controller (Zilog Super 8 ), programmed in Forth and assembly for controlling a four-axis mill.

    Well now...

    Just exactly what type of G-Code support do you think will fit?
    How many G and M codes will be supported?
    Will it include ramping and trajectory planning?
    Will the supposed fit include support for extruders and heated build platform monitoring, for 3D printers, or are we just talking about a milling and drilling application?
    Will there be any additional memory added for storage?
    What type of file or serial input are we talking about?

    Show me something besides an absolute bare bones application, without some type of additional memory scheme and I will be impressed :)

    It can't be done :) Any takers? :)
  • How many G and M codes does one machine tool actually need? I would wager just a small fraction of those that are defined. And what functions do they control? There's motion, both interpolated and non-interpolated, transit speed, spindle on/off/speed, program end, pause, tool change (if supported), and a few others. The G and M codes are just a hierarchy of abstractions above the basic machine control. I'm with Peter: Tachyon could handle all of these with ease. Spin/PASM, too.

    -Phil
  • Okay... I would have to agree to some extent. I do believe that with limited G and M command support, I think the P1 could support several different types of CNC machinery. However, I would have to say that I do not believe a robust 3D printer application will ever exist for the P1. Additionally, to have any real value to the marketplace, a P1 solution for CNC, should contain ramping and trajectory planning, as well as linear and circular interpolation.
  • jmgjmg Posts: 15,140
    edited 2017-06-12 06:26
    idbruce wrote: »
    Okay... I would have to agree to some extent. I do believe that with limited G and M command support, I think the P1 could support several different types of CNC machinery. However, I would have to say that I do not believe a robust 3D printer application will ever exist for the P1. Additionally, to have any real value to the marketplace, a P1 solution for CNC, should contain ramping and trajectory planning, as well as linear and circular interpolation.

    I'd tend to agree.

    The 'G-Code problem' is somewhat like the 'TV Remote control problem', there any one operational subset is not so hard, but when you want learning remotes and all standards, you find you need 128k Flash MCUs

    For someone wanting to start now, but with an eye to future P2, I'd suggest something like either
    P1 + Small FPGA - if the Project is hardware intensive
    or
    P1 + Small ARM (TQFP48) such as NUC505

    The latter pairing comes with 512k or 2M of FLASH, so could manage the outer layers of software, whilst the P1 manages the Axis.
    With C code running on the NUC505, later porting that to P2 should be relatively easy once silicon is available,
  • I have a different view on the need for Prop1 or Prop2 to crack the G code interpreter issue.
    G code is an absolutely basic STEM education concept.
    Every student who wishes to become competent in robotic control of CNC machines will soon be faced by G Code.
    I think G code should be incorporated into the small wheeled robots (ActivityBot, BoeBot)which Parallax pushes.
    There should be modules to control the motion of the wheeled robots (lines, arcs, repetitive actions) by interpreted G code.
    Incorporating G code into early robotics will be a winning strategy for the Parallax STEM education system.
    Later on in the STEM education the interpreted G code can be used for simple CNC machines.
  • David BetzDavid Betz Posts: 14,511
    edited 2017-06-12 11:25
    Show me something besides an absolute bare bones application, without some type of additional memory scheme and I will be impressed :)

    It can't be done :) Any takers? :)
    Peter is probably already nearly done with his Tachyon implementation and there will be space left over for a game of tick-tack-toe to keep you occupied while you're waiting for your print to finish.

Sign In or Register to comment.