Towards printer-independent GCode

There has been various discussion in the past about making GCode files that would be suitable for printing on a wide range of FFM printers, with different materials, so as to reduce the need for users to slice every STL model themselves. So I thought I would summarise where we are, and say what more I think needs to be done, to avoid the slicer having to know much detail about the printer.

1. Coordinates to print at. The slicer needs to know the coordinates of the centre of the bed, so that it knows where to centre the print. The obvious solution is to always make the centre of the printable area X=0 Y=0. This is almost universal on delta printers already. For other types of 3D printer, some (perhaps most) firmwares already allow you to define where X=0 Y=0 is.

2. Retraction settings. All modern firmwares and most slicers support firmware retraction using G10/G11 codes. So not a problem.

3. Speeds. Travel speeds should not be an issue, the slicer can use very large values and the firmware will limit them according to its maximum speed settings (M203). Printing speeds are different. One option is to have the slicer use standard speeds for each type of printing move (external perimeter, other perimeter, solid infill, interior infill, bridging) and then use a speed multiplier on the printer. A better solution would be for the slicer to indicate what type of move is being made. One way of doing this is that for G1 printing moves, instead of providing an F parameter to specify the speed, we would provide a different parameter, perhaps T, to specify the move type. For example, T0 = skirt, T1 = external perimeter, T2 = other perimeter, T3 = solid infill, T4 = other infill, T5 = bridge. Add 8 to indicate first layer, or 16 to indicate top layer.

4. Print cooling fan settings. If we provide move type information in G1 commands as I suggest above, the fan setting for each move type can be configured in the firmware instead.

5. Temperatures. Commands such as M109 and M140 could be modified to accept a layer number as an alternative to a temperature. Then the firmware would be configured to specify the temperatures to be used for the material being printed.

6. Start and end scripts. Macro calls (M98) can be used to call the start and end scripts, instead of embedding the scripts in the slicer output.

7. Layer height. This is one that the slicer obviously needs to know. But lots of people use standard layer heights, typically 0.2mm, so we can still achieve a fair degree of portability.

8. Nozzle size and filament diameter. Volumetric extrusion makes extruder coordinates independent of filament diameter. It also makes it independent of nozzle size over a small range, e.g. the same GCode could provide for printing with either a 0.4mm or 0.5mm nozzle. I think the vast majority of users use 0.4mm nozzles.

9. Coast-to-end and similar. Not needed if the firmware supports pressure advance.

In summary, we must accept that the slicer needs to know the required layer height and the approximate nozzle size. However, by implementing a couple of new GCode features, we could have slicers producing GCode that can be used on a wide range of printers with similar nozzle sizes. I have a Cartesian printer with a 0.5mm nozzle and delta and Scara printers with 0.4mm nozzles, and these could potentially all use the same GCode files.

Is it worth doing? Have I missed any important information that the slicer currently needs to know about the printer?

Edited 1 time(s). Last edit at 01/03/2018 08:41AM by dc42.

---

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

Out of curiosity, what is the drivng force behind trying to develop printer independant gcode? Most people like to tweak things like speeds, shells, infill etc from print to print. Either for time or strength requirements. Another thing you'd want to know is print volume size, if the printer can physically print the object, but maybe I'm missing the point of what you're asking.

I personally wouldnt look for pre made gcode, I often at the very least tweak infill if not layer height and temperatures. I usually find myself trying to print fast either to iterare quickly or because I'm impatient. Or is your suggestion to make a more universal slicer that doesnt need so much configuration?

How about making gcode post processors to modify settings? As we step into more elaborate printing, these post processors are quite useful anyway.

Personally, I'm not sure i see the need for gcode rather then .stl files. If settings are a problem then shouldn't we be looking to make hardware advances that eliminate settings? Eg, bed levelling to eliminate z Offsets and other first layer settings.

What does gcode solve, other then to make a set of problems across many machines? Well dialed in machines don't require us to change many settings before slicing anyway. Further to this, we actually have to set up our machines to accept gcode files (eg, changing the xy co ords to be at the center). Alot of faff for something that is *almost *equivalent to an stl file, but actually more limiting (can't edit gcode easily to add new parts, but an stl can imported into mesh mixer etc)

Edited 1 time(s). Last edit at 01/03/2018 09:18AM by Origamib.

