Originally shared by Josh Rhodes
I hope we can get to work on this future sooner rather than later
#3dprinting #modeling #3d #slicers
The slicer needs to be an integral part of the cad program, and be capable of communicating with the printer to determine the capabilities of the printer. Gcode needs to disappear and be replaced with something more powerful. Controllers need to become much more powerful. STL needs to disappear. We’re using old technology and standards because it’s convenient and already adopted.
@Stephanie_A I’m all for the changes that you’ve said.
As long as we are still using open and well documented file formats.
Too many man hours have been burned down at the altar of closed file formats.
@Stephanie_A Whats wrong with Gcode? I have programmed CNC’s with it for years. It’s simple precise and easy to read. There is macro programming for cnc’s and while it is powerful it is very cryptic and hard to read and harder to debug. Then you get into conversational controllers. In some ways they are easier for simple projects but very proprietary. Ever machine is different. Many times you have to lie to the machine to get it to do what you want. It’s a real pain in the ass. Gcode is so much easier and portable between machines.
That’s like saying we ought to dump HTML! When the original HTML no longer was sufficient, it was marked up. I’d imagine the same should happen to STL and there’s no reason why not.
Stl is a standard that would be impossible to change into the format we need it to.
Gcode doesn’t work well for 2 way communication, and each controller has its own standard of gcode. 3d printers are NOT cnc mills, get that out of your head. That’s like saying a 2d printer should use gcode, wasteful and limited. A mill uses considerably less commands than a 3d printer, and has considerably less complexity in how it works. You have different nozzle sizes, materials, temperature, flow rates, and layer heights. Gcode is dumb, you send a printer a command assuming that it is capable of completing that command. Two way communication is necessary. The slicer needs to know the capability of the machine. What’s its absolute accuracy, how fast can it move and accelerate, how much does it ooze, what is the die swell, how big is the build plate, what is its shape.
Right now we keep adding the same features and settings to the firmware and the slicer. Go ahead and take a look at how many features you will find defined in the firmware, then find the same features in the slicer. It’s stupid, redundant, wasteful, and prone to error. It should be defined once, and used everywhere. It’s like building a new software library from scratch each time you use it.
Just because it works doesn’t make it good or ideal. The reprap Darwin worked, why did we ever deviate from it? Why not stick with one design and standard? Because often it doesn’t suit the purpose. The entire maker movement is built upon not being content with what exists.
@david_merten html is a special case. It’s a subset of xml. See this… http://www.xmlobjective.com/what-is-the-difference-between-xml-and-html/ xml can be used to describe anything including other languages (I guess I’m an enormous geek because I always found xml interesting).
It does seem like any cnc motion can be described by gcode, but it’s extremely tedious and makes certain assumptions which may not be advantageous. Dumping it ouright wouldn’t be right, but possibly revisiting the assumptions could make all machines work better.
@Stephanie_A it sounds like we need a printer description file format. I think the easiest thing would be a file that lives on the printer, hook up the usb and the slicer can grab the file.
Personally I think 2d printers need the exact same thing.
And other peripherals as well.
2d printers have printer drivers and sophisticated controllers, we don’t have that luxury with most being controlled by 8bit mcu’s that have the amount of memory of a 1988 computer.
@Stephanie_A I’m sorry you missed my point, a driver (right now) is very very very specific. It’s for a particular OS a particular version of that OS, its 32bit or 64bit and sometimes even specific to a program.
My idea is: A generic hardware description. One that lives embedded within the device, once its plugged in the computer can transfer it over (i.e. usb thumbdrive) then the OS would have a generic driver for all printers for example that would input those parameters to work with this specific model. No driver downloads, no figuring out which driver.
How different are a dozen different 2d printers? What about 3d printers?
Sorry it’s offtopic.
We should talk more about how to develop the future 3d printing descriptors.
I think that the assumption that a cnc (or 3d printer) is just a dumb machine is the first assumption that should be thrown out.
There should be a baseline bottom end, but it should be higher than the current low end, which assumes the machine can only handle one move at a time.
Perhaps we should send the machine geometry instead of coordinates and let it work out the coordinates. Kinda like an SVG.
I’m doing away with GCode (eventually)!
My firmware will handle material properties such that it can adjust extrusion temperatures to compensate for feed and/or flow rate changes. This means that adding extrusion quantities to individual commands is redundant. The firmware will be aware of what it is printing e.g. normal lines, infill, bridging lines etc. so that it can adjust extrusion parameters within limits set by specification not arbitrarily set within a slicer.
The slicer, which I believe should still be separate from the CAD program, will generate output based on nozzle diameter, layer height, line width, interior density and material choice. It doesn’t know (or care) about extrusion and bed temperatures - profiles held on the printer manage those aspects. I would argue that slicers should be associated with the printer control application so that slicing may be configured based on the needs of the job or production requirements.
My aim is to develop an object-based protocol to represent information passing from the slicer to printer. This protocol will not be ASCII because it’s daft to convert floating point to/from ASCII just for transmission over a medium - even more so when storing it on pluggable media. Floating point formats exist so use them interchangeably at both ends. Also I want to extract data from the buffers in which they are received. Translating from buffer bytes into some variable format is wasteful. Objects are self-aware and can represent themselves as needed within a system.
On the subject of CAD formats I agree that STL will become limiting. We do still have the choice of AMF for multi-material printing and it would be better to pursue that rather than invent another format.
I really don’t think it helps to have the slicer built into the CAD program so much. I don’t care so much what the machine runs but I would want it to be standardized. We’ll get better results if the slicer can take in STEPs or other open solid format and output NURBS code. Faceted interchange file formats are annoying.
Seems to me that OS developers (Apple, Microsoft, Linux) really need to be involved to standardize. The sub systems of the OS is what is used for consolidating device types. Even if the language remains the same, the interface can then be standardized and one could select from a list of 3D Printers (I prefer the term Fabricators) in the same way we select from a list of printers today. The Fabricator driver would be configurable the same way that printer drivers are today. The Fabricator driver, either open source or provided by the manufacturer or a close printer would then take the place of the stand alone slicers today. In fact, it would just be a slicer encapsulated as a device driver that would interface with the specific Fabricator.
@Greg_Nutt I don’t see 3D Printers being integrated into the OS. In the future I would expect them to work with cloud resources and likely they would be accessed discretely using something like IPV6. I see more effort going into this sort of interface than making machines look like a conventional PC peripheral.
I think I’d have to disagree. The technology still is in its infancy and using limited methods but that will change. The plug and play method will rule when the masses can buy their own fabricator at Walmart and not have the technical know how to do anything other than plug it in and feed it. Sadly, most computer users have trouble just with the concepts of file management or installing drivers. Keeping it to a standardized interface will at least help make it familiar.
@Neil_Darlow Remember, there is no cloud. It’s just Someone Else’s Computer
That sounds terrible for several (to me) obvious reasons. Internet connection problem (no internet no print), too many middle men, the server being down…it goes on and on
With that trend before long we won’t be able to play solitaire on our computer when the internet is down.
@Greg_Nutt My paradigm would suit that. Connect your printer to the home network, browse an online 3D product catalog and place your order then have the model delivered to your printer for manufacture. There is no need to have the printer intimately tied to your computer.
Internet shuts down suddenly, instead of half a file you have half an object.
@Josh_Rhodes So you try again or, better, buffer the whole object before printing.
I don’t buy into the “What happens if the Internet disappears?” argument.
We are reliant on the Internet these days. You need to get your printable models from somewhere and the Internet is good for that.