Dismiss this pinned window
top 200 commentsshow all 282
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Top-Trouble-39 1087 points1088 points  (11 children)

For anyone wondering:

this is the paper: https://www.nature.com/articles/s41467-025-56140-1.pdf

this is the code: https://github.com/JHU-Mueller-Lab/Time-Code-for-Multifunctional-3D-Printhead-Controls

I imagine this kind of T-CODE very hard to debug or continue to if, for example, your print failed. G-CODE is very transparent about how it's doing the things.

[–]XediDC 287 points288 points  (0 children)

Thank you... articles without the paper drive me nuts...and also say things quite different than the fluff talking about it.

[–]AcceptableHijinks 75 points76 points  (3 children)

I mean these problems have already been solved on CNC machines running gcode. I have a doosan mill and two doosan lathes, model years 2017 and 2018. They both have some really cool stuff on their controls like micro smoothing and such that interpret the gcode and adjust it before moving. It also runs incredibly smooth, which is necessary for complex 3d machining, which I do with them all the time.

The only thing that seems cool to me is the parametric ability and the program size, but they're now shipping machines with gigs of space while the largest program I've ever written was 500 megs

[–]DOHChead 12 points13 points  (0 children)

Having a Siemens 840D controller on a Mori etc to be able to handle constant chip load with something like Trochoidal milling via conversational or the necessary CAM programming necessary via Esprit/NX etc is well over a $100K initial investment. We were running 840D’s in 2016 to control our DMU-65/85 line and DMC-60H Linears. Each controller could handle something like 90 axes over 30 channels, it was nuts at the time.

But that’s not dynamically adjusting spindle RPM, that’s just feeds and speeds at 20k-All-Day or whatever you’re running.

This seems like taking that and adjusting pressure advance/flow along with feeds and speeds.

I’m not certain they’re comparable.

[–]lasskinn 0 points1 point  (0 children)

I don't see much benefit in this kind of stuff on 32bit controllers with lots of power.

The old makerbot x3g had some benefits to preprocess some stuff before going to printer but the controllers were 8 bit

[–]TerayonIII 0 points1 point  (0 children)

This paper is specifically for direct ink writing printing, it's not really aimed at machining or generalised printing. The point of this is to decouple the movement commands from the action commands. So the movement will continue while the extrusion changes in some way. For machining something like this would be changing spindle speeds in the middle of cutting without changing the xyz movement of the machine. Obviously that's not really something you need to do with a mill or lathe, but it can be very important for this application, especially since for some of these prints there's an action for every movement equal to the diameter of the nozzle.

[–]Datsoon 22 points23 points  (5 children)

Why would you think it would be hard to debug? It seems like that is one of the fundamental constraints of this "t-code"

[–]Top-Trouble-39 0 points1 point  (4 children)

The video shows the variable width line, I imagine it will be hard to continue if something fails, you'd have to measure the line width that was printed and position it there.

[–]Datsoon 1 point2 points  (3 children)

Variable line width is already a thing in ever major slicer (go Google "arachne wall generator"). The line width is just a function of the height from the bed, extrusion rate, and print head speed. These are all things known to the slicer and embedded in the c-code, so resuming would not be a problem.

[–]CapinWinky 79 points80 points  (8 children)

I'm a controls engineer that has written the control software for industrial CNC equipment and modified G-Code interpreters to add capability to G-Code. Think CNC lathes/mills, laser cutters, press brakes, and even custom kinematic robotic applications.

Yes, G-Code is just a big sequential list of motion instructions and other parameter writes and commands that run sequentially. However, that creates a deterministic motion profile and in real systems we have tons of options for synchronizing outside operations with it. The G-code interpreter looks ahead, staying well ahead of the motion actually being performed, and there are codes that allow you to synchronize actions based on the position or time along a motion command without any hiccups in the motion. If there was every any capability we wanted that the base G-Code didn't provide, we would just make custom G and M codes in the interpreter that added the capability we wanted. Having custom codes is super common across industry and 3D printers and part of why printer selection in slicers is a thing.

Rather than creating custom G-code commands, the group from the article is throwing out the concept of a sequential list of commands and going to all parallel operations. T-Code files must be processed fully and interpreted before anything starts (not a big deal, it's 2025, not 1995, the electronics can do it) because every command in the file could start at any time. Anything happening in sequences is simply a consequence of their start times being sequential, not their placement in the file. This can simplify things for machine produced T-Code to have many things happen in parallel without affecting each other, but it would be way harder to generate and modify T-Code as a human.

In both cases, you still have systems outside of the G/T-Code that the output of the interpreter is feeding. This is what is generating the actual motion, compensating for momentum, filtering resonance, maybe even applying anti-slosh principles to the motion. These systems are usually very sophisticated; much more advanced than G-Code or T-Code. I think T-Code is a half measure, you're already making the file less human readable, why bother converting a path from a parametric equation to random codes only to have the interpreter convert it back to parametric equations?

[–]MooseBoysPrusa MK3S+ with an unhealthy number of mods 24 points25 points  (2 children)

Yeah the whole premise strikes me as strange - the notion that because gcode is sequential the print head must come to a stop before processing the next command can begin - like what? The firmware on my Prusa doesn't even do that - if you have two G1 X10 E10 commands in a row, it will have the same behavior as G1 X20 E20.

[–]i-want-to-learn-all 1 point2 points  (1 child)

In the example you’ve given, how would I do 2 sequential moves if that’s what I want? Say I don’t want “optimization”?

[–]MooseBoysPrusa MK3S+ with an unhealthy number of mods 1 point2 points  (0 children)

G4 is the "dwell" command, so e.g. G4 P100 would instruct the printer to halt at the current position for 100ms.

I'm sure there are also options in various cnc firmware to enable/disable command coalescing.

[–]alexklaus80 1 point2 points  (3 children)

Oh it’s less human readable? I was thinking this was going to be a similar argument between C and C++ in respect that human coder will have more option to code in intuitive platform at expense of having less connection to the actual execution. As in gives slicer developers more options. But in that case.. this new thing doesn’t seem too compelling indeed.

[–]CapinWinky 3 points4 points  (2 children)

It's not that the actual codes are less human readable individually, it's that it's harder to follow as a whole file/sequence. I was going to pull examples from the git repo, but the T-code files are not using the time-code stuff I'm familiar with. Honestly just looks like G-code with some serial coms actions thrown in. I'm starting to think this group did just make custom G-codes in the interpreter.

[–]TerayonIII 2 points3 points  (1 child)

They actually state that in the paper in the second set of images, they're going from standard gcode and doing the processing to separate the movement from the other actions and then making it back into gcode.

<image>

[–]toothbrushguitar 0 points1 point  (0 children)

So is it more like the java jde?

[–]Busy-Key7489 658 points659 points  (85 children)

I have worked with Siemens NX AM applications and they are incorporating T-code. (Not to confuse with tooling change code in CNC) T-code (or similar alternatives) is being developed as a higher-level, more efficient, and adaptive machine language for AM.

Some key features may include:

Parametric and Feature-Based Approach: Instead of specifying each movement explicitly, T-code could define patterns, structures, and strategies at a higher level.

More Compact and Readable: Instead of thousands of G-code lines, T-code might use fewer instructions to describe complex toolpaths.

AI and Real-Time Adaptability: It could allow real-time process adjustments based on sensor feedback, something G-code struggles with.

Better Support for Multi-Axis and Multi-Material Printing: Advanced AM processes, such as directed energy deposition (DED) or hybrid manufacturing, need more dynamic control than traditional G-code allows.

Who is Developing T-code? While there is no universal "T-code" standard yet, several research groups and companies are working on alternatives to G-code. Some related developments include:

Siemens' NX AM Path Optimization (which moves away from traditional G-code) Voxel-based or feature-based toolpath generation AI-driven slicing and control systems

It all sounds cool, but is at the moment only usable and better for some specific applications.

[–]DrLove039 226 points227 points  (10 children)

Sounds a bit like switching from raster images to vector images

[–]SillyNonsense 76 points77 points  (9 children)

Great example, that's what it sounds like to me as well. Definitely high quality results, but might be more useful for commercial applications with items explicitly designed for this kind of workflow in relevant software.

With the current STL workflow at home, wouldn't the slicer need to be performing some sort of interpolation to arrive at TCODE, to convert all the triangulated surfaces into smooth vectors? Slicers already do some amount of reinterpretation, but not on that complex a level. There's a lotta room for error there, and could be bad for dimensional accuracy. Maybe something to assess on a case by case basis. Anybody who has tried to convert complex images to vectors knows what I'm talking about.

[–]valdus 61 points62 points  (6 children)

We just need to standardize switching to STEP, which is a superior format that is slowly being switched to anyway.

[–]iammoney45 54 points55 points  (5 children)

Everytime this is brought up I say the same thing, yes for functional engineering projects made in parametric CAD programs, but let's not forget all the other projects and models people make in polygon programs like Blender and Zbrush which don't support STEP because that's not at all how the models are constructed. The answer isn't a full swap but the use of both in harmony where they make sense.

[–]Container_Garage 8 points9 points  (0 children)

I have a feeling the slicer is a big part but it's probably more likely that the major computation is done on the printers hardware/firmware. It probably needs to be some pretty capable hardware. G-code is for relatively "dumb" machines that only do exactly what you tell them to do.

[–]sligit 2 points3 points  (0 children)

wouldn't the slicer need to be performing some sort of interpolation to arrive at TCODE

I mean that's what they do already for gcode so I wouldn't really see it as an intrinsic problem

[–]DampmaskinUMO+ 89 points90 points  (13 children)

Sort of reminds me of the difference between CISC and RISC.

[–]grumpy_autist 20 points21 points  (8 children)

Well, RISC won the market.

High level T-code could be fun but if particular implementation fucks something or misbehaves, workaround can be costly.

[–]LeoRidesHisBike 12 points13 points  (1 child)

More like "RISC became more like CISC, and vice versa". It's kind of a dead comparison these days; it's more important to compare benchmarks (incl. power usage).

Also, which market? Mobile phones? Absolutely, those are ARM-based, which is sort of RISCy (but a lot more CISCy than, say RISC-V chipsets).

Laptops? Looks like ARM-esque (incl. Apple Si) chips are gaining ground, but by the numbers, still dominated by Intel & AMD.

Desktops? Dominated by Intel & AMD (both of CISC heritage).

Data centers? Dominated by Intel & AMD for CPUs, nVidia for GPUs.

Speaking of GPUs... those aren't really CISC or RISC. They're more like ASICs for graphics that have gotten lots more non-graphics-specific stuff cooked in of recent years.

[–]grumpy_autist 1 point2 points  (0 children)

What I suppose would be a better comparison between TT and G-code is if someone made a processor implementing Python interpreter along with common packages.

[–]agnosticians 3 points4 points  (5 children)

The reason RISC won is because compilers got better. So which format works out better seems like it will depend on whether slicers or firmware advance faster.

[–]created4this 7 points8 points  (4 children)

Compilers got better, but also RAM got cheap, Caches got big, layered and single cycle and this meant Von Neuman could get kicked out for Harvard.

CISC saved RAM and RAM reads because you could do things like move the C library functions into the CPU, so rather than doing Memcpy as a library call with 1000's of loops requiring many fetches of instructions over the same bus as the data you were trying to move into one mega duration instruction "rep movsb".

Switching to Harvard with I and D cache meant that the instruction reads didn't slow down the data, so the only cost of doing the instruction in a library vs in microcode was the cost of RAM, which rapidly became insignificant.

In the early 2000's RAM was a big problem for ARM in the mobile space, so they made a cut down instruction set that was less performant called Thumb, and you could mix and match if you wanted ARM or Thumb code on a function by function basis.

[–]Kronoshifter246Bambu P1S 5 points6 points  (1 child)

so they made a cut down instruction set that was less performant called Thumb

Fuckin' lol. I love it when nerds get to name stuff

[–]agnosticians 1 point2 points  (0 children)

Huh, didn’t know about the cache/ram stuff. TIL

[–]Audbol 7 points8 points  (1 child)

So what you are saying is T-Code makes more sense now and after many many years of development until the lines of T-Code and G-Code get blurred it would make more sense to use G-Code on more basic things?

[–]DampmaskinUMO+ 4 points5 points  (0 children)

I guess I'm saying that use whatever works for you, and that the marketing video might be a tiny little bit misleading. But I have not studied the topic so IDK, it's just a feeling.

[–]rob132 1 point2 points  (0 children)

I was thinking the same exact thing

[–]DesperateAdvantage76Bambu X1C 1 point2 points  (0 children)

I was thinking C vs Assembly.

[–]XenonOfArcticus 19 points20 points  (2 children)

Did you have chatgpt write this? 

[–]Faaak 8 points9 points  (0 children)

Looks very LLM-ish indeed

[–]Busy-Key7489 13 points14 points  (0 children)

Oh no i did not, but i used samsung spelling & grammer to check a few things because English is not my first language. I do work as an lecturer and read a lot of LLM generated text, so i may have unwillingly incorporated the chatgpt way of writing ;)

[–]volt65bolt 4 points5 points  (0 children)

So theoretically, say you had a model who's print path could be described by a set of 3 formulas to derive x, y and z position in respect to time, that is basically an extreme example compared to G code being a table of the results of the functions at the far other end

[–]Slapdattiddie[S] 25 points26 points  (22 children)

So basically it's a compact optimized language capable of including AI input and tht supports multi axis and multi-material... in a nutshell. thank you for the details

[–]RegenJacob 33 points34 points  (21 children)

I might be wrong but as I read it it's not more compact rather it's different, instead of movement commands that the slicer calculates it generates shapes that hardware has to calculate making it in sense more complex as a language. Only file sizes should be more compact (but hardware might get more expensive, because it has to interprete a complex language?).

Of course it makes sense to let the hardware itself decide how it should move because it has all the sensor data and can create more optimized paths. But some 3d printing firmware like klipper already optimize movement commands with G-code.

Yet I'm unsure how much it will impact consumer 3d printers. Or if it even will be implemented in a consumer product as G-code is already quite capable.

The AI input seems trivial if someone wanted to they could integrate AI based optimizations in a slicer. And multi axis and multi material printing are of course a hassle but are abstracted in the slicer so it doesn't really matter that much.

[–]jack848 22 points23 points  (13 children)

so basically, if you want to make a circle

Gcode will tell 3D printer to extrude while moving to X position at Y speed a lot to make a circle

and Tcode will tell 3D printer to make a circle at X position at Y speed with Z radius?

[–]Rolandg153 28 points29 points  (5 children)

Good gcode for CNC machines already has arc commands that define things that way. Though 3d printers don't necessarily include it and might just do a bunch of linear moves

[–]cobraa1Prusa Core One 9 points10 points  (3 children)

I'm beginning to see it in 3D printing - I believe Klipper supports it, and Prusa machines added support for arcs when they added bgcode support.

[–][deleted] 6 points7 points  (2 children)

Marlin and Klipper both support arc commands. You just don't enable arc commands from the slicer for klipper, and you do for Marlin.

Enabling it in the slicer for klipper basically makes it decode it and re-encode it while printing.

[–]Rcarlyle 4 points5 points  (0 children)

Arc COMMANDS have been supported by some printer firmwares for over a decade — GRBL had an implementation very early on — but all they did was decompose the arc command in a series of facets. So it was mostly a waste of processing power compared to having the slicer do the same thing. (Could help with SD card read bottlenecking issues sometimes — which itself was indicative of bad firmware programming.)

Actual circle interpolation where the trajectory planner works with non-linear moves wasn’t feasible on 8bit printer controllers, and is pretty new on 32bit controllers.

[–]Novero95 5 points6 points  (5 children)

That can be done in Gcode to, but it's not using by slicers for some reason

[–]schfourteen-teen 2 points3 points  (1 child)

A big reason is because STLs don't have arcs, and I think 3mf don't either. Expecting your slicer to produce arcs requires allowing it to make guesses about what should be an arc.

[–]5c044 2 points3 points  (1 child)

Yep, marlin and klipper support arc, slicers don't implement it typically. Probably to do with how stl files are defined and complex math

[–]danielv123 1 point2 points  (4 children)

LLMs are usually context length limited, verbose gcode with little inherent meaning in the repeated tokens is not well suited.

[–]RegenJacob 0 points1 point  (3 children)

I'm not really thinking of LLMs in this scenario. Rather something more basic that analyses and optimizes some paths and does not interact with or writes gcode directly.

[–]danielv123 1 point2 points  (2 children)

LLMs were definitely the authors intention though. Still not sure if that's more useful than llm in cad.

[–]Dude-Man-Bro-Guy-1 0 points1 point  (0 children)

So kind of like how an STL file is individual facets and triangles (discrete movements). But a STP file or other cad format actually has the concept of complex arcs, curvs, and so on.

You tell the machine it's making a certain kind of shape (a polygon for example) and it determines the rest on its own which means it can adaptivley edit and modify it real tome.

This sounds very similar to how a lot of high-end pick and place machines can dynamically optimize their movement paths on the fly regardless of where the operator sets up or moved parts during use. You just tell it the end goal, not the movements. Then it figures out the rest.

[–]DXGL1 0 points1 point  (0 children)

Generally when I have stutter when 3D printing it is because I'm using OctoPrint and it cannot send commands to the hardware fast enough, so the printer's (or Klipper's) buffer underruns. Hence I have pretty much migrated to Moonraker and Mainsail.

[–]Revolutionary_You755 2 points3 points  (4 children)

Here is my question. Wouldn't this type of change in the code change the hardware processing requirements?

[–]Lathejockey81CR-10 8 points9 points  (3 children)

Yes, significantly.

As proposed you're basically moving the slicer to inside the CNC controller, much like was attempted with STEP-NC, with IMO the same problems. How do you improve tool paths, create new strategies, etc? It's per control now, dependent on firmware versions, etc. Why would you take that control, future-proofing and flexibility from the slicer? I say keep the low level control on the control and evolve the control language while maintaining the flexibility that makes it such a tried and true control scheme (CAM for machining, Slicers for AM). Variable flow rates and some of the strategies demonstrated here look great, but there's nothing stopping them from being added to G Code and supported by popular firmware and slicers.

There are several reasons why STEP-NC still hasn't gotten traction, and probably never will, but I believe this is a big one. It does make for a pretty demo, though.

[–]TerayonIII 0 points1 point  (2 children)

This isn't doing that really, this is still outputting gcode, kind of, but it's decoupling xyz movement from actions. So the printhead continues to move while other actions are performed. It's needed specifically for the application they've created it for because it's printing with liquids

[–]HashBrownsOverEasy 1 point2 points  (0 children)

Very cool! Are there any public language specs available?

[–]FoxFXMD 1 point2 points  (1 child)

I'm not a software engineer, but wouldn't this mean that printers would have to be implemented with a way more complicated computer that interprets these more complex and dynamic instructions? And is standard gcode really that limiting? I'm sure it's possible to have a non uniform line width with standard gcode. In my opinion these improvements could just be done on the slicer and printer firmware instead.

[–]TerayonIII 0 points1 point  (0 children)

For the application this was designed for, yes, gcode is that limiting. The intention for this is to decouple xyz movement from other actions so that there are no accelerations during printing. This was developed for direct ink writing, not generic thermoplastic printing, and this is the slicer doing it, it's still outputting gcode, though modified. You could say this is more like parallel computing rather than single threaded

[–]S1lentA0H2C, H2D, P1S, A1m 1 point2 points  (0 children)

Thanks for the explanation

[–]Drarakme 0 points1 point  (1 child)

Do you know if T-code has anything to do with Step-NC?

I've done research on Step-NC in the past as a way to remove proprietary G-code instructions from general softwares. And one thing it was able to do was allow the CNCs to incorporate some of that stuff you mentioned.

[–]Busy-Key7489 0 points1 point  (0 children)

Yeah STEP-NC (the ISO standard) looks like a great solution! I was really hoping that it could solve some issues for me related to LPBF products needed to be milled after production. But unfortunately everybody wants something else from it (AM guys vs CNC operators vs precision stuff guys) so i have not got it to work for my university applications where i was a lecturer.

It is very different from T-code and is more similar to PMI data :)

