Input Shaping - "Start Input Shaping" Missing

As my configuration is not the standard one (Spider Board connected via GPIO-UART-Connection) I tried to install Input shaper via Repetier-Server, but the installer script failed during flashing the controller. So I installed Input shaper manually in the console. It works fine from console now but the menu entry "Start Input Shaping" and "Show Input Shaping Results" in RS is missing.
How can I tell Repetier Server that I already have installed input shaper and RS can use it, especially showing the results? 


  • The menu entries appear if your config has these three section in main configuration:
    [mcu rpi]

    Not sure if they can be added in your case especially with mcu rpi, but with them the menu entries should appear. From server side they can be empty if klipper can live with it.
  • OK, I will try!
    As I understand right, RS looks only for these entries in klipper-config-file to decide if input shaper is installed?
    In my case I have an mcu section named [mcu rpi2]. klipper does not regulate the name of the [mcu] section, means the name is not limited to rpi. But if RS needs it I will rename it.
    I already have another software mcu section as I have a 23017 I2C-Expander adapted...
  • "Start Input Shaping" appears in the menu list.
    If I start it, it does the homing, goes to the given coordinates, seems to start the shaking process but aborts with the following error: 

    --2023-12-30 21:05:01--
    Resolving (
    Connecting to (||:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 1253 (1.2K) [application/octet-stream]
    Saving to: '/tmp/'
    /tmp/inputShaping.s 100%[===================>]   1.22K  --.-KB/s    in 0s      
    2023-12-30 21:05:01 (33.2 MB/s) - '/tmp/' saved [1253/1253]
    No data for x axis found - skipping axis.
    No data for y axis found - skipping axis. 
    The printer goes offline and klipper reports:
    Lost communication with MCU 'rpi'
    After klipper restart the printer is online again.

    OK, so I reinstalled input shaping over the menu entry, which worked after three (or even more) tries of searching different python wheels, install scripts  and installing numpy (which was already installed by myself, but anyway) with sometimes success sometimes not...
    Then I started the process input shaping again and it aborted after round about 6 % progress again with the above error. Trying the recovery brings the printer online again.

    So what happens here?
    I think there are some prerequisities or preadjustments not satisfied.

    To answer the divined question if the accelerometer hardware is ok: Yes, it is!
    If I start G28 and TEST_RESONANCES AXIS=X from console, the shaping runs perfect and writes the data to /tmp/resonances_x_<date>.csv. Same with y-axis.

    I really like the integration of klipper in RS but sometimes I ask myself:
    "Why not using what is already implemented by klipper?" 
    "Why do I need an installer script (which is loaded via internet)?" Is there not a simpler method of integration than installing everything again in the RS sandbox? This method would be good if it would work out of the box, but IMHO it creates more trouble than it solves.

    Sorry for these clear words. I do really like your products and have it since years. I reallly really appreciate the unreached support in this forum by you. But in this case I ask myself: Why reinvent the wheel?
  • Here is the relevant part of the console output:

    Recv:21:57:52.544: // Disabled [input_shaper] for resonance testing
    Recv:21:57:52.544: // Testing frequency 1 Hz
    Recv:21:57:52.546: // Testing frequency 2 Hz
    Recv:21:57:52.548: // Testing frequency 3 Hz
    Recv:21:57:52.550: // Testing frequency 4 Hz
    Recv:21:57:52.554: // Testing frequency 5 Hz
    Recv:21:57:55.974: // Testing frequency 6 Hz
    Recv:21:57:56.951: // Testing frequency 7 Hz
    Recv:21:57:57.054: // Klipper state: Shutdown
    Recv:21:57:57.462: !! Internal error on command:"SHAPER_CALIBRATE"
    Recv:21:57:57.462: ok
    Recv:21:57:57.463: // Lost communication with MCU 'rpi'
    Recv:21:57:57.463: // Once the underlying issue is corrected, use the
    Recv:21:57:57.463: // "FIRMWARE_RESTART" command to reset the firmware, reload the
    Recv:21:57:57.463: // config, and restart the host software.
    Recv:21:57:57.463: // Printer is shutdown
    Exec:21:57:57.463: @syncMotion
    Recv:21:57:57.463: !! Lost communication with MCU 'rpi'
    Recv:21:57:57.463: ok
    Send:21:57:57.463: Slow command added:M400
    Send:21:57:57.463: N28 M400

  • It is important not to switch the tab, especially in chrome or you can loose connection to linux terminal and it exits before being finished. Reason is chrome throttels inactive tabs. For me calibartion always works, but when I look into your log and i see:
    Recv:21:57:57.462: !! Internal error on command:"SHAPER_CALIBRATE"

    this comes from klipper, which apparently thinks it lost connection to rpi which is required for the command, so it fails and shuts down it self. Can you execute
    from console or does it then also shutdown? Actually it is just send as manual command like over console, so it is the same except that server is watching for output and command to finish. See in klippe rlog maybe you see more infos there, but we can not anything when a command inside klipper fails.
  • It is important not to switch the tab,
    I did not. The operation stops after a short while (~ 6 % progress) whitout any user action.

    Tried the command via console:

    Recv:11:47:53.417: // Disabled [input_shaper] for resonance testing
    Recv:11:47:53.418: // Testing frequency 1 Hz
    Recv:11:47:53.419: // Testing frequency 2 Hz
    Recv:11:47:53.421: // Testing frequency 3 Hz
    Recv:11:47:53.423: // Testing frequency 4 Hz
    Recv:11:48:18.763: // Testing frequency 28 Hz
    Recv:11:48:19.768: // Testing frequency 29 Hz
    Mesg:11:48:20.317: Warning: Communication timeout - resetting communication buffer.
    Mesg:11:48:20.317: This means that a expected firmware response was not seen within the expected time.
    Mesg:11:48:20.317: The typical reason is a communication error and print should continue after the communication reset.
    Mesg:11:48:20.317: Connection status: Buffered:73, Manual Commands: 0, Job Commands: 0
    Mesg:11:48:20.317: Buffer used:73 Enforced free byte:0 lines stored:1
    Recv:11:48:20.780: // Testing frequency 30 Hz
    Recv:11:48:21.778: // Testing frequency 31 Hz
    Recv:11:48:22.491: // Klipper state: Shutdown
    Recv:11:48:22.879: // Testing frequency 32 Hz
    Recv:11:48:22.891: !! Internal error on command:"SHAPER_CALIBRATE"
    Mesg:11:48:22.891: Received extra ok - ignored

    Shutdown: Lost communication with MCU 'rpi' ....

    Tried the klipper proposed:
    Send:11:58:45.407: TEST_RESONANCES AXIS=X
    Recv:11:58:49.072: // Disabled [input_shaper] for resonance testing
    Recv:11:58:49.072: // Testing frequency 5 Hz
    Recv:11:58:49.072: // Testing frequency 6 Hz
    Recv:11:59:14.410: // Testing frequency 32 Hz
    Recv:11:59:15.413: // Testing frequency 33 Hz
    Recv:11:59:16.407: // Testing frequency 34 Hz
    Mesg:11:59:16.407: Warning: Communication timeout - resetting communication buffer.
    Mesg:11:59:16.407: This means that a expected firmware response was not seen within the expected time.
    Mesg:11:59:16.407: The typical reason is a communication error and print should continue after the communication reset.
    Mesg:11:59:16.408: Connection status: Buffered:23, Manual Commands: 0, Job Commands: 0
    Mesg:11:59:16.408: Buffer used:23 Enforced free byte:0 lines stored:1
    Recv:11:59:17.423: // Testing frequency 35 Hz
    Recv:11:59:18.412: // Testing frequency 36 Hz
    Recv:11:59:19.428: // Testing frequency 37 Hz
    Recv:12:00:53.468: // Testing frequency 131 Hz
    Recv:12:00:54.463: // Testing frequency 132 Hz
    Recv:12:00:55.465: // Testing frequency 133 Hz
    Recv:12:00:55.972: // Re-enabled [input_shaper]
    Recv:12:01:03.217: // Wait for calculations..
    Recv:12:01:04.945: // Resonances data written to /tmp/resonances_x_20231231_115845.csv file
    Mesg:12:01:04.945: Received extra ok - ignored

    No shutdown at all! The results are there as described.

    For me it seems like the same communication error appears in the test resonances script  but leads not to a stop of the operation. The shaping script waits and starts testing at the new frequency.
    Any ideas?

  • One more question:
    If I select the menu item "Start Input Shaping", what happend then internaly?
    You are writing:
    Actually it is just send as manual command like over console
    Where is defined what script is triggered than?
    Perhaps I can change that to my guess. 
    The downloaded shell script is as far as I see only a wrapper for the data analysis through "" and copies the input and outputs to other locations.

  • For next release and current dev version (installDev on our pi images to get it there) have the command now added to slow commands, so no timeout will occur any more. Also removed some options in config which make no sense for klipper.
  • Thanks repetier, I will try that!
    Repetier said:
    installDev on our pi images to get it there
    Means the NightlyBuild?

  • No installDev i sonly for armhf and is faster build. Nightly will only available tomorrow with that fix while dev is already up to date. But both will do the same if you wait until tomorrow.
  • Installed the Nightly 2024-01-01 Pro 1.4.15:
    Unfortunately the same behavior. TEST_RESONANCES AXIS=X and Y works, Menu entry  and SHAPER_CALIBRATE AXIS=X NAME=data FREQ_START=1 FREQ_END=133 HZ_PER_SEC=1 do not.
    Don´t see how to come further....
    Will change the Pi, the accelerometer and the cables now. We will see...
    Anyway thanks for your efforts repetier.

  • As said use installDev the nightly is with fix is only available tomorrow wioth date 2024-01-02. But this only fixes the timeout issue if yout timeout is shorter then time for execution.
    But since klipper says
     !! Lost communication with MCU 'rpi'
    before timeout there is a issue with communication. Broken cable, bad soldering, some other software using i2c, ...
  • Installed the Nightly from 2.1.2024.
    Same behavior!
    I'll check/exchange the hardware...
  • Just for the records:
    I checked the whole wiring and especially all connectors. I removed the connectors and reconnected everything and checked the continuity on the toolhead. The error seems to be gone now (means it did not occur during up to the last five tests).
    I suppose it was a bad connection which reveals during shaking but this is only speculation.
    Anyway, this issue can be closed as it seems not to be related to repetier server. Sorry for the trouble...
Sign In or Register to comment.