Hacker News Reader

Comment by angersock | Hacker News Reader

Hm. I wonder if it exports G-code, or simply says "Hey, let's write some proprietary drivers! It'll be fun!"

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.

View on HN

You may be speaking too soon. Let's reserve judgement for after we know the details.

I'm a Windows dev at build, but I know nothing about 3D printing. If you can you give me an idea what G-code is, then I'll ask or look at the SDK.

G-code converts a 3D model into printing instructions for a 3D printer. http://reprap.org/wiki/G-code

No, it describes how to make an object with a CNC machine. I hadn't heard about G-code until 5 minutes ago, but from what I see, there is a huge mismatch between G-code and the way 3D printers operate. Who cares about the zillion times one has to cut away a piece of wood using a lathe to create a sphere if one uses a device that _adds_ material to the object?

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.

G-code is indeed an old language, but it's the industry standard because it's better than all of the alternatives.

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.

Yes, descibing a product in terms of motor signals will be tedious. That's why I think a good description tries hard to describe what must be produced, not how it must be produced.

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.

G-code describes movements and tooling parameters, it does not describe how to make an object with a CNC machine.

That's why you can use G-code both for additive and subtractive processes.

Well, let's look at it this way.

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.

That is how plotters work. Lookup HP-GL or DPML

>it is good that there is software that understands G-code for 3D printers, but using it as _the_ data format?

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.

G-code is a language used to describe the movement of a tool. I think the first uses were for cutting tools, like CNC lathes and milling machines.

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.

Think of G-code like PostScript. It's a description language that tells a multi-axis machine how to move in 3D space.

I was hoping for something a bit more vector based. G-code seems more like Logo than PostScript.

https://en.wikipedia.org/wiki/G-code

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

Heres some sample G-code:

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

Dramatic post for something you seem to know nearly nothing about.

And I may ask, what leads you to this conclusion?

Its dramatic lamentations over conclusions you've drawn apparently without basis.

I'm sorry, I assumed that it was common knowledge that getting printers setup, especially in a team or enterprise environment, was some of the fucking worst and most annoying work you'll ever run into in IT. That it was common knowledge that proprietary driver bundles and features and whatnot are the bane of any consumer, and that interoperability was a fucking joke beyond the most basic of printing features (if then).

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.

This non-technical article references a "print dialog" and you're ready to cry about how all of humanity is oppressed by our 3D Printed Future being infected by the Win32 print subsystem? Forgive me if I feel like this moaning would seem more relevant on Slashdot.

The bit relevant to me was this:

"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.

3d Printing needs as much software iteration as hardware iteration. G-Code generation/slicing algorithms don't receive enough attention IMO. I just tried finding the Skeinforge repo and came up empty [1]. :(

[1] http://fabmetheus.crsndoo.com/

Reply on news.ycombinator.com