G-code
David Betz
Posts: 14,516
in Propeller 2
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?
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?
Comments
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
Actually I will see if I can find that document now.
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
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.
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?
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.
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:
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
Let me state once again...
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
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.
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.
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
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!
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.
I would hate to have to use some kludgy USB to printer port solution for driving any kind of machine.
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.
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.
Try
It's a fairly complete list of gcodes for most 3D printer firmware variants, with a description of their use.
dgately
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
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
-Phil
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,
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.