You can tweak printing speed on the printer itself already, and my proposal would allow you to tweak the speeds for different types of move independently on the printer - just as you can in the slicer. But if you want to change the number of shells or the infill, then you are right, you would need to re-slice anyway.

My motivation is partly to allow me to use the same GCode on all 3 of my printers, partly to allow me to use the same GCode with different materials (assuming I am happy to use the same number of shells and infill with all of them), and partly to reduce the amount of slicer configuration I have to do when switching printers. S3D is especially bad at maintaining multiple printer profiles.

As to whether the print fits on the bed, it wouldn't be hard for the firmware to scan the first layer of the GCode file to make sure it fits on the bed before printing it, or even scan the entire file. RepRapFirmware already has a simulation mode.

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

---

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

Quote
Origamib
How about making gcode post processors to modify settings? As we step into more elaborate printing, these post processors are quite useful anyway.

Post-processors have their uses, but to modify settings correctly they need to second-guess the type of move being made.

Quote
Origamib
Personally, I'm not sure i see the need for gcode rather then .stl files. If settings are a problem then shouldn't we be looking to make hardware advances that eliminate settings? Eg, bed levelling to eliminate z Offsets and other first layer settings.

Many settings - in particular, appropriate speeds - are very dependent on the machine.

Quote
Origamib
What does gcode solve, other then to make a set of problems across many machines? Well dialed in machines don't require us to change many settings before slicing anyway.

That's only true if you already have the slicer settings dialled in for your machine and the filament type you are using. You may still have to configure support, and perhaps have one or two failed prints before you get it right.

