The idea is simple: you define one or more gcode subprograms after the end of the main code. The subprogram is bookended with O<number> and M99, and it gets called with M98 P<number> in the main program. See this image lifted from gcodetutor.com for a visual explanation.
When printing many of the same part, you can pair subprograms with machine coordinate offsets (G54..59) to effectively array the subprogram across many points on the bed. This will result in "one at a time" printing which is a BIG benefit for production runs. You do have to take care to make sure the print head and gantry clear all the completed parts, but that's easy enough.
NOTE: machine coordinate offsets do not need to be handled or recognized by this new plugin, they are only mentioned to clarify how subprograms can be effectively used.
At first I thought this gcode behavior should be implemented in the firmware, but the more I think about it the more I think it would be easier to implement on the server side. Anybody want to take up writing this plugin? From my limited programming experience it seems like it should be straightforward enough. But I don't have the ability to dive into learning how to write plugins myself.
Alternate plugin behavior if it's easier to implement could be to use an @<trigger> (à la Octolapse, GcodeMacros, etc) to call a separate gcode file then return to the main program when finished. This alternative behavior would have a workflow benefit of being able to swap out the subprogram on the server without touching the main program, making updates to the part (e.g. design changes, print optimizations, etc) a little more streamlined, but at the cost of keeping track of multiple files for a single print job.
, and when I dug into where the macro data was stored it was just in the config file that a lot of other plugins shared. So that plugin (currently) isn't set up to be able to do this.
