Read ACCELEROMETER_QUERY responses using klipper-repl

[mykepredko]

I’m interested in finding out if I can use klipper-repl for recording/capturing console responses for my Klipper Board Functional Test.

I’m creating this thread to be separate from:

Read ACCELEROMETER_QUERY response in macro

Basic Information: Printer Model: Functional Tester MCU / Printerboard: KGP 4x2209 Host / SBC: CM4 klippy.log: N/A In my functional test code, I’m checking for the presence of an ADXL345 using a macro to execute the ACCELEROMETER_QUERY command but I can’t figure out how to read and parse the response in the macro. I’ve also looked at trying to change the ADXL234 values dynamically (which I should be able to capture the response) but I haven’t found any printer[adxl345]. objects that I c…

Which has become largely a Dynamic Macro discussion.

While I’m making progress with Dynamic Macros I want to continue to investigate klipper-repl as it looks like it could be a useful tool for this application and give me another option in case I run into issues with Dynamic Macros.

---

The initial post (from me) was:

@mykepredko

I’m looking at klipper_repl:

GitHub - unjordy/klipper-repl: The missing Klipper command line. A CLI G-Code REPL for 3D printers running on Klipper firmware.

and I think it might work but when I try to install it using pip:

I’m sure I’m missing something basic here but I just can’t see it.

Thanx for any help and suggestions.

With the initial reply:

@bozzo

try replacing sudo pip install ... with ~/klippy-env/bin/pip install ...

To which I did get some movement:

@mykepredko

@bozzo

@bozzo

try replacing sudo pip install ... with ~/klippy-env/bin/pip install ...

That did the trick, klipper-repl is now installed in ~/klippy-env/bin:

Now, I don’t have a link to the Klipper API (or Klipper itself) in the run folder:

This is important because when I try to run klipper-repl with /run/klipper/api as suggested in the klipper-repl GitHub page, I get:

Reading through the klipper-repl Discourse announcement:

I’m happy to announce the initial release of klipper-repl, a command line frontend for Klipper that uses the same socket API as Fluidd and Mainsail to provide an efficient G-Code REPL interface. [screenshot] Its features include: Automatic reconnection if Klipper restarts or is unavailable Support for running G-Code commands as part of shell scripts Multiple G-Code commands per line – use , as a separator Syntax highlighting for both G-Code and user-defined macros Tab autocompletion for use…

I tried using printer_data/comms/klippy.sock (which is used there but got the same error as the last post in the thread):

Now, I did try restarting the Klipper API (I know I shouldn’t have bothered, but I had to try) using the command:

~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer_data/config/printer.cfg -a /tmp/klippy_uds -l /tmp/klippy.log`

This is from the Klipper API page:

API server - Klipper documentation

I changed the printer.cfg location to match what was in the system.

I’m guessing I’m not providing the correct link to the Klipper API Socket, but I have no idea where it is.

Any ideas for next steps?

Thanx.

Now, I believe that restarting the Klipper API (at the end of the quoted text above) was the wrong way to go.

Going forward with trying to figure out the Klipper API Socket:

@bozzo

@mykepredko

I’m guessing I’m not providing the correct link to the Klipper API Socket, but I have no idea where it is.

Any ideas for next steps?

netstat --unix -p or cat /proc/net/unix might give some clues where the active klippy socket is located.

To which I replied:

@mykepredko

@bozzo

netstat --unix -p or cat /proc/net/unix

Only netstat --unix -p returned a value related to klipper:

I’m not sure what to do with 439/klipper_mcu - could you explain the next steps?

@hcet suggested I contact @flowerysong and @unjordy off line, to which @flowerysong replied:

@flowerysong

@hcet14

When you look at the issues GitHub · Where software is built, flowerysong seems to use it.

I used it once, yeah.

@mykepredko

-a /tmp/klippy_uds

-a is the flag that tells Klipper where to create the API socket. If you’re running Klipper like this, you would then run klipper-repl /tmp/klippy_uds.

My reply to @flowerysong was:

@mykepredko

@flowerysong

@mykepredko

-a /tmp/klippy_uds

-a is the flag that tells Klipper where to create the API socket. If you’re running Klipper like this, you would then run klipper-repl /tmp/klippy_uds.

I believe what I pulled out (in my desperation) was a statement that starts Klipper without any front end and produces a socket to connect to.

If I try klipper-repl with /tmp/klippy_uds I get:

but, if I look at the /tmp directory, I see that there’s klipper_host_mcu which, when run with klipper-repl, I get:

Which never returns.

So this is where things stand - I will contact @unjordy separately but it would be appreciated if anybody has an idea where I can find the Klipper API Socket.

Thanx.

[flowerysong]

It’s entirely up to your configuration. You need to figure out what’s running Klipper, and what flags it’s passing. We can’t do that for you.

One possible place to find this information is your Moonraker configuration, e.g. mine has klippy_uds_address: /run/klipper/api because I run Klipper using this systemd unit that passes -a /run/klipper/api

[mykepredko]

Hiya,

Thanx for the pointer - I should have thought of looking at moonraker.conf:

If I insert /home/biqu/printer_data/comms/klippy.sock I get the start of something:

I like seeing " ## Connected to Klipper at kgpft1:/home/biqu/printer_data/comms/klippy.sock"

I don’t like seeing anything else that is following.

---

But, I wondered if it were missing something and I tried calling a macro from the command line using something like:

~/klippy-env/bin/klipper-repl /home/biqu/printer_data/comms/klippy.sock READ_ADXL

and, when I look at the Mainsail Console, I see:

Or, going to the original question, sending:

~/klippy-env/bin/klipper-repl /home/biqu/printer_data/comms/klippy.sock accelerometer_query

and getting:

So, something’s working.

Let me see if I can capture the reply.

Thanx!

[mykepredko]

I think I’ve hit a wall here - I don’t seem to be able to get the responses for the commands sent by klipper-repl

The application works well in terms of passing commands to Klipper and hopefully getting it working here will be of use to somebody else.

@unjordy hasn’t checked in here in almost two years AND he hasn’t made any commits on GitHub for basically the same length of time so I don’t think he will be of any help.

Looking at the klipper-repl source, I feel like I could figure out how to dump responses - it’s only 256 lines of code and add it to the application but I have a working solution that looks like it meets my requirements.

So, unless somebody in the next day or so has some ideas on how to get command responses back, I’m going to assume that klipper-repl works as a method to pass commands to Klipper without getting responses from the command line or from a script.

[Mulcmu]

I’ve been using this for running remote python scripts to control printer and get responses. It works well enough for what I’ve been using it for (iterating over bed with lots of probe_accuracy and saving results to csv).

[mykepredko]

Interesting. That looks like it provides the functionality I’m looking for.

Now, are you running this from a remote terminal or can you run it on the Raspberry Pi host itself either through SSH or the keyboard/display console?

[Mulcmu]

I’ve only run it on a remote machine that was connecting to the klipper host. From what I can tell it should work on the host.

[flowerysong]

Ah, that’s an incompatibility with Python >= 3.11. async.wait() used to accept coroutines, but that’s an error now. It’s probably an easy fix, but that won’t really help you and this message is getting pretty long already.

Taking a step back, if you’re planning to call klipper-repl non-interactively to run a G-Code command and get output from that command, that’s not how it works. There’s no connection between a command and output that is produced at some point in the future.

There’s already a script for sending API commands and reading the raw result (scripts/whconsole.py) which we can use to understand why klipper-repl doesn’t output anything in non-interactive mode.

klipper@cetus:~$ python3 ~/klipper/scripts/whconsole.py /run/klipper/api 
Waiting for connect to /run/klipper/api
Connection.
{"id":"test1","method":"gcode/script","params":{"script":"RESPOND MSG=pong"}}
SEND: {"id":"test1","method":"gcode/script","params":{"script":"RESPOND MSG=pong"}}
GOT: b'{"id":"test1","result":{}}'

Processing of G-Code is asynchronous; the most that we get back when we request that a script runs is an acknowledgement that it’s been accepted (failed API calls return an "error" field instead of "result".)

Running G-Code might produce console output, which is a separate stream that we can subscribe to (which is what klipper-repl does in interactive mode.)

{"method":"gcode/subscribe_output"}
SEND: {"method":"gcode/subscribe_output"}
{"method": "gcode/script", "params": {"script": "RESPOND MSG='pong from whconsole'"}}
SEND: {"method":"gcode/script","params":{"script":"RESPOND MSG='pong from whconsole'"}}
GOT: b'{"params":{"response":"echo: pong from Mainsail"}}'
GOT: b'{"params":{"response":"x:open y:open z:TRIGGERED z1:TRIGGERED"}}'
GOT: b'{"params":{"response":"echo: pong from whconsole"}}'

As this demonstrates, console output is just an asynchronous output stream, with no easy correlation of a script request to the responses (if any) that it generates. Klipper was busy running a script from Mainsail with G4 P10000 as the first command, so I had to wait several seconds to see any output.

It would be possible to add a flag to do something like wait for a specified time or number of console events, but that would be getting pretty far from being a REPL (and the maintainer hasn’t been particularly responsive anyway.)

[flowerysong]

@flowerysong

async.wait() used to accept coroutines, but that’s an error now. It’s probably an easy fix, but that won’t really help you and this message is getting pretty long already.

Oh, it’s already been fixed. cli: py3.11 compatibility · unjordy/klipper-repl@5db0033 · GitHub

There hasn’t been a release with this fix, so you have to install from git (e.g. pip install git+https://github.com/unjordy/klipper-repl) to get it.

[Mulcmu]

For what its worth, I’ve found the moonpy send_gcode() blocks until the command is done with the exception of motion commands. Not great for responsiveness but makes the sequential execution and response query straight forward for basic scripts.

[mykepredko]

@flowerysong

There’s already a script for sending API commands and reading the raw result (scripts/whconsole.py) which we can use to understand why klipper-repl doesn’t output anything in non-interactive mode.

Interesting and fun to play with (although a lot of typing).

Going back to my previous comments in this thread, I have something that’s working and these approaches are going to take a certain amount of work to integrate into my main test script and, probably more importantly, will produce data in a different format which will require some different parsing. Not impossible but I’m not sure of its value when I have something already looking.

---

I’ve just spent some time going through the code and, honestly, it wouldn’t be a huge amount of work to change whconsole.py to add another parameter to the command line options, add it into a {"id":... string, send it, wait a second and then printf the response (maybe even format it a bit).

The test will be checking BL Touch for presense, ability to extending followed by retracting the probe and, finally, it’s ability to detect that the probe has been touched and it is “Triggered”. If I can do that fairly easily with Dynamic Macros then I’ll probably stick with them.

If it turns out to be a problem, I’ll look back at whconsole.py and MoonrakerPy.

[mykepredko]

@Mulcmu

For what its worth, I’ve found the moonpy send_gcode() blocks until the command is done with the exception of motion commands. Not great for responsiveness but makes the sequential execution and response query straight forward for basic scripts.

When you say “motion commands” do you mean something like G1? Do these work at all? I’m asking because I am specifying stepper movements in the test code.

When you’re running locally, what is the parameter for moonpy.MoonrakerPrinter('http://192.168.1.69') the documentation says it must be “the web/IP address” - can you use the Mainsail web page URL?

[Mulcmu]

@mykepredko

G1?

Yeah, G1, G28 motion commands work fine. Can use M400 to wait for motion to finish if need be in the script.

IP of host by itself should be fine unless you have multiple klipper/moonrakor installs. If you have more than one printer installed on the same host then you’d need the right port number.

[mykepredko]

@Mulcmu

IP of host by itself should be fine unless you have multiple klipper/moonrakor installs. If you have more than one printer installed on the same host then you’d need the right port number.

That’s not quite answering my question - the test will take place in China and I have not idea/control over what is the IP address.

This is why I’m asking about the Mainsail URL.

[Mulcmu]

I just skimmed the thread and didn’t pick up on the application. IP or URL should both work. If script will run on the host using 127.0.0.1 or localhost as address would eliminate any network problems from causing a snag.