Quote
Origamib
Further to this, we actually have to set up our machines to accept gcode files (eg, changing the xy co ords to be at the center). Alot of faff for something that is *almost *equivalent to an stl file, but actually more limiting (can't edit gcode easily to add new parts, but an stl can imported into mesh mixer etc)

Sure, if you want to modify the model, you will need to start from the STL model or whatever it was created from. But for a new user who doesn't yet understand slicing very well and just wants to print something, it would be easier if he/she could just download a GCode file which already has the support in the right places, and isn't tied to that particular make/model of 3D printer.

Edited 2 time(s). Last edit at 01/03/2018 09:29AM by dc42.

---

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

I like the idea of what you are proposing, but in an ideal world the GCode is too lower level to be particularly portable.

While we're on the topic of gcode I agree the G1 codes should be largely parameter independant and point to a header section of the file that lists parameter info to use in the absence of machine defined overrides or ensure there is a default safe set of parameters that the machine falls back too. That way if new features are added to slicers that result in new parameter set then the build doesn't crash, but falls back onto default values.

In addition g1 comands should belong to a particular part. Being able to set up an experimental arrat and kill parts that were looking bad was a big help on other machines.

Back to my original commment preparing the gcode on advance was really a hang over from low computer speeds. I'd like to see a higjer level of buold file that bundled stl files and parameter imformation, but did not necessarily contain g code. Again this would make repeat builds with tweaks easier. Perhaps I've missed that feature.

With regards to g-code being too lower level my main comment here is you are ssuming that you extrusion widths are suitable. In reality these mods are only goimg to make the files more portable between different material extrusion machines that are very similar, ie same nozzle diameter. Perhaps the slice data should be a contour and leave the co-ordimate definition to a post processor? It would be fairlybeasy to tie a raspberry pi to a duet to slice on the fly from a higher level nuild file wouldn't it?

Edited 2 time(s). Last edit at 01/03/2018 10:03AM by WesBrooks.

Honestly this sounds like a rather large undertaking, you not only need to implement the changes in firmware, but you also will need slicer support no?

There also should be some concern regarding standardization as well. Contacting other key developers in the 3d printer community at large (other firmwares, slicer developers etc.) to reach consensus on a standard would promote adoption. Otherwise you risk just creating a fragmented feature that is limited to the specific firmware and slicer you add it to (RRF and Slic3r I assume?).

I do think simplification of the toolchain to get a printer printing would help lower the barrier of entry to the technology. Greater adoption is a good thing overall.

I'm running 4 different printers and a CNC mill. All printers have different nozzle sizes, because for me it's the biggest hassle to change the nozzle and recalibrate the z-probe. I don't see a benefit in unified gcode. I also slice a part many times with different perimeter width settings to find the best match.
Another thing is file size. Why should I download a much bigger gcode file instead of a .stl? Perhaps from a shady place, who could hide "anything" in a text file?

I'm assuming you can get slic3r to chuck out slices on demand. Were they ran like this in the past via serial before complete build files were uploaded? Difference now is arduinos are being blended with computers, perhaps this needs consideration for the third generation of Duets? Perhaps an add on card as it'd significantly increase board cost and complexity.

Generic add on is probably best as it's more likely to be adopted across the community.

Edit: Cleaned up phone typos.

Edited 2 time(s). Last edit at 01/04/2018 12:21AM by WesBrooks.

Quote
dc42

Quote
Origamib
Personally, I'm not sure i see the need for gcode rather then .stl files. If settings are a problem then shouldn't we be looking to make hardware advances that eliminate settings? Eg, bed levelling to eliminate z Offsets and other first layer settings.

Many settings - in particular, appropriate speeds - are very dependent on the machine.

Quote
Origamib
What does gcode solve, other then to make a set of problems across many machines? Well dialed in machines don't require us to change many settings before slicing anyway.

That's only true if you already have the slicer settings dialled in for your machine and the filament type you are using. You may still have to configure support, and perhaps have one or two failed prints before you get it right.

Quote
Origamib
Further to this, we actually have to set up our machines to accept gcode files (eg, changing the xy co ords to be at the center). Alot of faff for something that is *almost *equivalent to an stl file, but actually more limiting (can't edit gcode easily to add new parts, but an stl can imported into mesh mixer etc)

Sure, if you want to modify the model, you will need to start from the STL model or whatever it was created from. But for a new user who doesn't yet understand slicing very well and just wants to print something, it would be easier if he/she could just download a GCode file which already has the support in the right places, and isn't tied to that particular make/model of 3D printer.

Support can be included in the .stl as well and gcode support does not take into account all the settings around support structures such as first layer settings (completely dependant on your build surface), speed and layer seperation at the interface between print and support (usually defined by material, temperature and layer height).

If your aim is to make it easier for first time users, then solid printer and material profiles for the slicer are needed. I rarely need to mess with my slicer these days. This is mainly because I only print with a few different brands, and what I do regularly use is highly dialed in to my printer.

If the gcode file does not print you would have to analyse the gcode in a simulation or text file, if my slicer goes wrong I analyse settings in an easy to read interface. The problems that surround thingiverse stl designs would be a lot more frustrating with gcode. For example, not only do you have to deal with modeling errors and bad designs but you also have to deal with the settings they impose in the gcode.

Quote
dc42
Have I missed any important information that the slicer currently needs to know about the printer?

Number of extruders. I'm thinking that when I slice a multi part, 5 colour object, things don't go well when I change to my 3 colour hot end (been there, done that). Also the additional tool change commands in a multi colour gcode file would certainly play havoc if I tried to print the same file with a single extruder configuration. In a similar vein, I tend to put the operating and standby temperatures for each tool and filament in the start gcode but things go wrong if I only set it for 3 tools but then try to print with a 4th (been there too, done that too). Conversely, setting operating and standby temperature for 5 tools leads to error messages when I only have a 3 tool config.g (been there as well).

Z hop? You might want to do it on say a light and nimble Delta but perhaps not with a printer that has a large, heavy and therefore slow Z axis.

Nozzle size, I think you touched on it but I'm thinking big nozzles, like 0.9mm and upwards. I've never tried volumetric extrusion so can't make any sort of comment. Using that, is it possible to have a single gcode file that would print with both a 0.5 and a 0.9mm nozzle? How would the firmware know to slow the print speed to 1/6th of normal? With my big 0.9m nozzle I use 0.7m layer height but with the 0.5mm I use 0.3mm. Difficult to imagine how I could use the same gcode file.

Just some thoughts.

I have to say that it would be useful to only have to slice things once. I currently have 3 diamond hot end assemblies that I switch between - 0.5mm 3 colour, 0.9mm 3 colour and 0.5mm 5 colour and I'm think of adding a single E3D V6 or similar. So effectively 4 quite different printer configurations but sharing the same frame, axes, gantrys etc.

I have to say, am I missing something? Is slicing something people don't like doing? I find it is not an excessively annoying part of my tool chain.

S3D slices very quickly allowing me to rapidly see which settings are best... Often I will change settings such as perimeters, overhang speed and infill. Sometimes I will even change infill based on layer height to save on filament.

I honestly think that bigger gains are to be had by simplifying your slicing routine. Dialing in material profiles for me means that the majority of models without support or overhang can be imported to slicer, checked over and sent to my printer in only a few minutes. A gcode file still has to be imported into software and checked over before printing. Where are the gains? To me, gcode files are like the 'basic' settings of S3D and that is already a feature of every slicer out there.

Quote
Origamib
I have to say, am I missing something? Is slicing something people don't like doing? I find it is not an excessively annoying part of my tool chain.

Not so much missing something. Wasn't it nice when you could press the on button on your computer and have enough time to brew a cuppa tea properly before it was ready to do anything? It takes Slic3r far laess time to slice a average layer than it does the printer to print it so why wast time doing ot in advance? Add a cache space and you can be making a buffer of a few slices up in case a few were really quick.

While this is little benefit if you have a well honed system running the same material day in day out if you move builds between machines or frequently change materials then the increased ability to change things on the fly can really hasten the development process.

Edited 1 time(s). Last edit at 01/03/2018 05:16PM by WesBrooks.

Think what I was suggesting wasn't too clear.

1) New build file to include mesh data, scaling, offset, and rotation translation information for the mesh files (copies of the same part to run from the same data), and part/build process parameters.

2) Processing of the build file to happen concurrently to the machine starting a build process. The concurrent slicer to process as many slices as possible and store them back to a section of the build file.

