[FEATURE REQUEST] Quality of Live Features

[moghyukon]

A set of Quality of Live Features would be helpful for debugging and keeping Code clean.

Following Features should be in FC as a information and gcode file output:

• Slicer (to be displayed in various print environments (-> Marketing!?)
• Preview Image (A blue lined image would be enough I guess) or at least a default FC Logo ( -> Marketing!?)
• Layers (mainsail Klipper needs extra lines to work properly https://docs.mainsail.xyz/overview/slicer/prusaslicer#layer-count
• Object Dimension
• Nozzle Diameter
• Filament Type
• Filament Usage (estimated)
• Filament Weight (estimated)
• Print Time (estimated)
• Min/Max Travel Speed
• Min/Max Print speed
• Min/Max Volumetric Flow
• FC Version
• Buildplate representation (preferably to work with Prusa-Gcodeviwer)
• implement extrsusion type gcode comment for Gcode viewers
  

I know some are flavor / slicer specific but I guess aligning to one of the main Slicers does no harm? -> for Example in my case I use Prusa Extrusion type to distinguish the different type.

I did incorporate some simple stuff into my code like travel moves and layers but it also makes the code cluttered.

Mainsail working Layer count:

Mainsail Example Filelist view:

Additional Info: Harware/Software: Voron Triden 350 Mainsail / Klipper Dragon HF + CHT 0.6

[ES-Alexander]

Some thoughts (from an occasional contributor to this project):

• Most of these seem like they'd be quite straightforward to determine values for, and the exporting should also be straightforward as long as there are decent examples and/or documentation available for the formats required for the relevant viewing softwares
• Automatically generating preview images may be a bit fiddly to get decently consistent behaviour for, but it should at least be possible as a small extension of the existing visualisation options
  • That said, I'm curious what format such an image should be in, and where it should go, since gcode files are just text comments and lines of machine instructions, unless you're thinking of something like a 3MF export (discussed somewhat in #20)?
• As I understand it FullControl itself doesn't have a concept of layers, which I see as part of why it was created - it's not slicing existing models into layers, and things like vertical extrusions often can't be meaningfully expressed in terms of layers
  • That said, some design outputs may take the form of layers, in which case I can't imagine it would hurt to provide a LayerChange object that allows tracking that for people who want to make use of it
  • Extrusion types sit in a similar category
• print time, volumetric speed, and total volume(/filament) estimates are (briefly) discussed/mentioned in #22, but not currently implemented
  • volume estimation is approachable from a few different angles, and likely needs some discussion on choosing the most appropriate one, or provide multiple options the user can choose between (with varying degrees of calculation time required vs accuracy)

[moghyukon]

• Picture format is png at 2 different sizes for prusa and its forks -> its 2 blocks formatted by linebreak at the beginning of the gcode ( it would be probably best to look at the code from prusaslicer which is public )
• A static picture (Logo) would be fine by me for Marketing and visual differentiate the files on the printer

[fullcontrol-xyz]

Thanks for these suggestions. I can see the value in them and some are v easy to implement. My main desire would be to keep things generic and not tied in to a particular slicer. In some cases, it may be better to communicate how a designer can add these things to their design for their specific system/viewing software. I presume you used a GcodeComment in the design with the correct format for a 'layer-change' identifier or an 'extrusion-type' identifier. I can see how this might make the code a little cluttered, but am not sure there's a way around this, since the concept of 'layers' is very flexible in FullControl as as mentioned by ES-Alexander. It is a little more effort, but it means the overall code base stays simple and I expect the most important thing is a good demonstration/tutorial that is easy to find. Keeping things translatable beyond purely desktop polymer 3D printing is nice when possible. The png for prusa seems like an easy thing, but is very printer specific. It begins to get complicated if all the different printers have different formats and only some are supported - it could end up confusing for the end-user. But I definitely see how it could work. I'll put some of these in the roadmap for short term implementation since they're obviously just valuable for everyone (i.e. report of the design print time and similar). For others, we're currently working on opening up fullcontrol to all the printers in cura (or prusaslicer). Once that is done, it will be clearer about how we might have printer-specific outputs with logos or not logos, etc.

Thanks again for the suggestions. Lots of interesting things, and many of them overdue in FullControl!