While the T-code concept is interesting, this graphic makes no sense to me, it just looks like the results from an old printer running Marlin that doesn’t have pressure advance or input shaping enabled?
I’m curious as to what others think, is this something worth adding to Klipper in some form (eg under the hood re-processing), or is it based on a flawed understanding of current printer firmwares like Klipper?
For what it is worth, the authors of that Nature article don’t seem to be aware of the common 3d printing firmware techniques. For example, they state, “this limitation stems from the line-by-line execution of G-Code, requiring the printer to decelerate and stop at each new line”. That hasn’t been true of 3d printers since the very early days of RepRap. All modern firmware implement “lookahead” to avoid full stops between moves. Klipper (and others) can also process “auxiliary” commands between movements without introducing zero velocity pauses.
I didn’t see an example of their “T-Code”, but at a very high-level the Klipper host code translates G-Code to precisely timed commands that are sent to the MCUs. So, in a sense, one could say Klipper is a G-Code to “T-Code” converter. In my brief scan of that paper it wasn’t clear to me if that’s what the authors were describing though.
Also, the paper seems to be about “Direct Ink Writing” which may have sufficient differences from Fused Filament type 3d printers. So, I don’t know if programs like Klipper would apply to their goals.