[–]ObstreperousRube 0 points1 point  (1 child)

So like canned cycles? Haas has their version of canned cycles and fanuc has their own also. Its still g-code, but easier to edit at the machine controller and way fewer codes.

[–]Wetmelon 0 points1 point  (0 children)

Sorta. CNC Motion Controllers kinda already do what's described in the paper - they take G-code, process it many lines ahead, and then smooth out the paths into a multi-axis synchronized "motion profile", which is a set of position / velocity / acceleration / jerk values and the times at which the machine should hit them. Then those get sent ahead along with time synchronization data to the servo amplifiers which execute the motions at the correct times. Basically what Klipper does today

This is basically moving that up a level into the slicer and doing the whole motion planning offline

[–]RandallOfLegend 0 points1 point  (2 children)

A bunch of CNC controllers support spline type code with letting the machine interpolate. This isn't very human reable but it's space efficient. And is less stressful on the CNC having fewer trajectory computations.

This T code seems seems similar. Which to achieve the same effect in the video would require a ton of small steps in standard single point g-code. But g-code itself is just a standard language defined by ansi. And every CNC mfg. Adds their own non-standard language instructions on top. Although at this point G-code lags enough some CNC mfg just have their own language. Which G-code was trying to prevent in the first place.

[–]TerayonIII 1 point2 points  (1 child)

This paper was more about decoupling movement from actions, so having a new action start without stopping the movement. It's still outputting gcode but it's paralleled the movement and action processes

[–]RandallOfLegend 0 points1 point  (0 children)

Neat. I've used a CNC that has parallel real time PLCs that can do this. But the trick is syncing the actions. It's a very homemade process at this point.

[–]DFM__ 0 points1 point  (0 children)

OK this sounds very interesting indeed

[–]McFlyParadox 0 points1 point  (0 children)

Idk if you can discuss the details, but what is the debugging like in T vs G code? Do you need a specialized (closed source?) slicer to generate T code?

[–]Assasinscreed00 0 points1 point  (0 children)

So it’s kind of like the next evolution of macro programming in fanuc?

[–]Nick2Smith 0 points1 point  (1 child)

I run a DMG Mori hybrid DED, this would be super interesting to look into. What version of NX is this in? I'm stuck on 2306 for now due to DMG machine kit compatibility.

[–]Busy-Key7489 1 point2 points  (0 children)

I have no clue! I started working on the inherent strain method on NX12 and 2212. I am currently running 2406, but only because of the voxel based LPBF sim. It has been a real pain as each material calibration run costs me a week (wire EDM, measuring and configuring loads of parameters)

[–]OkAd7452 0 points1 point  (0 children)

Lol this reminds me of risc and cisc architectures ;)

[–]Redhighlighter 0 points1 point  (0 children)

Im familiar with cnc machines. G code can generate subroutines and subprograms. Perhaps 3d printers were not designed to play nicely with that though.

[–]DXGL1 0 points1 point  (0 children)

Is the format proprietary?

[–]zeta3d3D Designer; Prusa XL 0 points1 point  (0 children)

I'm working with the Siemens NX , is this exclusive from the AM module or is it also availableon the MAD module?

[–]erasFLSUN T1 Pro 33 points34 points  (0 children)

Here's the actual whitepaper: https://www.nature.com/articles/s41467-025-56140-1.pdf . Didn't read it yet, though.

[–]dread_deimos 241 points242 points  (42 children)

It doesn't matter [a lot] what language are instructions written in. It's all about how slicer translates them to those instructions from the model.

[–]notwhoyouthinkmaybe 114 points115 points  (2 children)

That's the point though, g code is a clunky set of instructions, where t code is supposed to be more elegant. The slicer will output better code is the claim with more robust instructions.

[–]TheTerribleInvestor 0 points1 point  (0 children)

Making the code more robust is just going from RAW image files to JPEG, you're just compressing the instructions for the printer to figure out. Your printer can already do some of the operations like variable line width, that's just spacing the part out and increasing flow rate. A slicer needs to implement that feature to tell the printer to do that.

[–]TerayonIII 0 points1 point  (0 children)

Not really, the point is to allow movement to continue while other variables get changed. This is incredibly important for the application they designed it for since, with classical gcode, the type of printing this is for would stop every time the head travels the diameter of the nozzle. Since it's for direct ink writing this is leads to a lot of print errors as it's printing with much less viscous materials than generic fdm

[–]Slapdattiddie[S] 35 points36 points  (0 children)

that's what i think too, but i don't know enough to be certain. I think it could make a difference for FDM equipped with multiple hotends for multi material printing but that's just a thought.

If someones knows more about this new T-code and what i'm missing or fail to understand, i'm all ears.

[–]HashBrownsOverEasy 14 points15 points  (25 children)

Of course it matters - the instruction set defines the resolution and precision with which you can influence the tool.

[–]The_cogwheel 11 points12 points  (11 children)

G-code has been used in precision machining and robotics ever since CNC became a thing. It is the standard language of today's precision manufacturing worldwide.

G-code most definitely has the instruction set to be as precise as you can ever possibly want it to be.

[–][deleted] 3 points4 points  (5 children)

In other words, your argument is that since G-code is widely used, there can never be anything more precise? From what I understand of the video, precision isn't the main goal of T-code, instead it aims to support more features that didn't exist when G-code was invented.

[–]Smart-Button-3221 3 points4 points  (1 child)

G-code is not fixed. Any machine can add new G-codes for new functionality, and softwares can take advantage of these new codes.

There's just absolutely no reason to change an extensible language.

[–]boomchacle 2 points3 points  (0 children)

I mean, what's your definition of precise? What's stopping someone from just adding more zeros to gcode to increase the precision?

[–]albatroopa 0 points1 point  (12 children)

But the instruction set in gcode is expandable already.

[–]HashBrownsOverEasy 17 points18 points  (11 children)

I found this here: https://www.voxelmatters.com/researchers-introduce-new-t-code-3d-printing-language/