3) Raw gcode fed into the main driver card as required via serial or local network connection.

4) Repeat build processes don't need repeated slice caching if no changes are made to the build or part parameters.

5) People who don't use this slice on the fly can still use this build object as a convenient way to record all the details of a build including the original mesh data. Setting a full advance slice would just pre-cache the slices to the build file and these could be extracted as a raw gcode file to run in the existing manner.

Edited 1 time(s). Last edit at 01/04/2018 12:44AM by WesBrooks.

Quote
Origamib
I have to say, am I missing something? Is slicing something people don't like doing? I find it is not an excessively annoying part of my tool chain.............

All true. The only thing I can say is that with the multiple hot end options that I have (3 colour, 5 colour, 0.5mm, 0.9mm etc), I end up with a lot of duplicated gcode files which were generated from the same stl, and that I have to add an identifier to the file name so that if I want to repeat a print some time later, I pick the hot end for the gcode file that I want to use. So in a way it would be useful not to have to do this but as you say, it's not a huge issue. Sometimes I have forgotten to add an identifier to the file name so don't know which hot end configuration I used when I sliced the object. But it's no big deal to load the stl and slice it again while the bed is heating up.

Quote
deckingman

Quote
Origamib
I have to say, am I missing something? Is slicing something people don't like doing? I find it is not an excessively annoying part of my tool chain.............

All true. The only thing I can say is that with the multiple hot end options that I have (3 colour, 5 colour, 0.5mm, 0.9mm etc), I end up with a lot of duplicated gcode files which were generated from the same stl, and that I have to add an identifier to the file name so that if I want to repeat a print some time later, I pick the hot end for the gcode file that I want to use. So in a way it would be useful not to have to do this but as you say, it's not a huge issue. Sometimes I have forgotten to add an identifier to the file name so don't know which hot end configuration I used when I sliced the object. But it's no big deal to load the stl and slice it again while the bed is heating up.

It seems to me that this and multiple machines are the only legitimate use for gcode files. This only affects a tiny proportion of the market though, and if we are really after changes to make first time printing easier there is other low hanging fruit to consider

Quote
Origamib

It seems to me that this and multiple machines are the only legitimate use for gcode files. This only affects a tiny proportion of the market though, and if we are really after changes to make first time printing easier there is other low hanging fruit to consider

Quite agree. For example, I'd much rather see slicers that can generate true arc moves as supported by G2\G3 commands, rather than chopping them up into short segments.

I'd like to see slicers generating true arc moves too. But given that the input STL file doesn't have curves in it at all, only planes, it's a difficult job for a slicer to reconstruct an arc from a series of line segments. And then the firmware will turn it back into line segments anyway. So unless you can find a compelling reason for making gcode files smaller, it's hard to see what the benefits would be.

The slicer feature I suggested would be very easy to implement, because the slicer already knows what type of move it is generating.

