Towards printer-independent GCode

To address the issue of the way forward - having gcode that can print on any printer is IMO NOT the way forward. Having the slicer built into the 3d printer is.

Compare it to paper printers, you feed them something to print in standard format, the printer figures out the toolpaths required to print it.

The only reason we had separate slicers was to allow a PC to do the heavy lifting that 8 bit arduinos couldn't do. Now it's possible with 32bit controllers or raspberry pi's to just chuck an stl at your 3d printer. Since the slicing settings that work best for any given printer and material are specific to that machine they should be pre-programmed into the printer. Sure you can have some profiles, fine, normal, draft, etc..

Surely the ideal is when we want to print a 3d object which we get in standard format stl, obj we chose a printer and pick a quality setting and press print and then a few hours later a green light comes on and we open the printer door and take the object out.

Since the firmware we use now are for enthusiast machines, not truly consumer printer maybe the bridge is that using some built in calibration objects and a "unified calibration routine" the firmwares first job in a new machine is to walk the user through setting it up, determining the optimum slicing settings in the process,using objects to test the various variables, bed adhesion, dimensions, cooling etc.. After that you just hit print.

Edited 1 time(s). Last edit at 01/06/2018 05:18AM by DjDemonD.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

Or better still, cut out the stl and feed the printer the raw mesh

STL isn't far of a raw mesh. It's a bit of a crappy format given today's computing power, even on raspberry pies. There's no information on shared vertexes. The only information is a huge sequence three coordinate sets. Most stl object handlers that I've worked with post process the files with assumptions to try and rebuild the connectivity information.

I get the impression this would be an easy task as at least Slic3r is driven by external programs such as Repitier.

I'd draft it in python and use the exisiting slic3r config files to set it up.

Edit: Not suggesting ditching STL at the same time, just discussing its a format born in a time of much reduced pricessing power. We could do netter now.

Edited 1 time(s). Last edit at 01/06/2018 06:41AM by WesBrooks.

Quote
DjDemonD
To address the issue of the way forward - having gcode that can print on any printer is IMO NOT the way forward. Having the slicer built into the 3d printer is.

Compare it to paper printers, you feed them something to print in standard format, the printer figures out the toolpaths required to print it.

The only reason we had separate slicers was to allow a PC to do the heavy lifting that 8 bit arduinos couldn't do. Now it's possible with 32bit controllers or raspberry pi's to just chuck an stl at your 3d printer. Since the slicing settings that work best for any given printer and material are specific to that machine they should be pre-programmed into the printer. Sure you can have some profiles, fine, normal, draft, etc..

That assumes that the generation of appropriate support material can be done fully automatically, perhaps with a few user-definable parameters. Is automatic support generation good enough for that yet?

Quote
DjDemonD
Surely the ideal is when we want to print a 3d object which we get in standard format stl, obj we chose a printer and pick a quality setting and press print and then a few hours later a green light comes on and we open the printer door and take the object out.

Yes, that's the ideal.

Quote
DjDemonD
Since the firmware we use now are for enthusiast machines, not truly consumer printer maybe the bridge is that using some built in calibration objects and a "unified calibration routine" the firmwares first job in a new machine is to walk the user through setting it up, determining the optimum slicing settings in the process,using objects to test the various variables, bed adhesion, dimensions, cooling etc.. After that you just hit print.

There are already 3D printers aimed at consumers out there, and I expect to see a lot more soon. RepRapFirmware isn't only aimed at enthusiast machines, it's used in industrial 3D printers too and may soon appear in consumer machines. The problem I am trying to address is that whereas the firmware configuration parameters depend largely only on the printer and filament and not on the model, the slicer parameters depend to some extent on the model too, e.g. support generation, number of shells, and percentage infill.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Maybe this a machine learning issue, maybe we can teach a narrow AI system to look for problem areas in a model. There's no doubt that auto support generation is okay, slic3rPE does it very well, but not as good as custom generated support by an experienced operator. But it's not rocket science or black magic. If software that allows custom support learned from each user placed support structure which types of models need it and where to place it the problem would be solved in most cases.

In fact the more I think about it the more it seems like the answer, I recently read a book which claims the business plan of the next 10000 successful companies will be "add AI and await results". Maybe a cloud slicer app programme which crowd sources the knowledge of which models need which settings.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

Quote
WesBrooks
STL isn't far of a raw mesh. It's a bit of a crappy format given today's computing power, even on raspberry pies. There's no information on shared vertexes. The only information is a huge sequence three coordinate sets. Most stl object handlers that I've worked with post process the files with assumptions to try and rebuild the connectivity information.

I get the impression this would be an easy task as at least Slic3r is driven by external programs such as Repitier.

I'd draft it in python and use the exisiting slic3r config files to set it up.