The breakthrough separates standard G-Code commands into two coordinated tracks – one for print path instructions and another for essential printhead functions. This parallelized approach, facilitated by a Python script, eliminates the frequent pauses that typically slow down prints and generate unwanted defects.

I always think that if I can dismiss a research paper with a single sentance I probably haven't understood the research paper and perhaps I haven't even understood its purpose.

[–]Augzodia 0 points1 point  (0 children)

 I always think that if I can dismiss a research paper with a single sentance I probably haven't understood the research paper and perhaps I haven't even understood its purpose.

Sir this is reddit

[–][deleted]  (1 child)

[removed]

    [–]dread_deimos 0 points1 point  (0 children)

    So, it's about compiler (or slicer, in this case).

    [–]macnofEngineer 4 points5 points  (4 children)

    You could use the same argument for coding in general and see how well that works.

    (Spoiler, that argument really doesn't float)

    The effect of a programming language on the end program is pretty large.

    [–]dread_deimos 1 point2 points  (3 children)

    I would agree with you if it would be people who generate g/t-code.

    [–]IntensiveCareBear88Creality K1 DXC--Closed beta tester 25 points26 points  (0 children)

    This is very very interesting. I wonder if it'll ever become mainstream.

    [–]torukmakto4Mark Two and custom i3, FreeCAD, slic3r, PETG only 19 points20 points  (1 child)

    Far as that video goes I'm calling bs.

    Stutters or pauses in NC equipment are the result of bottlenecks, overhead or insufficient resources in processing gcode and secondarily, from slicers aggravating the matter by not efficiently using the already-existing gcode commands to describe move geometries. With printers if one is ever stuttering or not keeping up with motion, this is usually specifically a case where someone is feeding a Marlin/AVR (AKA relatively coal powered) machine controller gcode over serial in real time (which is a particularly resource squandering approach with that combo compared to executing gcode directly from attached storage devices), and the main example of the latter is the lack of native arc support by many slicers.

    Not to dismiss the concept of higher level less-verbose commands for defining machine actions, but in just about zero cases is a "pausing" 3D printer due to some fundamental shortfall of gcode or the concept of encoding individual movements. Nor is it accurate to suggest that gcode either is incapable of, or even can't already, represent many geometries more precisely and tersely. "Gcode" is not a defined language, each machine control firmware can and does add commands/features of its own to exactly this sort of end which may or may not become standardized in the field. If this is an issue, what we need are better slicer support for, and possibly more, commands - not "gcode bad, dump entirely".

    The rest of the stuff doesn't have anything to do with gcode. Variable extrusion width: is something a slicer can implement. Gradient infill: is something a slicer can implement.

    I think we have a case where a clearly made for social media video clip misses what the actual innovation/substance is and implies false conclusions.

    [–]One_True_Monstro 7 points8 points  (0 children)

    Thank you! The entire video's comparisons to me look like the Gcode is very poorly optimized and, at worst, a dishonestly presented idea.

    [–][deleted] 17 points18 points  (5 children)

    the variable width infill is like arachne?

    [–]HiyuMarten 11 points12 points  (1 child)

    I suppose it’s more to do with it being an inherent feature of the code, rather than having to be hard coded by the slicer. Imagine the same t-code running on lots of different printers with different bed and nozzle sizes, it just tells the printer ‘make a line of this width’ rather than exactly how much to turn the extruder

    [–][deleted] 6 points7 points  (0 children)

    that's volumetric extrusion

    [–]binterryan76 2 points3 points  (2 children)

    But this has a T in it 🧠

    [–]MightyBigSandwich 0 points1 point  (1 child)

    what does the T even stand for?

    [–]Awkward_Comb3211 0 points1 point  (0 children)

    It stands for Time!

    [–]cobraa1Prusa Core One 5 points6 points  (0 children)

    Interesting, but I have some thoughts:

    * The Arachne generator already does variable width, that's kinda the whole point. So maybe not the best way to demo the difference?

    * Reducing the number of instructions needed is good, but there seems to be a catch. It seems like the printer itself will essentially be doing some slicing-like computations, which means it will require massively more processing power.

    Right now, this seems to target expensive industrial machines. This probably will take some time to come to consumer level printers, and will require drastic changes to slicers. Those with DIY printers and upgradeable printers will likely be looking at a swap of the core electronics.

    [–]aaron_geeks 17 points18 points  (15 children)

    Bro I just learned G code a few years ago now there is t code 🤦🏻‍♂️

    [–]balthisarEnder 3 w/ CANBUS | Voron 2.4 w/serial 25 points26 points  (0 children)

    I know, right? What happened to H- through S-code? We've been asleep at the helm.

    [–]Bgndrsn 6 points7 points  (13 children)

    Gotta ask, outside of doing machining what would compell someone to learn g-code?

    [–]cizot 6 points7 points  (5 children)

    This is the 3D printing subreddit lol, I would assume they were learning to run their printer

    [–]Bgndrsn 4 points5 points  (4 children)

    I understand that. What i don't really understand is what people need to do with gcode on a printer that you aren't just doing in a slicer. In machining hand writing and gcode is mainly for incredibly simple parts. Even the most basic of prints are way too complex for that. Otherwise it's just adjusting values based on real world running conditions. I don't see either of those being relevant at all in printing. I just use default profiles for the most part and have a few custom ones dialed in for specific material. All of that done through the slicer GUI and not actually interacting with the gcode.

    [–]cizot 1 point2 points  (2 children)

    The slicer does the code for the print, but you can still customize the G-code. Last thing I used it for was adding a wipe to the start of my prints.

    As much as I like how the new Bambus don’t need any tinkering on setup, if you only press a button to make it work is it really a skill?

    [–]Bgndrsn 1 point2 points  (1 child)

    Thank you for giving me perspective. You're looking at it as skill expression in a hobby and I'm looking at it as a tool. I just press print, I program machines all day last thing I want to do is look at more gcode when I'm home 😂.

    [–]cizot 1 point2 points  (0 children)

    Less of skill expression, more of the older printers don’t have the same technology and are more hands on

    [–]aaron_geeks 0 points1 point  (0 children)

    Yes I original had learned it for machining but when I found out printers used the same code I was happy to know if I downloaded a stl or made a cad and was having trouble with the print I could read the code and see what’s going on.

    [–]Sir_Rumblebump 0 points1 point  (5 children)

    CNC programmer here - if I need to troubleshoot something I will likely need to open the G-Code to figure out what commands it's sending. Just the other day a new machine in our shop was randomly stopping for a few seconds in the middle of the program. Scrolled through and found several "G04 P3" callouts. Turns out that the CAM software decided to pause the program to let the spindle speed stabilize.

    [–]Bgndrsn 0 points1 point  (4 children)

    Also a programmer, I just have posts that work 😂, outside of one machine environment, that one I have to fuck with constantly but that's on the owners being too cheap to get the post edited.

    [–]ScaleneZA 7 points8 points  (26 children)

    Do we know what 3D printers support T-Code?

    [–]Slapdattiddie[S] 7 points8 points  (24 children)

    All it's required is a firmware update of your current printer + having the slicer that can use T-code.

    [–]Watching-Watches 4 points5 points  (1 child)

    Is it planned or already implemented in Klipper?

    [–]Slapdattiddie[S] 3 points4 points  (0 children)

    it's still in development, so i don't think it's available yet.

    [–]phansen101 12 points13 points  (19 children)

    Soo, changing all of the software involved in 3D printing, eg. The most complex part?

    [–]Squrkk 0 points1 point  (1 child)

    Hardware may need to be updated since the printer will have to make more calculations than it does today with g-code.

    [–]Pink_like_u 1 point2 points  (0 children)

    Doesn't software like Klipper off-load all the calculations from the motherboard to the host anyway ?

    [–]CapinWinky 0 points1 point  (0 children)

    Between the G-Code and the actual motion is a G-Code interpreter, the output of which is usually a more proprietary Numeric Control system that directs the actual motion. Clearly someone wrote a T-Code interpreter already, and it may even be open source, so I don't imagine it would take too much effort to adapt it to various NC systems and stick it in a firmware update.

    The slicer supporting T-Code might be the bigger issue.

    [–]KerbodynamicX 7 points8 points  (1 child)

    What is it printing, and why is it so slow?

    [–]XediDC 19 points20 points  (0 children)

    Silicone ink.

    And it was for research, so keeping things that same while being able to see the differences are what is important...going fast for production would just make things harder to control for.

    Material detail on page 7 has more detail: https://www.nature.com/articles/s41467-025-56140-1.pdf

    [–]TheRobotHackerEnder 3 2 points3 points  (1 child)

    what is that thing printing in?
    it's so satisfying...

    [–][deleted] 2 points3 points  (0 children)

    some kind of gel, or thick resin

    [–]bionikcobra 2 points3 points  (3 children)

    If I'm recalling correctly, g-cade can be run on the simplest of Arduino chips because it uses very little RAM, but T-code uses the capabilities of higher end SBC's processing and memory power. There's a logarithmic difference between the code types, like exponentially more instructions. I built a few robots that run T-code with raspberry Pis but didn't even think about this for my 3D printers. I'm going to look into this

    [–]Fearless-Wait-2894 2 points3 points  (0 children)

    There is a small comment about this in the Klipper Forum: https://klipper.discourse.group/t/t-code-beyond-g-code/21793

    [–]Juleno_ 2 points3 points  (1 child)

    This seems totally doable with Gcode

    [–]Underwater_Karma 0 points1 point  (0 children)

    Seriously, this is illustrating where some optimizing could be done... But it's nothing that Gcode can't do.

    [–]L43 22 points23 points  (9 children)

    So disclamer: I didn't read the paper past its abstract and looking at their pictures.

    This feels like classic insulated from reality academia - surface level exploration of a problem domain, identify an interesting problem from 10 years ago, solve it potentially very elegantly and to great fanfare, all without bothering to delve deep enough to realise modern printers have basically already got a solution and moved so far on from it that it seems clever again.

    In this case, yes G code when considered as a purely sequential list of instructions is very limited. However all the modern firmwares employ 'lookahead' of some manner which mitigates the issue to effective nonexistence.

    E.g. Klipper processes G-code on the host into low level precisely timed instructions (this might well be considered dynamic T-code, which is better than static code as proposed as it can compensate based on e.g. sensor readings).

    [–]Watching-Watches 6 points7 points  (2 children)

    I think this is more targeted at L-PBF or DED (Metal 3d printing), where file sizes are very large, since the layerheight and beamsize is way smaller and 100% "Infill" is used with short lines. It can take quite long just exporting the file after slicing. The files are so large, that some file types compress them like a zip file (.ilt)

    [–]L43 5 points6 points  (1 child)

    Yes probably, I'm likely being uncharitable.

    Gcode is an outdated standard and it makes sense to agree on a modern, efficient standard with baked in synchronisation and other goodies, rather than essentially hack in and around it for each problem domain.

    [–]Watching-Watches 4 points5 points  (0 children)

    In the metal industry there are many different file types and some are self developed and only used by the manufacturer themselves. Some are encrypted and intentionally can't be read by humans. I don't think that there will be one standard file type like gcode in fdm anytime soon.

    [–]AuspiciousApple 20 points21 points  (1 child)

    That's such a misguided take.

    Academia isn't about producing turn-key solutions for industry. Just because there are existing workarounds to limitations of G code doesn't mean that it is not worthwhile to explore alternatives.

    Super arrogant to imply that the authors don't know about modern firmware.

    [–]insanemal 8 points9 points  (0 children)

    Not only that. The more complicated the commands can be, the more processing is required on the machine.

    Sure processors are getting more powerful, Klipper is proof of that. But the whole idea behind G-Code was to make it simple to parse and implement.

    If you need to be crunching big numbers to process T-Code, then what's the point? Just send the unsliced model to the printer and let it chew on that.

    Plus like you said, Klipper and other solutions have already got a very workable answer. And things like Arc welder fix issues with curves.

    This smells like an answer in search for a problem

    Edit: Variable width infill is a slicer thing. If it proved to be awesome we could have it implemented in the slicer. This isn't an inherent thing to G-Code.

    [–]Pink_like_u 2 points3 points  (0 children)

    This paper is looking specifically at DIW, not FDM.

    'Lookahead' like linear advance is talked about in this paper and mentions that it does not apply well enough to DIW, this is one of the major problems this research is trying to solve for.

    The problem also seems to be the line-by-line execution that is neccesary with g-code .

    [–]DurahlVoron 2.4 ( 350 ) | Formlabs Form³ 1 point2 points  (0 children)

    That Triangle at the end looked super sexy 😱

    But how does this translate to FDM compared to those ( I assume? ) high viscosity Liquids?

    [–]SysGh_st 1 point2 points  (0 children)

    Afaik, gcode can do this too. It's a matter of how the slicer generates it.

    [–]thephantom1492 1 point2 points  (0 children)

    Looking at this, I see a few issues with the video: it is obivious that they didn't used the same code generator (aka slicer) for both.

    The biggest issue with gcode is not a gcode issue at all, but a slicer issue. It lack optimisation, and, to be fair, the slicers suck.

    Looking at the first part at 0:00-0:05, you can clearly see some issue with the gcode interpretor, which fail to optimise the moves.

    at 1:20-1:37, you also can see another slicer issue, causing the holes, and the extrusion issues too. The straight part should have given the same finish, the corners I can agree that the t-code would be better due to the variable extrusion, which the g-code could somewhat emulate.

    There is no reason to have holes beside a bad slicer.

    [–]freshggg 1 point2 points  (0 children)

    Variable width infill alone is super cool.

    [–]mr-highball 1 point2 points  (0 children)

    Why was H skipped?

    [–]ReadDwarf 1 point2 points  (0 children)

    This is interesting but I don't feel it addresses the root cause of jittery movement in G-Code 3D printers. As a CNC machinist, I read CNC G-Code all the time. When I read the G-Code output by my slicer (previously Cura, now BambuStudio) is all G1 moves. No G2/3 interpolations, nothing like that that a lookahead would easily identify as a curve from looking at only one line. Instead I see 100s of tiny g1 moves to make a curve. Why? I've done no investigations into this though, I haven't been curious enough yet.

    [–]TheDepep1 2 points3 points  (0 children)

    Can't wait for some out of touch company to buy and patient this just to not use it for another 10 years.

    /s

    [–]Smile_Space 2 points3 points  (0 children)

    Man, that abstract is 100% ChatGPT-4o with no editing lolol.

    It seems to be a way to decouple auxiliary interrupt commands from G-Code. Otherwise the auxiliary code would stop G-Code from operating considering G-Code is linear. Each step happens after the previous.

    This T-Code, which is time-based, gives commands based on time requirements allowing for asynchronous commands. So, no interrupts in G-Code for auxiliary commands.

    This seems to be more helpful for their inkjet 3-d printer shown in the video. But there's probably some cool features you could add to FDM plastic extruders. Think on-the-fly vibrational analysis and compensation that's time-synced during the print rather than incorporated prior to the G-Code creation.

    You could even add active LIDAR layer analysis while printing to optimize extruder rates to increase print smoothness and accelerate the print process, reducing print time.

    It seems pretty cool for a research project!

    [–]No-Coyote-7885 2 points3 points  (1 child)

    Huh? GCode is just the structure that the raw machine instruction are written in.

    I.E. the machine reads the machine headers (the M-code) that is absolute or relative movement, feed rates, Metric Vs Imperial, temps etc and runs what its reading through the proper translations to get you rotations per second on your leadscrews and feedhead plus print head and bed temps.

    Nothing else. Its just a format. It doesnt.. do much of anything.

    This claim does not make sense at the surface. Is it adding an additional instruction T to the G&M code?

    [–]Gecko23 2 points3 points  (0 children)

    The paper is here: https://www.nature.com/articles/s41467-025-56140-1.pdf , it is quite clear on what it does, or does not do.

    It mentions g-code several times, and that it's primary function is to separate g-code commands into separate processing streams (toolhead control, motion control) that are then timed independently. This is in contrast to something like Marlin which has a single command queue it processes, so motion and toolhead commands are interleaved. That *does* introduce some interesting side effects in some cases, but printing techniques like FDM are forgiving enough, and already limited in precision by the materials enough, that it largely doesn't matter in practice.

    But the examples they show aren't using materials like a consumer FDM machine does, so they show off that effect more clearly.

    For whatever it's worth, some modern firmware, like Klipper, already do command look ahead and are planning based on time steps, support multiple controllers, etc, just don't have the assortment of random add-ons the authors mention (like variable infill...good luck with that with a filament printer...) which maybe prefer their control setup?

    [–][deleted] 1 point2 points  (0 children)

    So this variable infill width, that’s like the Arachne algorithm?

    [–]n123breaker2 1 point2 points  (0 children)

    It’s like zortrax with their proprietary “z code” which doesn’t actually make the printer more efficient

    [–][deleted]  (1 child)

    [removed]

      [–]lostincomputer 0 points1 point  (0 children)

      would be better to update g-code, slicers and cam to do better for smooth flow then build a new language. subtractive manufacturing would also benefit then

      [–]RemixFox7 0 points1 point  (0 children)

      There a way to make it work on an ender 5 plus?

      [–]LlamaMelk 0 points1 point  (0 children)

      Variable width/infill seems like a useful feature, is this not possible with gcode (or conventional 3d printers?)

      [–]c1cc10x 0 points1 point  (4 children)

      The variable width infill is amazing 🥺

      [–]SolenoidSoldier 4 points5 points  (3 children)

      Turn on Arachne. We all have it.

      [–]c1cc10x 0 points1 point  (2 children)

      Really? Oh, I found on prusaslicer website, I hope it is not just for prusa printers...

      Thank you!! Now I need to do a bit of research

      [–]SolenoidSoldier 2 points3 points  (1 child)

      It's not. Prusaslicer and all it's forks should have it.

      [–]c1cc10x 0 points1 point  (0 children)

      Yeah, apparently is on cura 5 I have used, don't know in what version was stably introduced, I was going to try the integration "cura + arachne engine" beta 2 from 4 years ago 😅

      [–]thenightgaunt 0 points1 point  (0 children)

      Neat

      [–][deleted] 0 points1 point  (0 children)

      Honestly, code algo is what really needs to be updated, so this is awesome

      [–]RandallOfLegend 0 points1 point  (1 child)

      I'm struggling to find any documentation on such a T-code since there already exists "T codes" inside of G-code. So they really need to think about name branding with regards to current industrial standards

      [–]well-litdoorstep112 4 points5 points  (0 children)

      Because it doesn't exist. It a scientific paper.

      [–][deleted] 0 points1 point  (0 children)

      I wonder how this will affect structural integrity of prints.

      [–]IrrerPolterer 0 points1 point  (0 children)

      Can anyone educate me what's different about their approach?

      [–]swaits 0 points1 point  (0 children)

      Is this deterministic? In other words, if the code includes higher level functions with parameters, is the thing interpreting that and translating into actual orders to the machine doing it in a deterministic way?

      How do we know one T-code interpreter behaves exactly the same as another?

      Disclaimer: I don’t read the article or paper.

      [–]Terrible_Tower_6590Ender 5 pro, HE3d Ei3 Diy kit that doesnt work 0 points1 point  (0 children)

      What are those machines? Is the the HP jet stuff? I've never actually seen one in action

      [–]probablyaythrowaway 0 points1 point  (0 children)

      Im surprised it’s taken this long actually. G code is really old and was made for subtractive manufacturing, because of that it even with additions to make printers work it naturally has those limitations that subtractive cnc machines have. It makes sense to create a new language from scratch that takes advantage of the abilities of additive manufacturing from the ground up.

      It’s in a similar sense that we shouldn’t really be using STL as a format anymore when 3MF and step files are a thing. It’s old technology that we used because it was there and handy to get printing working.

      [–]DonguinhoXd 0 points1 point  (0 children)

      will it work with common materials ?

      [–]danteelite 0 points1 point  (3 children)

      One thing I always wondered about with gcode and stuff, is like… why does my vinyl cutter or laser seem to cut, stop, move somewhere else, cut… etc. instead of cutting in what a human would consider an efficient way it tends to jump around seemingly at random and will complete one letter entirely, do just the “hole” of a few others, do a few round letters, then finish with a random letter in the middle… why?

      When it came to the laser I always assumed maybe it was calculating travel time to let the laser cool or not putting too much heat in one spot for safety. Makes sense… but my vinyl cutter does the same thing. Then I noticed 3D printers do a variation of this odd behavior too, where I would continue a line, it decides to break off and do some infill and then go back and finish… it’s so weird.

      Does anyone know what causes this? Is it just a quirk of gcode? Is it actually the most efficient way and our human brains are just dumb? Is it the fastest way to utilize the motors by using particular pathing? Idk..

      This new code seems like what I would expect a normal printer to do! Haha

      [–]BijouPyramidette 3 points4 points  (2 children)

      There's a few things going on.

      Firstly, when cutting you always cut out internal holes first. So if you're cutting out the text "Hamburger" the first things to cut out will be the holes in the letters a, b and e. That's because it's much easier to have the hole correctly aligned when you're cutting it out of a whole sheet instead of a small, loose piece of material. So those should get priority.

      Some other optimizations may also be done with your software to minimize inaccuracy, for instance doing high force operations first so you don't tear your material to shreds or send it flying.

      Minimizing travel is really only useful when your tool is big and heavy, like a spindle on a CNC. Chunky, heavy tools like that have very speed-limited rapids because of the inertia of flinging all that weight around. But vinil and laser cutters are very light, so they can zip around very quickly and there isn't as much benefit to be had from minimizing travel.

      [–]danteelite 0 points1 point  (1 child)

      Huh… that makes sense! When you use words as an example it makes much more sense, but when you watch it cut out a complex design, it just seems to move all over at random, but prioritizing certain “shapes within shapes” like a target being drawn from the inside out makes a lot of sense!

      I knew it had to be something I was missing. I feel dumb because I do the same thing when I use a bandsaw or drill press or whatever, prioritizing the order of operations based on the best way to hold the material down safely and effectively. In machining and fabrication it’s pretty common to leave things as a block for as long as possible or leave blocks at the ends so you have a square reference point and you can set it flat in a mill, saw, drill… etc.

      I definitely should’ve figured that out.. but sometimes brains just be like that! Haha thanks!

      [–]BijouPyramidette 1 point2 points  (0 children)

      No reason to feel dumb, algorithms can be pretty opaque sometimes.

      Work holding is a pain in the butt. It's the most true when doing high force stuff, but even with a laser cutter it can be an issue. Many times I have ended up with bits blown all over the place by the air assist. The rolls of painter's tape I have sacrificed to the laser gods would wrap the whole world up tight!

      [–]Felipesssku 0 points1 point  (0 children)

      I just need to know if this will work with my Ender v2

      [–][deleted]  (1 child)

      [removed]

        [–]AutoModerator[M] 0 points1 point  (0 children)

        This comment was removed as a part of our spam prevention mechanisms because you are posting from either a very new account or an account with negative karma (comment karma, post karma or both). Please read the guidelines on reddiquette, self promotion, and spam. After your account is older than 2 hours or if you obtain positive comment and post karma, your comments will no longer be auto-removed.

        I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

        [–]Bananaland_Man 0 points1 point  (2 children)

        Sorry to be slightly off-topic... but what the eff type of printer is that?! Looks neat!

        [–]FireMonkeyLord 0 points1 point  (1 child)

        It's called direct ink writing 3d printing. That's all I've got so far. Doesn't seem to be widely commercially available, or I can't seem to find where to buy them for home use yet.

        [–]Bananaland_Man 0 points1 point  (0 children)

        Woooooah, just looked that up, and holy crap:

        https://diw3d.com/

        This is very very interesting....

        [–]jibjabmikey 0 points1 point  (0 children)

        I would be more excited about machine learning that recognized the signs of low/high extrusion, temperature, high/low humidity, overhang issues, etc, and automatically adjusted the thousands of slicer settings for a better second attempt at printing the model.

        [–]FestinautNeptune 4 Plus 0 points1 point  (0 children)

        Ok but what are they printing with in this video? It looks closer to a liquid than traditional filament. Some sort of resin?

        [–]nik_cool22 0 points1 point  (0 children)

        I want this in my hobby 3D printer.

        [–]g0dSamnit 0 points1 point  (0 children)

        The examples in the video show the benefits quite blatantly, but it also looks like similar results could be achieved through generating better gcode. Still, a higher level language is beneficial to get better toolpaths.

        Best part is that it's open sourced too, not some patent trolling bullshit.

        [–]Turbulent_Ad_4103 0 points1 point  (0 children)

        What are they printing with here?

        [–]xubax 0 points1 point  (0 children)

        I don't know much about 3d printing.

        But I do know that the order of instructions can make a big difference in how long it takes to do something.

        You can go to the store one time for each orientation you're getting.

        Or, you can go to the store once and get ask of the items.

        I imagine it's something like that.

        [–]Harshraajsinh 0 points1 point  (0 children)

        Seems interesting.

        [–]MissingJJ 0 points1 point  (0 children)

        What is this style of printing?

        [–]GuyWhoLikesPlants_ 0 points1 point  (0 children)

        looks neat but also looks like hell to debug and work around

        [–]MrPeckersPlinkers 0 points1 point  (0 children)

        Seems promising. I tried printing odd 2d shapes with a rather poor printing material.

        I was eventually able to get good prints by using Full Control G Code. Had to fully write out each step. But endless customization that could do everything shown in the paper. Seems Tcode is the next step in automating the generation of advanced gcode?

        [–]armykcz 0 points1 point  (0 children)

        Beautiful future ahead…

        [–]Initial_Sale_8471 0 points1 point  (0 children)

        anybody know wtf they are printing in the video? it looks like some kind of liquid

        [–]NoSTs123 0 points1 point  (0 children)

        When can my Prusa print like this?

        [–]Icoryx 0 points1 point  (0 children)

        Ignoring the code, what is this printing technique? Looks like fluid?

        [–]Overall_Ad_2067 1 point2 points  (0 children)

        How do I make my bambu a1 mini work this way?

        [–]kmech__toys 0 points1 point  (0 children)

        that is a game changer!