New Dimension For Windows: Microsoft Puts 3D Printing Support Directly Into OS | Hacker News Reader

New Dimension For Windows: Microsoft Puts 3D Printing Support Directly Into OS

geekwire.com

In PC based CNC systems, there is almost always dedicated hardware separate from the PC that is feeding the motor drivers, because Windows and Linux are not true real time operating systems. A cnc system must have a timing resolution much finer than is available in traditional general purpose operating systems.

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?

It's easy to do realtime control on a linux box, simply run your program as root and disable interrupts. Every time you're 'safe' (stopped, or very low speeds) you can safely enable/disable interrupts to make sure all your hardware gets serviced and to poll for UI input. I've controlled a 3D mill/plasma cutter like this at very high speeds.

That's not going to sell a lot of units, though. Its hard enough to get a machinist to set up a cnc system with a full gui. You want him to disable interrupts on Linux? Just shoot me now.

No, you can use a GUI, you just need to do your polling when you know it is 'safe'.

I honestly don't have any experience with linux cnc. A lot of what forms my opinion is the controller's marketability. Many controllers do not ship with a PC, which is a great selling point on one hand, but a limiting factor on the other hand. If a controller came with, or just was itself, a dedicated host, and is the only supported host, then linux is definitely a viable option that doesn't create any barriers to entry. But if a company is simply building a controller, and requiring the customer to provide a PC, I see it as a no brainer business decision that the PC runs windows, and not linux.

Or, you know, use one of the half dozen RT variants of Linux.

What if 2 applications will do it?

> It's easy to do realtime control on a linux box, simply run your program as root and disable interrupts

If this were the case, how would the clock/time on the OS work?

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.

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

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/

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.

It is telling that I am more excited about Windows 8,1 than iOS 7.

I mean to me, all it indicates is Jobs and Hillel Cooperman were the only good benevolent product and aesthetic guys in the OS space.

This seems like it could be bad news - they might be trying to make some sort of proprietary 'postscript for 3-D' to lock down the whole industry. Though I'm guessing my worry is probably unfounded.

PostScript is a well-defined, well-documented programming language. Introducing a new layer for 3D printing would be very cool, but in the end, G-code is the "native" language for most of the hobby (and maybe other) 3D printers out there.

I didn't see any reference to G-code in the article. I think the worry is that they will introduce a closed, proprietary standard in an attempt to build their platform.

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.

This. G-code is more like Logo than PostScript. Something based on meshes and computational-computed surfaces (e.g. bezier curves) would work better. In fact, we could get most of the way there with OpenGL/DirectX at a low-level (meshes to specify a few vertex positions, hull shaders to to extrapolate additional vertices based on whatever algorithm you want).

OpenSCAD: http://openscad.org/

Its about as close to being a "3D Postscript" as you could find these days ..

That's the first thing that came to mind for me.

http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

Indeed - my cynical first thought was "so this is how they're going to implement DRM for 3D printers"…

I think this is excellent news (I am biased, I am working on a 3d printing startup). This will bring more awareness and accessibility to 3d printing to the masses.

> I am working on a 3d printing startup

What sort of startup?

p2p marketplace for 3d printing. http://makermarket.co

In practice, how is this different than simply being able to install a package? Furthermore, Ubuntu has 3d printing packages in the standard repositories, are we to believe this gives MS any sort of practical advantage?

Well mainly because all the decent 3d modelling packages run on Windows?

(Solidworks basically)

fedora 19: 100% 3D Printing Bring 3D printing tools to Fedora and allow users of 3D printers, such as RepRap, to be fully satisfied with software in the repositories, without having to download binary blobs or run Python code from git.

All of the big CAD packages (Solidworks, CATIA, Solid Edge, Pro-Engineer, Rhino, SpaceClaim, ...) are Windows only. Lately OSX has gotten some traction, but it's still pretty marginal.

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.

With this support embedded into the OS, now the NSA can get a direct report whenever you print a 3D gun part! Yay!

/I kid, they won't be real-time reports... Just batches.

Reply on news.ycombinator.com