---

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

Quote
dc42
........................ And then the firmware will turn it back into line segments anyway. So unless you can find a compelling reason for making gcode files smaller, it's hard to see what the benefits would be........................

Oh. I thought G2 and G3 were for doing true arcs as single moves. If the firmware chops these G2\G3 single arc move commands back into multiple small segmented moves, then yes it's pointless. I was rather hoping that doing an arc as a single move would get around the jerky movement problem pressure advance causes with small segmented moves and prevents me from being able to use it.

Quote
deckingman
Oh. I thought G2 and G3 were for doing true arcs as single moves. If the firmware chops these G2\G3 single arc move commands back into multiple small segmented moves, then yes it's pointless. I was rather hoping that doing an arc as a single move would get around the jerky movement problem pressure advance causes with small segmented moves and prevents me from being able to use it.

At some point those arcs have to be chopped up into steps for the motors to move so...

The benefit is just to make the gcode more concise and as a bonus the files would become much smaller.

Also, what firmware are you using?

Edited 1 time(s). Last edit at 01/04/2018 04:20PM by obelisk79.

Quote
obelisk79
The benefit is just to make the g code more concise and as a bonus the files would become much smaller.

Use a binary file format if you want them smaller. Readable formatting is a huge waste of disc space. Giving the user the ability to adjust coordinate data in the slice file is wasted effort as you'd need a program/script to to much real world build file edits and the original data (such as bounding contour for a hatched area, or raw contour for a perimeter trace) has long since been lost and so even the scope of machine level editing is limited without some serious processing to recover most likely degenerated contour or surface data.

G-code at the moment is serving two purposes and doing neither ideally. 1) Machine readable command file. 2) User readable and editable file.

Edit: Maintaining readable files for development is always helpful, but nothing prevents a GUI being generated to view and edit binary data.

Edited 2 time(s). Last edit at 01/04/2018 04:29PM by WesBrooks.

Quote
obelisk79


Also, what firmware are you using?

Duet - latest version. The issue I have with pressure advance is that it cleans up prints nicely when running at high speed but makes arcs jerky and curves become faceted. It's because I run a mixing hot end and use 3 or 5 extruders concurrently. Something to do with the gcode processor not being able to fill the movement queue as fast as the motion system empties it apparently.

Quote
deckingman

Quote
obelisk79


Also, what firmware are you using?

Duet - latest version. The issue I have with pressure advance is that it cleans up prints nicely when running at high speed but makes arcs jerky and curves become faceted. It's because I run a mixing hot end and use 3 or 5 extruders concurrently. Something to do with the gcode processor not being able to fill the movement queue as fast as the motion system empties it apparently.

It's much more likely to be because there are too few facets, so the angle between adjacent segments is too great to permit speed to be maintained without violating the jerk limits.

---

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

Quote
dc42

Quote
deckingman

Quote
obelisk79


Also, what firmware are you using?

Duet - latest version. The issue I have with pressure advance is that it cleans up prints nicely when running at high speed but makes arcs jerky and curves become faceted. It's because I run a mixing hot end and use 3 or 5 extruders concurrently. Something to do with the gcode processor not being able to fill the movement queue as fast as the motion system empties it apparently.

It's much more likely to be because there are too few facets, so the angle between adjacent segments is too great to permit speed to be maintained without violating the jerk limits.

David,

I was just quoting from your final words on this lengthy thread [www.duet3d.com] which were

"So I think I've worked out what is going on. When there is a sequence of short moves such as in an arc, the gcode processor may not be able to fill the movement queue as fast as the motion system empties it, especially if it is having to compute and generate step pulses for 5 extruders. If the queue contains insufficient moves to do full lookahead, then the segments in an arc have to be scheduled to slow down at the end, to ensure that the motors can stop if new moves are not added fast enough. When large amounts of pressure advance are used, this causes the extruders to retract filament at the end of the move. This retraction increases the number of steps that must be generated, which further increases the load on the processor. So if the machine gets into a state in which the gcode processor can't quite keep up with the mechanics of the machine and starts doing jerky movements, pressure advance will increase the load on the processor and make the situation worse."

You then went on to say

"Here are some possible solutions/workarounds:

- Reduce printing speed
- Use larger segments in your arcs (lower $fn value in OpenSCAD)
- Use fewer extruders
- Use lower pressure advance
- Use lower microstepping, which will reduce the number of steps being generated. Are you using the default x16? If so then you could try x8 on the extruders, especially if you are using the 0.9deg motors that E3D supply for the Titans.
- If you are using 0.9deg motors on your extruders, use 1.8deg motors instead. It may be worth using 0.9deg motors in ungeared extruders, but for geared extruders like the Titan I doubt that they offer any advantage.
- Make the firmware more efficient at generating steps and/or processing gcodes. The step generation is probably as fast as I can make it already, but I may be able to improve the efficiency of gcode processing. The 1.20alpha series should be faster than 1.19 already.
- Make the firmware reduce printing speed automatically when underrun is imminent
- Use a faster processor (but we will have to wait for the Duet N^2G for that!) "

So as I already use 1.8 degree steppers then I use low pressure advance - i.e. none at all, and of course of necessity, lower speeds.

Ian

The progression in ink printing was
dot-matrix
Ink-jet
Laser
and greater and greater resolution
Printing at the resolution of the printer not the display device

Postscript was developed to provide the language for this.
(first device-independent Page Description Language (PDL),)

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

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.

Edited 2 time(s). Last edit at 01/05/2018 03:29AM by WesBrooks.

Quote
cozmicray
The progression in ink printing was
dot-matrix
Ink-jet
Laser
and greater and greater resolution
Printing at the resolution of the printer not the display device

Postscript was developed to provide the language for this.
(first device-independent Page Description Language (PDL),)

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

But in each step in the progression, different technologies were employed too. To move forward, we need more than just language. Personally I think out robot controlled hot melt glue guns have just about reached the limits and are rapidly approaching the end of their life cycle.

Quote
deckingman
But in each step in the progression, different technologies were employed too. To move forward, we need more than just language. Personally I think out robot controlled hot melt glue guns have just about reached the limits and are rapidly approaching the end of their life cycle.

What will take it's place?

I mean, people have been saying magnetic hard drives were at their end of life for over ten years now and yet the tech keeps being refined and improved upon. While SSD's are certainly superior in many regards, traditional HDD's certainly remain relevant in todays world of computing. Why would FFF printers be any different? The technology still isn't fully mature in my opinion.

Edited 1 time(s). Last edit at 01/05/2018 10:19AM by obelisk79.

Quote
obelisk79

Quote
deckingman
But in each step in the progression, different technologies were employed too. To move forward, we need more than just language. Personally I think out robot controlled hot melt glue guns have just about reached the limits and are rapidly approaching the end of their life cycle.

What will take it's place?
.......................................

SLA, Jet Fusion, Nano Particle Jetting, CLIP, APD, CBAM, DMLS, or "other TBA". Take you pick. Just take a look at the world of high end additive manufacturing. Sooner or later one or other of these technologies will filter down into the consumer market. When laser printers first came out, it was only large corporations that could afford them and they were only mono printers to start with. I now have a colour laser sitting on my desk at home that didn't cost me much more than an inkjet.

Ones perception changes with age and I'd guess I'm probably a bit older than you. You mention hard discs but I can remember when computers only had floppy drives - big 8 inch ones at that. (In fact, I can remember when only large businesses had computers - the PC hadn't been invented). Then there were 5 inch floppies that everyone thought was pretty cool, then 3.5 inch in a hard plastic shell - wow!. Then lo and behold, along comes the hard disc but SSDs are starting to become a lot more affordable. It's just a matter of time.

When I was child, my parents had a gramophone that played vinyl records (their parents had only ever seen wax cylinders on a phonograph) When I was teenager, I had an 8 track cartridge player. When I was in my early 20s, we had stereo cassettes, then along came CDs, then music DVDS then people found you put music files on flash drive and now nobody bothers with any of that stuff - you just stream it.

Trust me, in not many years our super modern all singing printers will look like typewriters.

It's the pattents that are a big issue. Pattents expiring are what triggered the material extrusion printer reprap boom. Revent pattent expiries have seen the projection vat photopolymerisation technologies fall into the relms of the open source world. Likewise there are open source laser powder bed fusion technology projects now. Main issue is that stops these being mainstream is the cost of the equipment required. Lasers aren't cheap, and many of the high end technologies need atmospheric control, most metals systems need argon, plastics get by with nitrogen.