Edit: Not suggesting ditching STL at the same time, just discussing its a format born in a time of much reduced pricessing power. We could do netter now.

You are obviously far more knowledgeable about these things than I am. I was just kind of thinking along the lines of how I perceive CAD\CAM to work. AFAIK, the model is created on some piece of software which is then fed directly into some sort of multi axis machine that produces the part. Or is that too simplistic an understanding of how the process works?

Edit. I use OpenScad so it would be pretty handy if I could design something on that, and tell the printer "make me one of them".

Edited 1 time(s). Last edit at 01/06/2018 09:19AM by deckingman.

Quote
WesBrooks
STL isn't far of a raw mesh. It's a bit of a crappy format given today's computing power, even on raspberry pies. There's no information on shared vertexes. The only information is a huge sequence three coordinate sets. Most stl object handlers that I've worked with post process the files with assumptions to try and rebuild the connectivity information.

I get the impression this would be an easy task as at least Slic3r is driven by external programs such as Repitier.

I'd draft it in python and use the exisiting slic3r config files to set it up.

Edit: Not suggesting ditching STL at the same time, just discussing its a format born in a time of much reduced pricessing power. We could do netter now.

Simplicity really is key, and the simplicity of stl means it has amazing backwards and forwards compatibility. CAD formats are quite infamous for being extremely proprietary, bad compatibility, bad support, or just dissapearing entirely.

For general modelling and CAD use this isn't important, but it's a strong concern of academics to chose a format that will survive the years despite simplicity. Stl fits the need incredibly well, even if it does have some compromises. The databases of thingiverse are here to stay forever because stl is just so damn compatible with everything.

The slicer needs to know the printer to gen the code

A 3D printed circle is a bunch of segments
designated in the CAD program

Printer independent language

Some CAD / CNC can define arc -- center point, radius, degree of arc
Thus printing at resolution of printer

GRBL commands
Arc IJK Distance Modes: G91.1

Quote
WesBrooks

Quote
cozmicray

the 3D printing world needs a type of language to move forward

I don't follow the argument you are making? Can you explain another way?

STL (Stereolithography) and gcode files (adapted from nc machine control) are exactly that?

I suspect the open source efforts for laser sintering and projector based systems use different files.

Move outside open source and each vendour will have its own (often binary) formats for build objects, slice data, and parameter sets.

I’ve read this entire thread, and I agree with a lot of what others have said, which are different thoughts than the original poster.

First, a little about my background, to set the proper context:

In my past, I worked on CNC controller software for Hurco CNC machines. At the lowest level, you can submit CNC Gcodes to the machines and they”ll work accordingly. Even then, they haven’t sold entirely identical capability machines. A major selling point/marketing feature for Hurco machines is referred to as “conversational programming” which is most easily compared to Logo turtle graphics/programming for machining: rather complex parts can be readily defined with procedural/declarative programs that are far more easily understood than raw gcode. In fact, it doesn’t require someone proficient in gcode to read and see what the program will do, fairly readily, even if the machine didn’t do a nice 3d rendering of the described output result. Hold onto these points, I’ll build on them.

About the time I started working at Hurco, I was also modeling things with POVRay, a 3d ray tracer, fully source. The description you feed in via declarative code defines lots of materials/system properties that have context. It’s pretty easy to read and write and get great results.

My next employment oversll in the field was at Kubotek USA, makes of KeyCreator, formerly sold as CadKey. A key detail of CadKey/KeyCreator is that it’s a parametric modeling system, and you can script it readily to define and modify things more readily than using a history-based model like a large percentage of CAD systems. I was hired there largely as a side-effect of the CNC experience at Hurco, because KeyCreator has largely focused on the mold creation area, and that’s often done via CNC, so one of the selling features of KeyCreator is taking input KeyCreator CAD files and generating efficient CNC toolpaths.

Now, for my more recent and relevant background, outside of 3d programming in various manners: I support Windows developers in the Windows SDK, which includes several cmparable things for higher-level graphical description languages than gcode is the equivalent of in the PC realm. For example, with GDI you can describe things with EMF (Enhanced Metafiles) which you can replay on any machine, whatever its capabilities, as it works with DIBs (Device Independent Bitmaps) which does the translation as needed according to device limitations from/to ideals. There are more modern types as well for printers for the same reason. Device drivers are responsible for implementing the low-level machine language from the higher-level language/specification, and they utilize higher-level context for that translation into device outputs.

Gcodecas we have it now is optimized for the low-level machine, and is machine-specific in its nature: I submit that this lowest-level machine language is the most ideal level of abstraction for the task, for more than one reason:

1. Easy to step through and debug at the lowest machine movement/operation level. I have experience with deep debugging of machine code to base this on, sometimes you need low-level details.
2. Requires minimal resource usage to process, not just in file buffers, but also RAM for complex processing on the printer’s microcontroller.
3. Easier to do interpreter->motion control computations than a higher-level representation would give.
4. The interpreter and motion control code can readily fit within the flash/eeprom of affordable controllers.
5. It can be readily extended to address special features of machines not currently known, without requiring everyone support it. Admittedly, this is both good and bad!

There are likely other things I forgot.

STL is, like CNC gcode, a descriptive format but it’s even more limited than gcode: it has no real context, and it doesn’t even have units! It’s an overly-simplistic description language for geometric shapes. It gives no hints as to intent, doesn’t do more than 3d triangle coordinates, doesn’t communicate things like tolerances, or, for example, that a large series of triangles are intended to be a nice smooth curve that should be rendered at best quality of the device. STL really wasn’t designed with machining in mind: its intended purpose is incompatible with efficient/effective gcode generation, regardless of the gcode interpreter and the machine limitations due to lacking too many concepts. It needs to be abandoned wholesale, as it’s 3d machine code for the wrong kind of machine.

A rasonable question as to why you would wish to create a universal gcode for 3d printers is related to why output to STL is the norm, and also asks why you’d want to create an entirely new standard. After all, the great thing about standards are that there are so many to choose from

STL has a long history, and a large part of its popularity is how simple the definition of the format is. That’s also its greatest defect, because it’s way too simplistic for machining/3d part definition. With gcode, you can say “do a curve, best quality” where STL doesn’t even have that concept, as one example. However, 3d printing has largely focused around taking output from CAD software that’s in the form of STL and then reinterpreted to gcode, because it’s fairly straightforward, as flawed as it is, to generate something thst will likely work. The result is you end up with slicers that havecto look at an absurd number of points and try to reason about them to optimize things with insufficient context, and then use parameterized templates for gcode output for different machines: converting one overly-simplistic and limited machine language to one that’s richer, but it’s not easy to use that at max effectiveness due to lack of context from STL: things are literally getting lost in translation and rotation ()

So, here’s the thing: a universal gcode would hamper progress on machine improvements, and history shows that where a current language specification doesn’t support a new feature, the language gets special extensions for various vendors. This is something that happened with 3d programming APIs (OpenGL) extensions. Therecis one positive thing to say about STL: it’s so standardized and so simplistic, that 3d definitions really can’t be misinterpreted for the low-level geometry: the higher level a language is, the more wiggle room there is for divergence of meaning with implementations. Gcode already has enough of that, and I recognize that as the reason for your quest.


With my background, it’s very visible that what you wish to do will require huge changes and huge development throughout the entire path from human having an idea to translating it into a 3d manufactured part you can (in theory) use any device with a large enough build volume to fabricate. It’d be comparable to recreating something already standardized for the objective, that has a lot of industry support: see here: 3d printing universal specification

No question, getting this universally used still requires a huge amount of work for various parties, but it at least doesn’t require every printer designer/manufacturer to rip up their existing designs and add needless complications in software and more expensive hardware justcto make a universal machine language for 3d printers, or catering to the lowest common denominators of functionality.

I think it's obvious that we should let designers specify formally how an object is supposed to be manufactured. I'm in favour of the most low-level and hackable solution possible. I think portable gcode is a good candidate. For example E3D's tool-changer demonstrated that gcode is low level enough to be used flexibly (combined with RRF macros), and enable machine improvements instead of hampering them.

I do run the same gcode on different machines already, even if results are sub-optimal, just to save time and effort. I would absolutely love to be able to move the machine specific parts of my slic3r.ini over to the firmware config, and get better results with the gcode sharing that I'm already doing.

Even more so, I would love to be able to use my friend's sliced gcode. I constantly end up wasting time and plastic (but not effort) compared to him, because he puts more effort into his slicing.

I do not agree that the required changes are huge. On the contrary. The suggested changes are small and straight-forward, and they would go a long way. I think we better get going with talking to slicer maintainers and/or presenting some successful portable prints.

Parts of this thread feel like the discussions that were had in the GNU/Linux-communities before package managers became a standard thing. Those who participated in the discussions already loved gcc, make, and bash, they didn't crave for one-size-fits-all pre-compiled binaries. Today those binaries are compiled and packaged by specialists who successfully make computing much more accessible to the general public. Computer users are still free to compile for themselves, but very small fraction of them are interested.

I think pre-sliced objects can play a similar role for manufacturing after a few years of refinement. Letting a few people slice for many people would be an upgrade of the whole 3d-printing community, and extend our reach. We would help us standardize our machines and collaborate more efficiently.

Some prior discussion here: forums.reprap.org/read.php?1,705311

---

torbjornludvigsen.com