Hi,
If I understand this discussion correctly, the goal would be to replace a typical G1 X10 Y10 E2 command with a configuration command to set the extrusion width (something like SET_EXTRUSION EXTRUSION_HEIGHT=0.2 EXTRUSION_WIDTH=0.45) followed by explicit “move with extrusion” commands (something like MOVE_WITH_EXTRUSION DESTINATION_X=10 DESTINATION_Y=10 DESTINATION_Z=0.4). Thus, not sending encoded extrusion amounts on each movement command, and instead sending commands that try to better relay the intent.
This is something I’ve thought about a bit in the past, and I can give some of my high-level thoughts on it. My thoughts here are just “philosophical musings” and should not be taken too seriously.
To summarize though, for what it is worth, I’m not sure making a change like the above would be worthwhile.
If I could go back 15 years and scream about how painful it would be to add E to G0/G1 movement commands I certainly would. As I understand it, this was an invention of the RepRap team, and I don’t think it was a good choice. I’d certainly prefer it if the firmware received more context with extrusion (the other parameters of the movement commands are in millimeters relative to the bed, it is bizarre that the E parameter is not). Alas, I can’t go back in time to fix that, and nor can anyone else. It seems to me that “ship has sailed”.
In my opinion, the problem with trying to “improve legacy g-code” is that it never works in practice. Instead of getting a “better g-code”, one just ends up with two different “quirky g-codes”. Specifically, none of the slicers can remove support for the “older g-code style” (because there will be printers that don’t support it) and none of the firmware can stop supporting the “older g-code style” because there will always be prints/slicers emitting it. So, instead of “fixing g-code” one just makes “more quirky variants of g-code”. Thus, in my experience, the end result of “trying to improve g-code” just leads to “an even worse g-code”.
If I understand the proposal here, it’s mainly a semantic change. That is, one could mechanically translate to/from G1 and MOVE_WITH_EXTRUSION commands using a little math - for example one could mechanically convert a MOVE_WITH_EXTRUSION to G1 X{DESTINATION_X} Y{DESTINATION_Y} Z{DESTINATION_Z} E{MOVE_DISTANCE * EXTRUSION_WIDTH * EXTRUSION_HEIGHT / E_RATE}. For what it is worth, that’s what I’d recommend doing instead of attempting to “redefine g-code” - that is, accept that “g-code has quirky encoding rules” and just internally encode/decode to that quirky encoding as needed.
At some point in the future, of course, it might be realistically possible to fully replace g-code. I look forward to that day.
Again, this is just some of my high-level thoughts on the topic. I’m happy to be proven wrong. Please feel free to work on whatever topics you feel are worthwhile.
Cheers,
-Kevin