Open vlsi opened 11 months ago
Overall dimensions. The printer might reject or warn the user in case the printed model will not fit into the print volume
Not all printers have rectangular beds. Not all printers even have a volume that can be represented by simple shape.
Since it's not "gcode for cuboid printers only", that will limit applicability or overcomplicate specs.
If you limit "dimensions" to cuboid geometry, that will make models unprintable that otherwise will fit on delta.
Not only that but while "print" might be fitted to the bed, actual moves might be outside of the bed and that could be intended behaviour.
That also creates an issue: how do you determine (on the printer side) whether move is intended to be a part of the model (and thus lead to error) or intended out-of-bounds move (such as tool changes, wipe moves, etc)?
Total filament length for the print. It might be helpful on the info screen before user accepts the print
gcode isn't 3d printer-only file format. Even firmwares that generally used for 3d printers can be used for other things, like CNC or laser cutting.
By introducing hardware-specific entities to specs you are limiting use of the format and/or also creating unnecessary overhead.
Everything you describe have nothing to do with file format. That could be a part of the additional "agreement" on how slicer and printer interact with each other but hard coding options doesn't do any favor for the format nor for its users.
It would be great to have a standard set of keys for the metadata.
For instance: