In general terms, a cnc system must convert high level instructions, like G-code, in to voltage pulses that are fed to either stepper or servo motors.
Some of these calculations are performed on the PC, others are performed on the dedicated hardware. Do steps 1, 2, and 3, send step 3's result over usb to the controller, then perform steps 4 through 10.
Not everyone agrees where to place that barrier.
In the case of GRBL, which is the firmware that runs most of these hobbyist level 3D printers, the entire process happens on an 8 bit microcontroller, from G-code to steps.
Other cnc systems perform almost all of the calculations on the PC, and sends a representation of the timing information to the controller.
Still other systems decode the G-code into vectors and other intermediate representations, and let the controller do most of the heavy lifting.
Some systems transmit their data over USB, a standard ill equipped for industrial environments or cable lengths more than about 10ft. Others use ethernet. I'm sure there are others that use RS-485, or even proprietary protocols.
Is Microsoft accounting for any of these variations, or are they going to standardize everyone to whats popular today, which is usb and 8 bit microcontrollers that can't even create 50,000 steps per second?
If this were the case, how would the clock/time on the OS work?
For once--for once--we had a chance to break away from the lowest pit of IT hell: printing.
We could have done something beautiful, we could've made the world a better place--and yet, I fear that Microsoft is now just going to extend the failures of 2D printing into the third dimension, quite literally piling on layers of sadness.
N10 G00 Z0.25000
N20 G00 X0.00000 Y0.29975
N30 G01 Z-0.50000 F2.00
N40 G01 X0.00000 Y1.03725 F5.00
N50 G02 X1.12000 Y1.03725 I0.56000 J-0.37323
N60 G01 X1.12000 Y0.29975
N70 G02 X0.00000 Y0.29975 I-0.56000 J0.37323
N80 G00 Z0.25000
N90 G00 X0.00000 Y0.00000
N100 G00 X1.5200 Y0.29975
N110 G01 Z-0.50000 F2.00
N120 G01 X1.5200 Y1.03725 F5.00
N130 G02 X2.64000 Y1.03725 I0.56000 J-0.37323
N140 G01 X2.64000 Y0.29975
N150 G02 X1.5200 Y0.29975 I-0.56000 J0.37323
N160 G00 Z0.25000
N170 G00 X1.32000 Y0.668625
N180 G01 Z-0.50000 F2.00
N190 G00 Z0.25000
N200 G00 X0.00000 Y0.00000
The N field is a line number and is disregarded
The G field describes the motion type. G00 is a rapid line.
G01 is a feedrate line. G02 and G03 are arcs, one CW, the other CCW.
The X, Y, and Z fields describe geometry
The F field is the feedrate, or the tool's speed
Yes, it is good that there is software that understands G-code for 3D printers, but using it as _the_ data format? Ridiculous. That would be as if one used plotter instructions to print in 2D; instead of "here is a rectangle; fill it with pure red", one would have zillions of "move pen to x,y; draw to x,z; move to x,y+0.01; draw to x,z+0.01; move to x,y+0.02,…" instructions.
Also, I don't even think G-code is that good of an idea for generic CNC files. Suppose your file says "use a 10mm bit", while your CNC machine only supports bits up to 5mm. You can sort-of emulate the larger one, but it will be inefficient and lead to lower quality cuts.
There are complex G-codes, such as threading, which allows you to define the pitch, thread depth, cutting style, the distance to move away from the material between passes the distance to cut the thread, etc. But a lot of G-code files do consist of thousands of discrete lines.
The reduction of a 3d shape to motor signals will eventually come to a stage that deals with lots discrete vectors, regardless of how you represent the data, G-code or not. G-code files consisting of thousands of lines are usually created by a CAM software anyways, not by hand.
Your strawman argument of a 10mm bit when only a 5mm bit is available extends to just about any type of standardized process that consists of instructions being evaluated.
And yes, it applies to any process that consists of instructions. Again, that's why I think that is a bad way to describe a 3D object for a generic printer interface.
That's why you can use G-code both for additive and subtractive processes.
People don't really write G-code anymore, it's generated from a 3D model. G-code is like the compiled version of the model made for execution on the printer.
>Also, I don't even think G-code is that good of an idea for generic CNC files
Why make such a ridiculous assumption when you just said you heard about this only 5 minutes ago? You're making a blanket statement about a technology that's been around for more than 40 years based on 5 minutes of googling.
Having a language which simply describes the movement of your tool through space is nice--there is less chance that a later vendor decides to add overrides to your "red rectangle" to be more of a blue circle.
There is also much less chance for hardware vendors to screw up their implementations and introduce incompatibilities: move this bit here, at this speed. It makes the firmware much simpler, and makes the shelf-life of files much longer.
It seems to be a pretty good solution, though with not as great a shiny factor as others.
It describes things like movements of a tool on linear or rotational axis, cutting tool rotational speed, operation of auxiliary equipment (heater on/off), etc.
The first implementation of high level numerical control programming language was developed at the MIT Servomechanisms Laboratory in the late 1950s. The main standardized version used in the United States was settled by the Electronic Industries Alliance in the early 1960s. During the 1970s through 1990s, many CNC machine tool builders attempted to overcome compatibility difficulties by standardizing on machine tool controllers built by Fanuc. Siemens was another market dominator in CNC controls, especially in Europe.
Numerical control (NC) is the automation of machine tools that are operated by abstractly programmed commands encoded on a storage medium, as opposed to controlled manually via handwheels or levers, or mechanically automated via cams alone. Most NC today is computer numerical control (CNC), in which computers play an integral part of the control. G-code is the common name for the most widely used numerical control (NC) programming language. There are other codes (Letter addresses which span the entire alphabet); the type codes can be thought of like registers in a computer. Some letter addresses are used only in milling or only in turning; most are used in both. Bold below are the letters seen most frequently throughout a program.
A Absolute or incremental position of A axis (rotational axis around X axis)
B Absolute or incremental position of B axis (rotational axis around Y axis)
C Absolute or incremental position of C axis (rotational axis around Z axis)
D Defines diameter or radial offset used for cutter compensation. D is used for depth of cut on lathes.
E Precision feedrate for threading on lathes
F Defines feed rate
G Address for preparatory commands
H Defines tool length offset; Incremental axis corresponding to C axis (e.g., on a turn-mill)
I Defines arc center in X axis for G02 or G03 arc commands. Also used as a parameter within some fixed cycles.
J Defines arc center in Y axis for G02 or G03 arc commands. Also used as a parameter within some fixed cycles.
K Defines arc center in Z axis for G02 or G03 arc commands. Also used as a parameter within some fixed cycles, equal to L address.
L Fixed cycle loop count; Specification of what register to edit using G10
M Miscellaneous function
N Line (block) number in program; System parameter number to be changed using G10
O Program name
P Serves as parameter address for various G and M codes
Q Peck increment in canned cycles
R Defines size of arc radius, or defines retract height in milling canned cycles
S Defines speed, either spindle speed or surface speed depending on mode
T Tool selection
U Incremental axis corresponding to X axis (typically only lathe group A controls) Also defines dwell time on some machines (instead of "P" or "X").
V Incremental axis corresponding to Y axis
W Incremental axis corresponding to Z axis (typically only lathe group A controls)
X Absolute or incremental position of X axis. Also defines dwell time on some machines (instead of "P" or "U").
Y Absolute or incremental position of Y axis
Z Absolute or incremental position of Z axis
I figured it was also plainly obvious that the article suggests strategic partnerships creating this support, which very strongly indicates that the print support will be either some gnarly plug-and-play driver nonsense or weird stilted API defined by Microsoft.
I'm rather fond of the current "give me g-code I'll emit parts" model, as it is very open and hackable.
EDIT: By all means, downvote me. We all know printing sucks.
"The company is announcing the new feature this morning, working with partners including MakerBot Industries, 3D Systems, Afinia, AutoDesk, Netfabb and others."
So, are those nice folks on a standards body? Or are they each going to be putting forth a model where they supply drivers that somehow convert .obj or .stl models into whatever makes their printers happy?
The current solution works so well precisely because it isn't all locked up in goofy proprietary formats and comm methods.
I don't want you to think I'm an anti-Microsoft zealot here; I'm just making the completely reasonable observation that this could be a repeat of all the nonsense that we've had to deal with from 2D printers.
A better announcement would've been "Microsoft pushes for open standard for 3D printer communications, supplies open-source reference driver and API". Then again, that's still not as simple and useful a solution as old G-code.
I'm a bit conflicted. On the one hand, G-code is very compatible with the open source ethos, but on the other it's a very old standard that was originally intended for plotters. I'd love to see something better replace it that can say, use bezier curves.
Its about as close to being a "3D Postscript" as you could find these days ..
What sort of startup?
There are translators (e.g. SolidWorks -> STEP, SolidWorks -> STL) that run on Linux, but the better ones, and the ones that support the proprietary formats (SolidWorks, CATIA, etc.) all cost money and couldn't be included in a Linux distro's software repository.
So even if Linux supported 3D printing out of the box, it wouldn't be as useful as if Windows did, IMO.
/I kid, they won't be real-time reports... Just batches.