The personal fabricator is a tool that does CNCing, 3D Printing, Laser cutting etc. This is the future that is envisioned in the book by Neil Gershenfeld: Fab, The coming revolution on your desktop - from personal computers to personal fabrication. Seeing as I am attempting to make a “personal fabricator” I have come to realize the limitations of using g-code in this machine (and g-code in general). Here are my points:
G-Code is not mass customizable: One of the big selling points of 3D Printing is mass customization. If the print is of a shoe, the end user must put in their parameters to get the right size. This would require a CAD program + STL Slicer to get the new g-code to create the shoe. Apart from the cost, there is the learning curve, just so that the person can enter Size 14, Wide.
G-Code has no verification logic: When you’re machining something for the first time, you have to measure it afterwards to ensure that it came out correctly. Since mass customization implies that every build of an item can potentially be unique, this means that it has to be measured to confirm that it was built properly. G-Code doesn’t appear to have native support for that.
G-Code is 50 years old: G-Code is awesome if you have to produce 50K of some on various machines and the process is standardized. For this reason it is a classic technology. Once personal fabricators are mainstream it will become old technology, replaced by whatever fancy new language that was developed for PFs.
G-Code has no logic: G-Code is not even a programing language so there is no support for instructions that need to be calculated. Take for example: If you have a 3D Printer with a 0.35 mm nozzle today and you upgrade to a 0.26mm nozzle tomorrow; technically you will have to rework all your G-Code files to obtain the higher resolution. As opposed to desktop printing where the image will just come out in the higher resolution. There is no thinking by the user that perhaps I have to redo my images to support a higher resolution.
These concerns arise from the fact that I need to implement a solution that can “interpret G-Code” and take the aforementioned problems into consideration.
So the question is: Is there a better language than G-Code that will satisfy most of those concerns?
Short answer is no.
the vast majority of cnc machines use gcode.
There is a new standard being touted stepnc but both are output from cad packages.
So the limitations you are talking about are cad not gcode.
Actually it looks like stepnc addresses point 2 already; allowing verification of the output. Looks like a better starting point that G-Code; thanks Justin.
Further, it seems that Step NC is based of a programming language called EXPRESS? Never heard of it though. If it is a real programming language then it takes care of point 1 and 4.
It’s all about where you move the computing to. You can tell the printer to build a sphere so the printer will have to compute all the point coordinates and the order the head has to go trough them (this is a lot of computational power), or you can do this on your PC and just tell the printer where to move the head.
@ Errol, (almost wrote error again) I’m going to write the slicer as well.
The slicer will be incorporated into the “printer”. If necessary it may require the compute power of a Rasbery PI or some Xmos chips but it’s gotta be done by the printer.
Truth #1: GCode sucks
Truth#2: GCode is supported by everything
A corollary would be #1: Ladder Logic sucks #2: Ladder logic is supported by everything
A second coronally would be #1 C++ sucks #2 C++ is supported by everything
This is simply the state of things. Most machine tools interpret GCode. Some types of machines, like industrial robots, do not as it would have been an unworkable solution. Consequently there are loads of different languages used to program robots and a few ‘standards’. While GCode is thought of as a ‘standard’, i.e. RS274, it certainly is not. Different companies that make CNC controllers do things in slightly different ways, they do this as a result of having to work around limitations over the years, Fanuc has emerged as the de facto ‘standard’, that means the way Fanuc does things is seen as the way to emulate.
There have been lots of attempts at developing a ‘replacement’ for GCode but to date all of them have fallen flat. Over the years NIST has put loads of money into trying to develop a ‘drawing to part’ concept that takes a 3D model that a machine tool can directly machine, basically skipping the CAM step, for 20 years or more it has been touted as just around the corner. (Of course it can and will never work )
For 3d printing and FDM machines, I believe the solution is a format based on image planes, not tool paths. The slicing would produce layered regions with color and f fill information and be drawn by a graphics engine. To my mind, the first problem is not so much the G-Code to move the tool head, but the common use of the STL format to describe the geometry. Most times, you go from model to stl to gcode. I would be looking at a new solution for the geometry - and I would be working on graphics based image planes.
@ Jeff_Brit, I don’t think C++ sucks. When these guys say just around the corner, they are talking in terms of 20 year spans, not year over year. Engineering is actually a slow process of building up classic technology.
@ Blue Hair Bob, Image planes would cause files to be come very large. Also, how would you specify the infil percent (e.g. 75% infil) if the model demands that you print everything?
I found another attempt at making better files: AML, which is more like STL 2.0. This format however is targeted to 3D printing as opposed to STEPNC’s target of Milling. The format that I’m looking for would allow a Laser cutter, a water jet cutter, CNC Mill, 3D printer or a stencil cutter to produce the required part. In the case of the 2D cutters, it would be possible to cut the layer out then have the user “glue” the layers together to make the 3D object.
Right, and another point: Also it would need to allow different machines to be able to work on the same part. For instance you know how 3D Printing can only produce parts with a certain corner radius? Well after you print the part you can apply a laser cutter to the corners to “square” them off. This would be awesome for press fit applications.
And then there is the scaffolding problem. (Sorry if this is disjointed guys). If you have a part that you are going to CNC Mill, but you need some way of holding it down. You can print the scaffolding to hold it down on a 3D Printer. Also, sometimes you need scaffolding to hold it up while printing. The part to cut and the parts that are the scaffolding need to be in the same file because the always go together.
@ kurtnell - C++ does suck, but it is very useful and very powerful, and it is universally supported so it will never die. They are ‘finally’ merging in ideas and libraries that have been around a decade or more (but with it being an international affair any change will be slow). ‘C’ was a great idea in its time, and C++ was built on top of C back in the day. Given its age there is all sorts of cruft left around that is just waiting to bite you in the butt. As I’ve heard programming language designers say, you can always add to a language but you can never take away. So over the years things get bloated as you still have to support 99.99% of everything that has ever been in C or C++.
GCode like C++ is long in the tooth, but it is supported everywhere and will likely never die.
Having said that I think vintage VW bugs suck too, but I love them. I’m under no delusion that they are anything even close to the quality and reliability of a modern car, but I love them
75% of what makes C++ suck is the backwards compatibility with C. As you imply, however, it is also this which gives it much of its appeal. The language designers have recently been making some changes to the language that make it much more appealing (see C++11, and especially the proposal for modules), but it will always and forever be a superset of C.
@ godefroi - You and I are on the same page. Understanding how a language got started and has evolved over the years helps you understand why it is the way it is at this point in time. Whether the language be C++ of GCode. GCode was originally a set of simple instructions that was read from a punch tape, there was never any thought or idea at the time to use variables, loops, conditional statements, etc. It was not possible on the machinery being used and it was not needed to get the job done.
After much mediation I have decided on what to do. I’m not going to create a standard; I’m going to leverage HTML5. My machine will work just like a web browser and execute JavaScript. The model data will be in the html description, and the JavaScript will be able to access it however the developer chooses. My machine will simple have 1 method in a new object that normal browsers don’t have: Machine.Fab
It’s signature is
public Vector Fab(Vector data, int tool, double mmS, string defaultResponse) {
throw new NotImplementedException();
}
public struct Vector {
int x;
int y;
int z;
int a;
int b;
int c;
string message;
}
The idea is that you send commands as if you commanding the tool as opposed to the machine. so you send the position information via x,y,z, as well as the rotation information on a,b,c (for 6 axis machines). The message is an optional message that you can send to the tool. So if you send a message to tool1 and then send a message to tool2, the machine will automatically move to change the tool, return, then process the message. Once the operation is complete the “tool” returns with it’s current x,y,z,a,b,c position and an optional message. Adding a ! symbol to the front of the message will tell the machine to wait on the tool’s ready signal, as opposed to the tool waiting on the machine’s ready signal (i.e. make tool the master and the machine the slave). When the tool is master it can command the machine to stop. This will return in the command returning. This is how measurement tools can return measurements to the JavaScript.
With a few simple code changes I can put in an xml webservice to process the command effectively allowing anything to command the machine.
The tools will setup by the operator (user) prior to the commands being run (naturally) and the html file (which would be able to give descriptions of the tools required as necessary) will guide them. the file extension by default will be DOT FAB (.fab).
This arose after looking at the other attempts at making a new specification were doing. It seems that the 2 camps were separating (Additive vs. Subtractive manufacturing). This divide adversely affects my machine’s design. If I follow those “standards” the machine will end up with a split personality.
The string defaultResponse is the default response that the program is expecting from the tool. This is needed so that simulators can verify what the effect of running the program will have on the material being machined (or added).
The double mmS is Milimeters per Second.
There will be simulators that can simulate the effect of running the commands. They can be adapted to respond with the coordinates based on random deviations, however they will not know what the tool should respond with. Only simulators will respond with the contents of defaultResponse.
)