I’ve got a shell script to emulate a PC speaker beep by running speaker-test that works when I run it from terminal locally or over SSH, but it won’t run properly from the console in Klipper as called by a macro using Gcode Shell Command. For background, I’m a Windows admin and an Azure engineer with a nearly forgotten history in Linux web admin for Hostgator and Softlayer, so I know exactly enough to be dangerous in bash. I even know enough to recognize this isn’t really a Klipper question, but by science it sure is dressed up like one.
My method is sloppy, but it works in everything but Klipper. Broadly, it works like this:
Define a function to send a sine wave to the audio service and then kill the process after a set time instead of figuring out how to stop the sound properly, piping stdout and stderr to /dev/null so it doesn’t fill Klipper’s console
Call that function exactly once, specifying frequency and duration as parameters
Force restart the audio service to avoid hearing the remainder of the already piped audio
This is clunky, to be very generous.
The macro, followed by the script, for those interested:
I’m assuming this is down to the klippy service not having access to something, but I’m not sure what it would be. Any guidance would be greatly appreciated.
I did, but I wasn’t getting anything useful - just the stdout from speaker-test and an error from systemctl that I expected because I was sloppy. Thanks for the suggestion though!
EDIT: I should clarify - set -x matched the exact output from the shell but where I get the tone to sound off in the shell, it didn’t from the macro:
08:57:53
Failed to connect to bus: No medium found
That’s the error from systemctl. I’m expecting this. I still have an inkling that it’s pointing at the lack of a connection to the audio subsystem, but I can’t turn anything else up about it.
08:57:53
+ kill -9 2625783
/home/twoscoopsofpig/beep.sh: 9: kill: No such process
+ systemctl --user restart pipewire.service
The very sloppy kill -9 failing is weird too, but again, I’ve chalked it up to being some sort of persistence issue or session handling thing. There’s no other indication that it’s affecting the script run.
Ah! That makes sense. I’d kind of glossed over that in my troubleshooting -since I installed GCode Shell Command as an extension from KIAUH, it got muddied in my mental model. I’ve been assuming that when Klipper runs the macro it would ALSO run the script because I’ve been assuming the session context carries through the whole stack.
Does GCode Shell Command run from Mainsail’s context instead of Klipper’s?
Python may be the missing link here. If Klipper isn’t not invoking the script directly, that may be where the chain breaks down. Windows has a problem with credentials being passed from one context to another (CredSSP is a mess) so I can imagine this being somewhat similar.
I’ll see what I can find in the logs when the macro runs. I really appreciate the insight!