Add configurable action command to send when printer is killed

[benlye]

Sends user-defined string as action command when printer is killed.

Spawned from conversation in #7137, where a couple of people thought that informing a connected host that the printer has been killed in a user-configurable, language agnostic, way would be useful.

I'm sure there are other action commands which it would be useful for the printer to send, but a 'kill' action is the one which seems most useful to me. With that in mind, I couldn't decide if the variable should be KILL_ACTION, which groks easier, or ACTION_KILL, which lends itself to being in a list of other action definitions. I don't feel strongly either way.

[Roxy-3D]

USER_SPECIFIED_ACTION_AT_KILL leaves very little doubt about what is being specified and when it will be invoked. For something as important as this... It doesn't bother me to have a slightly longish name.

[fiveangle]

But I do see how having all ACTION_* strings in a common location useful, and prefixing with "USER_SPECIFIED_ACTION" doesn't really lend itself well toward finding if someone is looking for "ACTION" items (which is what other host software like Repeteir and Octoprint lump them into).

I do like ACTION_AT_KILL (since ACTION_AT_SUICIDE as per some existing internal values seems a bit melodramatic ;)

[Roxy-3D]

Yes. You are correct...

I don't really care what the name is. But I want it very obvious what it means when it shows up in the code some where. Let's not skimp on characters for the name just to make it short. I prefer something like this is very very obvious!

And if the user presses the Kill button on the LCD Panel, it isn't a 'Suicide'. The firmware didn't kill itself. :)

[thinkyhead]

Two minor changes needed…

[thinkyhead]

Please clone these lines to the same position in all Configuration_adv.h files in example_configurations. The easiest way is to globally replace the unique lines that precede this addition with those same lines, plus this addition.

[benlye]

Will do - wanted to have the conversation about the parameter name before I went and edited a bunch of files. ACTION_ON_KILL seems good to me. Do you have a preference?

[thinkyhead]

Please use this instead to save on SRAM:

SERIAL_ECHOLNPGM("//action:" KILL_ACTION);

[benlye]

Not to be pedantic, but ACTION_ON_KILL sounds better to me than ACTION_AT_KILL, and I think that syntax will work well for any future action commands. I'm ready to update the PR with @thinkyhead's changes and the revised name as soon as there is consensus.

[fiveangle]

ACTION_ON_KILL sounds better to me than ACTION_AT_KILL

Agreed. But it looks like Scott doesn't want to change the string name throughout ? Maybe make the change as he describes for now, and if the action commands take off, we can revisit renaming so all actions are prefixed with "ACTION_" at a later time ?

EDIT: I see that Scott's comments were only to omit the comma operator from the SERIAL_ECHOLNPAIR to save SRAM, so I think you're good to go for ACTION_ON_KILL.

[fiveangle]

But I want it very obvious what it means when it shows up in the code some where.

To @Roxy-3D 's point, the ACTION is a host feature class that probably deserves some form of simple documentation on the wiki. @benlye - do you have an idea on where you could inject this info ? Also, your new Mcode probably needs an entry ?

ps- I don't think others realize the possibilites this opens up. Nice work 🥇

[benlye]

I've changed the serial out method to SERIAL_ECHOLNPGM, made the modification to all the configuration_adv.h example files, and in the absence of any other feedback I went ahead and changed the parameter name to ACTION_ON_KILL.

[thinkyhead]

This is a great contribution, simple as it is. Thanks!

Perhaps we ought to also add "CAP:HOST_ACTIONS:1" to M115 output when this is enabled.

If it seems like "HOST_ACTIONS" isn't needed, that's fine. A host will or will not respond to action strings based on its own settings, and probably doesn't need to be pre-warned to expect them.