Set any parameter per G-Code to get saved with SAVE_CONFIG afterwards

[ProfDrYoMan]

Hi,

a nice feature in Redeem/BBB is to be able to change parameters via G-CODE.

In Redeem, this is done by many Mxxx G-Codes. This is not likely the way Klipper might do it.

Anyhow, a feature like this would be nice. Something like:

SET_PARAMETER stepper_x/step_distance=0.0225

SAVE_CONFIG

Done.

[klipper-gitissuebot]

Hi @ProfDrYoMan,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[ProfDrYoMan]

Addon: Driven by the discussion here: https://forum.makerforums.info/t/replicape-recore-firmware-changes/79010/6: "What is in Redeem and not in Klipper".

"I am not sure if there is something like pin-name-aliases already. …" <= Is there something like that?

[KevinOConnor]

a nice feature in Redeem/BBB is to be able to change parameters via G-CODE.

The closest equivalent in Klipper is to install the OctoKlipper plugin. It has the ability to modify the Klipper config file via a web browser and apply those changes to Klipper.

FWIW, my high-level feedback is that a "terminal interface" isn't a good way to configure a 3d printer. I know of several developers interested in a direct http interface to Klipper. I suspect configuration functionality is best done via config files and web interfaces.

"I am not sure if there is something like pin-name-aliases already. …" <= Is there something like that?

Take a look at the [board_pins] support in config/example-extras.cfg.

Driven by the discussion here: ...

FWIW, one issue with Klipper on the Beaglebone has been the fragile nature of the Linux distributions for the Beaglebone. Basically, they keep making non-backwards compatible changes - seemingly every couple of months. The low-level Klipper gpio and PRU code has been stable, but it's been a nightmare getting Klipper installed and running on anything other than the exact Linux versions tested. :-(

-Kevin

[ProfDrYoMan]

Hi Kevin. I fully agree that a proper web based setup is always better than an terminal based one.

Thanks for that information: https://github.com/KevinOConnor/klipper/blob/master/config/example-extras.cfg#L508

As for the BBB. It took me 2h to fiddle out how to get Debian 10.x for BBB up and running with the PRUs. Yes, there are changes, but getting some kernel-agnostic boot scripts for PRU and klippy would not be that hard if somebody really wants to.

[goeland86]

Just to butt in - since I was the one who made the initial comment about g-code configuration of the firmware - the idea was to eventually create an OctoPrint plugin that would start a configuration wizard, and issue the relevant G-code and M-code commands to setup the configuration based on what the various inputs become.

The idea that you have to write the whole config file in one go feels very arduino-ish to me, despite the fact we're dealing with something leaps and bounds more advanced. That is why I think there must be a better way than editing the config file by hand, where typos can create heaps of issues.

[DMCShep]

@goeland86 FWIW this sounds like something fairly easily included in this ticket that I have on my "To Do" list: #2205 (comment)

Effectively, the config settings are quite scattered, so the first step I will be undertaking is building a web-based front end to categorize them, making them searchable with filters etc. Later I will be including a few utilities (a steps/mm calculator for example) -- a config creator isn't a bad idea and something I can easily tackle.

While it's true that certain things can't be set dynamically mid-print, macros may help with this. But for the things that are static, a wizard should help.

Side note: OctoKlipper has been widely reported in the Klipper Discord to completely wipe out printer.cfg files while editing them, rather than save them correctly. It appears to be a nasty bug, most of us recommend keeping backups on a desktop for this reason. SD cards test out fine before and after occurrences, but oddly Duet Web Control installs do not seem to fall victim to this, even though a printer.cfg editor is built in.

[goeland86]

@DMCShep we've run into something similar with the OctoPrint_Redeem and OctoPrint_Toggle plugins on our end as well. I'm guessing it has more to do with OctoPrint's backend itself than the plugins directly, but of course it happens so rarely that it's really hard to provide foosel with the required data to reproduce it...

Regarding your to-do list, indeed it seems that the config builder would fit right in, and if I can contribute in any way, please let me know.

I'm happy to say I've managed to get a build of Umikaze to an alpha stage where Klipper is installed by default with OctoPrint and OctoKlipper, and the PRUs respond. Further testing needed, but if anyone wants the image, let me know.

[DMCShep]

That makes sense that OctoPrint may have some underlying bugs, I know certain things are known to need rework but the degree of work and planning involved in fixing them is massive reading through the GitHub issue tickets, this may take a while. I will definitely spread the word on Discord to check the logs -- anything I need to know to tell people that may want to try to replicate?

I will be open-sourcing my project, BSD license as always. Not sure what language yet, might be a good use case to get finally started with Python, depends if I can make a web server out of it (discussion on that front would probably be better in issue #2205 that said).

Umikaze I haven't heard of yet -- need to google that one!

[goeland86]

Umikaze is the beaglebone Ubuntu image that I was making with the Replicape community. It previously bundled OctoPrint, Toggle and Redeem with a few other minor tweaks. The new version includes Klipper & OctoPrint. Build scripts are in my fork/branch here: https://github.com/goeland86/Umikaze/tree/convert_to_ansible

[DMCShep]

Ohhh, cool!

Are there logs that may help if someone on our Discord can reproduce? We have over 1,200 members so it's only a matter of time before someone runs into it again -- especially if some decide to try and make it fail. I will make sure they get posted to your GitHub when/if we can but want to make sure everything you are looking for is supplied when it happens. Replication will be hit-or-miss but I am wondering if verbose logging options can help pinpoint the cause.

[goeland86]

The ansible logs are pretty verbose by default, and until it's merged into my master branch, it should be considered an alpha-version of how to build Umikaze... I hope to stabilize it soon, and hopefully provide a set of scripts to define the necessary states of multiple components for a running image. Of course I'll keep generating the Umikaze images, ready-to-run Klipper for Replicape linux images to put on the Beaglebone.

[DMCShep]

Oops I meant for OctoKlipper deleting logs, not the Umikaze thing, sorry should've specified!

[goeland86]

Ah, my bad! I dunno what logs need to be looked at - it's so rare that I usually just pasted my config back in and tried again...