Gaurav Manek

I don't have write access either.

There's a bunch of useful static GCode analysis that can also be done in the same Moonraker plugin. I'll report back in a couple of weeks.

Made the requested changes! - Single STEP file - No spaces in filenames - Updated the compatibility chart

Awesome, I'll look into it!

Oh, you don't need to change the OUT_SIZE at all. Simply set the type of board in HT1632.h and see this example: https://github.com/gauravmm/HT1632-for-Arduino/blob/master/Arduino/HT1632/examples/HT1632_Heart_Multiple_Bicolor/HT1632_Heart_Multiple_Bicolor.ino

Oh, dear. I missed your message. I'll look into it and reply in a few days? Gaurav

Okay, each screen now has its own, independent buffer. You need to draw the string on each channel and each screen independently. 1) The screen alignment issue is likely due...

I'm attempting the plugin route, but with a Python implementation of the estimator. The goal is to also offer more functionality (essentially static analysis tools)

I'm happy to do this as a moonraker plugin -- it will fit nicely with the gcode server plugin I was writing.

The current idea is that this is dynamically calculated (and cached) by a moonraker plugin, so no slicers need to be involved, it can pull the latest Klipper configuration information...