Community driven duet sanity checker - how feasible?

zapta

I saw in another thread the comment "Dynamic acceleration adjustment has less effect when using high jerk" and wondered, how feasible is it to have software that provides automatic sanity check of duet's configuration. For example by querying the duet over http or by pasting some gcode response into the tool and then getting a list of warnings.

It doesn't have to be perfect to be useful and with proper software structure, more rules can be added by the community over time, similar to 'lint' tools that programmers used to verify their code.

Considering some programming ang gcode talents here I thought this may work but am not sure.

Any thoughts?

Danal

Interesting idea. Getting and parsing the file is certainly easy enough. In fact, I would be OK with saving a zip of every .g file in /sys and uploading that zip to a checker. Full automation would be cool... but...there are so many variations of connectivity, just make it a few clicks for the human and it gets hugely more robust.

Anyway, that's physical logistics... let's talk about the "business rules" the config-lint rules. Many things come immediately to mind. Also, some warnings, some errors

Pin definitions that are not later used. (Warning)
Mismatches between a tool definition and the heaters, sensors, etc on which it is based. (warning)
Missing required elements (perhaps by Kinematic type or other determinant) (error)
Things that are there that shouldn't be (SSID save for WiFi, wears out the module flash) (error)

And so forth.

Having said all of that... I've never looked at the encoding (the 'language') for lint rules. It would be nice to start with something like that. Anybody have ideas of a structure with which to start?

zapta

@Danal said in Community driven duet sanity checker - how feasible?:

Getting and parsing the file is certainly easy enough.

Are you thinking reading the config files or just querying the state of the printer after the configuration was read and settled down?

Edit: with state based check, if the duet has a concept of an object model representing its state than the checks can be performed on that model. E.g. if <some pattern or condition met> then emit <some message> or something along these lines.

Danal

I believe that directly connecting to a running printer introduces a huge layer of unnecessary complexity. Does the checker connect from the cloud? Lots of security to think about. Does the checker run on a local PC? Windows? Linux? Pi? If locally installed, how are the rules updated?

Just seems simpler to zip /sys/*.g and upload it to a cloud based checker.

Plus if the checker checked the object model, it cannot catch things in config.g that are "erroring out" and not building an object...

zapta

@Danal, yes, good points.

zapta

@Danal, if you are good with web page, the config analyzer can also have an interactive user interface, similar to those used by code programmers, with annotations, links to entries in the duet gcode reference page, and so on.

alt text

There is a lot that can be done in this area but probably the best option to to first start with something, even very minimal.