Frix-x
MCU 'mcu' shutdown: Timer too close still present
K-Shake&Tune module branch
- [X] I confirm using the main branch
Version
v4.0.1-0-g69ad2283
Describe the bug and expected behavior
i belive problem appeared after first axis check
`` BatchBulkHelper batch callback error Traceback (most recent call last): File "/home/klipper/klipper/klippy/mcu.py", line 71, in _do_send return xh.get_response(cmds, self._cmd_queue, minclock, reqclock) File "/home/klipper/klipper/klippy/serialhdl.py", line 327, in get_response raise error("Unable to obtain '%s' response" % (self.name,)) serialhdl.error: Unable to obtain 'sensor_bulk_status' response
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 72, in _proc_batch msg = self.batch_cb(eventtime) File "/home/klipper/klipper/klippy/extras/adxl345.py", line 294, in _process_batch samples = self.ffreader.pull_samples() File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 270, in pull_samples self._update_clock() File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 242, in _update_clock params = self.query_status_cmd.send([self.oid]) File "/home/klipper/klipper/klippy/mcu.py", line 75, in send return self._do_send([self._cmd.encode(data)], minclock, reqclock) File "/home/klipper/klipper/klippy/mcu.py", line 73, in _do_send raise self._error(str(e)) gcode.CommandError: Unable to obtain 'sensor_bulk_status' response BatchBulkHelper stop callback error Traceback (most recent call last): File "/home/klipper/klipper/klippy/mcu.py", line 71, in _do_send return xh.get_response(cmds, self._cmd_queue, minclock, reqclock) File "/home/klipper/klipper/klippy/serialhdl.py", line 327, in get_response raise error("Unable to obtain '%s' response" % (self.name,)) serialhdl.error: Unable to obtain 'sensor_bulk_status' response
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 72, in _proc_batch msg = self.batch_cb(eventtime) File "/home/klipper/klipper/klippy/extras/adxl345.py", line 294, in _process_batch samples = self.ffreader.pull_samples() File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 270, in pull_samples self._update_clock() File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 242, in _update_clock params = self.query_status_cmd.send([self.oid]) File "/home/klipper/klipper/klippy/mcu.py", line 75, in send return self._do_send([self._cmd.encode(data)], minclock, reqclock) File "/home/klipper/klipper/klippy/mcu.py", line 73, in _do_send raise self._error(str(e)) gcode.CommandError: Unable to obtain 'sensor_bulk_status' response
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "/home/klipper/klipper/klippy/mcu.py", line 71, in _do_send return xh.get_response(cmds, self._cmd_queue, minclock, reqclock) File "/home/klipper/klipper/klippy/serialhdl.py", line 327, in get_response raise error("Unable to obtain '%s' response" % (self.name,)) serialhdl.error: Unable to obtain 'spi_transfer_response' response
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 62, in _stop self.stop_cb() File "/home/klipper/klipper/klippy/extras/adxl345.py", line 289, in _finish_measurements self.set_reg(REG_POWER_CTL, 0x00) File "/home/klipper/klipper/klippy/extras/adxl345.py", line 232, in set_reg stored_val = self.read_reg(reg) File "/home/klipper/klipper/klippy/extras/adxl345.py", line 227, in read_reg params = self.spi.spi_transfer([reg | REG_MOD_READ, 0x00]) File "/home/klipper/klipper/klippy/extras/bus.py", line 98, in spi_transfer return self.spi_transfer_cmd.send([self.oid, data], File "/home/klipper/klipper/klippy/mcu.py", line 75, in send return self._do_send([self._cmd.encode(data)], minclock, reqclock) File "/home/klipper/klipper/klippy/mcu.py", line 73, in _do_send raise self._error(str(e)) ``
after that i decided to run test again, but new error appeared. idk if thats related
`Internal error on command:"_COMPARE_BELTS_RESPONSES"
Traceback (most recent call last):
File "/home/klipper/klipper/klippy/gcode.py", line 211, in _process_commands
handler(gcmd)
File "/home/klipper/klipper/klippy/gcode.py", line 137, in
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 72, in _proc_batch msg = self.batch_cb(eventtime) File "/home/klipper/klipper/klippy/extras/adxl345.py", line 294, in _process_batch samples = self.ffreader.pull_samples() File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 270, in pull_samples self._update_clock() File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 242, in _update_clock params = self.query_status_cmd.send([self.oid]) File "/home/klipper/klipper/klippy/mcu.py", line 75, in send return self._do_send([self._cmd.encode(data)], minclock, reqclock) File "/home/klipper/klipper/klippy/mcu.py", line 73, in _do_send raise self._error(str(e)) gcode.CommandError: Unable to obtain 'sensor_bulk_status' response BatchBulkHelper stop callback error Traceback (most recent call last): File "/home/klipper/klipper/klippy/mcu.py", line 71, in _do_send return xh.get_response(cmds, self._cmd_queue, minclock, reqclock) File "/home/klipper/klipper/klippy/serialhdl.py", line 327, in get_response raise error("Unable to obtain '%s' response" % (self.name,)) serialhdl.error: Unable to obtain 'sensor_bulk_status' response
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 72, in _proc_batch msg = self.batch_cb(eventtime) File "/home/klipper/klipper/klippy/extras/adxl345.py", line 294, in _process_batch samples = self.ffreader.pull_samples() File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 270, in pull_samples self._update_clock() File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 242, in _update_clock params = self.query_status_cmd.send([self.oid]) File "/home/klipper/klipper/klippy/mcu.py", line 75, in send return self._do_send([self._cmd.encode(data)], minclock, reqclock) File "/home/klipper/klipper/klippy/mcu.py", line 73, in _do_send raise self._error(str(e)) gcode.CommandError: Unable to obtain 'sensor_bulk_status' response
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "/home/klipper/klipper/klippy/mcu.py", line 71, in _do_send return xh.get_response(cmds, self._cmd_queue, minclock, reqclock) File "/home/klipper/klipper/klippy/serialhdl.py", line 327, in get_response raise error("Unable to obtain '%s' response" % (self.name,)) serialhdl.error: Unable to obtain 'spi_transfer_response' response
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "/home/klipper/klipper/klippy/extras/bulk_sensor.py", line 62, in _stop self.stop_cb() File "/home/klipper/klipper/klippy/extras/adxl345.py", line 289, in _finish_measurements self.set_reg(REG_POWER_CTL, 0x00) File "/home/klipper/klipper/klippy/extras/adxl345.py", line 232, in set_reg stored_val = self.read_reg(reg) File "/home/klipper/klipper/klippy/extras/adxl345.py", line 227, in read_reg params = self.spi.spi_transfer([reg | REG_MOD_READ, 0x00]) File "/home/klipper/klipper/klippy/extras/bus.py", line 98, in spi_transfer return self.spi_transfer_cmd.send([self.oid, data], File "/home/klipper/klipper/klippy/mcu.py", line 75, in send return self._do_send([self._cmd.encode(data)], minclock, reqclock) File "/home/klipper/klipper/klippy/mcu.py", line 73, in _do_send raise self._error(str(e)) gcode.CommandError: Unable to obtain 'spi_transfer_response' response Stats 96146.0: gcodein=0 mcu: mcu_awake=0.117 mcu_task_avg=0.000005 mcu_task_stddev=0.000003 bytes_write=155192 bytes_read=57477 bytes_retransmit=0 bytes_invalid=0 send_seq=4098 receive_seq=4098 retransmit_seq=0 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=168003292 TH0: mcu_awake=0.773 mcu_task_avg=0.000028 mcu_task_stddev=0.000030 bytes_write=10180 bytes_read=549991 bytes_retransmit=0 bytes_invalid=52 send_seq=994 receive_seq=994 retransmit_seq=0 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=12000118 adj=11999845 TH1: mcu_awake=0.002 mcu_task_avg=0.000012 mcu_task_stddev=0.000019 bytes_write=1869 bytes_read=12207 bytes_retransmit=0 bytes_invalid=0 send_seq=225 receive_seq=225 retransmit_seq=0 srtt=0.001 rttvar=0.001 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=12000159 adj=12000072 TH2: mcu_awake=0.002 mcu_task_avg=0.000011 mcu_task_stddev=0.000010 bytes_write=1893 bytes_read=12191 bytes_retransmit=0 bytes_invalid=0 send_seq=226 receive_seq=226 retransmit_seq=0 srtt=0.002 rttvar=0.001 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=64000440 adj=63998868 Arduino_MEGA: mcu_awake=0.068 mcu_task_avg=0.000216 mcu_task_stddev=0.000086 bytes_write=1821 bytes_read=50860 bytes_retransmit=9 bytes_invalid=6 send_seq=190 receive_seq=190 retransmit_seq=2 srtt=0.004 rttvar=0.001 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=15882018 adj=15881703 TH0_temp: temp=35.9 TH1_temp: temp=37.3 TH2_temp: temp=37.7 OrangePi_temp: temp=54.5 Driver_Z0: temp=42.1 Driver_Z1: temp=57.4 Driver_Z2: temp=61.4 Driver_Z3: temp=55.9 Driver_A: temp=54.6 Driver_B: temp=53.3 Motor_Z0: temp=43.2 Motor_Z1: temp=49.7 Motor_Z2: temp=38.2 Motor_Z3: temp=46.6 chamber: temp=31.2 heater_bed: target=60 temp=60.0 pwm=0.000 sysload=0.86 cputime=249.774 memavail=375532 print_time=73.119 buffer_time=1.310 print_stall=0 extruder: target=150 temp=148.5 pwm=0.000 extruder1: target=0 temp=30.5 pwm=0.000 extruder2: target=0 temp=28.9 pwm=0.000 b'stepcompress o=13 i=0 c=6 a=0: Invalid sequence' Exception in flush_handler Traceback (most recent call last): File "/home/klipper/klipper/klippy/toolhead.py", line 435, in _flush_handler self._flush_lookahead() File "/home/klipper/klipper/klippy/toolhead.py", line 365, in _flush_lookahead self.lookahead.flush() File "/home/klipper/klipper/klippy/toolhead.py", line 176, in flush self.toolhead._process_moves(queue[:flush_count]) File "/home/klipper/klipper/klippy/toolhead.py", line 362, in _process_moves self._advance_move_time(next_move_time) File "/home/klipper/klipper/klippy/toolhead.py", line 320, in _advance_move_time self._advance_flush_time(flush_time) File "/home/klipper/klipper/klippy/toolhead.py", line 300, in _advance_flush_time sg(sg_flush_time) File "/home/klipper/klipper/klippy/stepper.py", line 228, in generate_steps raise error("Internal error in stepcompress")`
Additional information and klippy.log
No response
I also have this issue! occurs after running a macro and when its starts to compile the data. Also having issues where it just errors out compiling the csv to png.
11:12:46 PM Error while generating the graphs: index 147 is out of bounds for axis 0 with size 125 None 11:12:45 PM [experimental] Mechanical health: Mechanical issue detected 11:12:45 PM Belts estimated similarity: -94.1% 11:12:43 PM This may take some time (1-3min) klippy (6).log
I ran into this during a few different operations. I reniced klippy to -7, and later put the klippy process into a cpuset sheild, and that seems to keep it safe enough
I ran into this during a few different operations. I reniced klippy to -7, and later put the klippy process into a cpuset sheild, and that seems to keep it safe enough
Mhmm not sure to understand how you did this? Did you directly modify the Klipper files? But thanks for the hint... I'll try to see how I can improve it further. I've already put a new commit in the development branch regarding this issue, which should mostly solve it (avoid joining the file write process and use the klipper reactor instead -> this is what solved the issue for most people on the shake&tune computation process, but I forgot to do it on the CSV file writes as well).
For testing, at runtime:
# Locate` klippy's main pid
% pgrep -fla klippy
1234 /some/path/python klippy.py ...
# Raise priority
% sudo renice -7 -g 1234
# Create cpuset shield, moving everything off of cores 2&3 (leaving cores 0&1 for workloads)
% sudo cset shield -c 2-3
# Move klippy to the 'shielded' CPUs
% sudo cset shield --threads --pid 1234
For a more permanent soloution: Edit klippy systemd service to set nice
# /etc/systemd/klippy.service.d/21-nice.conf
[Service]
Nice=-7
Create/edit systemd dropin to set default cpu affinity Requires a reboot to take effect
# /etc/systemd/system.conf.d/20-affinity.conf
[Manager]
CPUAffinity=0-1
Move klippy service other CPUs Requires restart of klippy to take effect
# /etc/systemd/klippy.service.d/20-affinity.conf
[Service]
CPUAffinity=2-3
Note: My klipper host service is named 'klippy' and not 'klipper' ( 'klipper' is way more common ) Moonraker will also complain about some modifications the unit, so you may need to adjust moonraker.conf to keep it from complaining.
Note that a process cannot decrease it's own "niceness", so setting negative values requires some kind of privileged thing. In this case, it is the service manager.
There are a few differences between the two setups, one uses cpusets, the other affinity, but in this configuration, they should have almost identical effects.
On a 4c cortex a-53, with top at 1.4G, I compiled klipper during an input shaper run, and saw klippy using 60%+ between the two cores, and the compiler ran the other two cores into the wall. This is with the cfs scheduler in default configs. Normally doing this would busy the entire machine enough to run the timers out.
Hello everyone, could you update to v4.0.2 that is now out and let me know if this error is now fixed?
Same error since updating to v4. Happened with 4.0.1, 4.0.2 and now v4.1.0-1-g66f5e32e. Host is a Raspberry Pi Zero 2W...didn't have any problems with this before, made a new cable yesterday, since in the past I had the MCU shutdown when the a previous cable had a loose connector.
During the testing, the CPU is around 35%, RAM between 45% and 70%
I ran into this during a few different operations. I reniced klippy to -7, and later put the klippy process into a cpuset sheild, and that seems to keep it safe enough
this trick didnt worked for me
Renicing didn't work on my setup either. The shutdown doesn't seem to have a clear pattern. Sometimes it occurs between 30-60 hz, sometimes when 120 is reached. Couldn't get one measurement to finish.
I Run my klipper on a Pi4b 8GB. I am also using a Pi cam3. Are you guys using any cameras ?
I have a noname Webcam added, as well as a Fystec Hotkey board, but I removed them both for testing and it didn't change. The only other MCU that is running is the interface for the ADXL345 which is directly connected to the Raspi.
Hello I have the same issue MCU 'mcu' shutdown: Timer too close. I have a Voron 2.4, with Octopus Pro; BTT 2209 (RP2040) CAN Board; BTT PI ; klipperscreen HDMI 5-inch Touchscreen and Beacon. All software and firmware are up to date. Klippain-ShakeTune version v4.1.0-1-g66f5e32e The macro [AXES_MAP_CALIBRATION] and [COMPARE_BELTS_RESPONSES] work well. The macro [AXES_SHAPER_CALIBRATION] works when there are no temperature setpoints. BUT don't work when I setup the bed and hotend to a temperature (exemple 60°) to test when fans are running. I reboot several times and test without the klipperscreen to save power, still same issue. The error appear a the end of the first test.
19:37 MCU 'mcu' shutdown: Timer too close 19:37 MCU 'mcu' shutdown: Timer too close This often indicates the host computer is overloaded. Check for other processes consuming excessive CPU time, high swap usage, disk errors, overheating, unstable voltage, or similar system problems on the host computer. Once the underlying issue is corrected, use the "FIRMWARE_RESTART" command to reset the firmware, reload the config, and restart the host software. Printer is shutdown 19:37 Cleaned up the output folder (only the last 3 results were kept)! 19:37 input shaper graphs created successfully! 19:37 FIRMWARE_RESTART 19:36 Peaks detected on the graph: 1 @ 35.8 Hz (1 above effect threshold) 19:36 -> Recommended shaper is EI @ 33.4 Hz (when using a square corner velocity of 5.0 and a damping ratio of 0.046) 19:36 To avoid too much smoothing with '3hump_ei', suggested max_accel <= 1600 mm/sec^2 19:36 Fitted shaper '3hump_ei' frequency = 49.0 Hz (vibrations = 0.1%, smoothing ~= 0.354) 19:36 To avoid too much smoothing with '2hump_ei', suggested max_accel <= 1600 mm/sec^2 19:36 Fitted shaper '2hump_ei' frequency = 40.0 Hz (vibrations = 0.1%, smoothing ~= 0.345) 19:36 To avoid too much smoothing with 'ei', suggested max_accel <= 2000 mm/sec^2 19:36 Fitted shaper 'ei' frequency = 33.4 Hz (vibrations = 0.1%, smoothing ~= 0.293) 19:36 To avoid too much smoothing with 'mzv', suggested max_accel <= 1700 mm/sec^2 19:36 Fitted shaper 'mzv' frequency = 24.0 Hz (vibrations = 3.6%, smoothing ~= 0.357) 19:36 To avoid too much smoothing with 'zv', suggested max_accel <= 4700 mm/sec^2 19:36 Fitted shaper 'zv' frequency = 34.8 Hz (vibrations = 12.0%, smoothing ~= 0.129) 19:36 This may take some time (1-3min) 19:36 Y axis frequency profile generation... 19:36 Testing frequency: 133 Hz 19:36 Testing frequency: 132 Hz 19:36 Testing frequency: 131 Hz 19:36 Testing frequency: 130 Hz 19:36 Testing frequency: 129 Hz
I am getting the same "timer to close". Running Manta M5P with CB1 on a Ender 5 Pro/Merc 1.1 adxl in EBB42 on tool head. It runs fine for belts and inputshaper. But errors out when trying to create vibrations profile klippy (27).log
Small update. Managed to run through COMPARE_BELTS_RESPONSES without mcu shutdown. I lowered my mycrosteps to reduce the load. lowered from 32 to 16.
Small update. Managed to run through COMPARE_BELTS_RESPONSES without mcu shutdown. I lowered my mycrosteps to reduce the load. lowered from 32 to 16.
All of mine are already at 16 and I got a MCU shutdown about 30 seconds into trying to run it, 3 times in a row. When this current print finishes I will attempt to run it again, If I get a different result I will post it here.
Small update. Managed to run through COMPARE_BELTS_RESPONSES without mcu shutdown. I lowered my mycrosteps to reduce the load. lowered from 32 to 16.
All of mine are already at 16 and I got a MCU shutdown about 30 seconds into trying to run it, 3 times in a row. When this current print finishes I will attempt to run it again, If I get a different result I will post it here.
try 8
ye even with that its still really unreliable. it works 1 time out of 5
Hello everyone, could you update to v4.0.2 that is now out and let me know if this error is now fixed?
I double checked today and I am running 4.1.0 and still having an issue. But only with create_vibrations_profile
Same here on fly-gemini v3, no camera but I have klipper screen and extender connected. Will try w/o later.
Edit: I've experimented with (in my case) \etc\systemd\system\klipper-mcu.service increasing TimeoutStopSec from 10 to 30 and it seems that everything's working.
BTW. I found this post on official klipper forum
A “Timer too close” error occurs when the MCU attempts to schedule a timer for a target time that is in the past. It almost always occurs as a result of a message from the host requesting an action at a time that is now in the past.
I get timer too close sometimes too. FWIW, Manta M8P V2 with CB1. Temperatures stay below ~46C. I have also had issues where the vibrations test (400mm/s, 200mm size, 2500mm/s^2 accel) will usually run fine but I get a timeout error as it's crunching the data after the motion part of the test. I looked for the timeout value in the code but I can't seem to find it. I think it's likely the CB1. I'm thinking it will help... I have a CB2 ordered from BTT but who knows when they'll decide to send it from China. Looks like it's in stock now but they don't seem to be in any hurry to get it boxed up and shipped. :(
I switch from gemini v3 to skr pico + orangepi zero 2, update the 'niceness' following @Laikulo suggestions and it seems to be working now (done about 8 vibration profiles and no issue)
I was getting these errors as well when trying to run this test hot. but found that turning off the heaters was enough to let it complete
Hello all,
I've done a bit of diagnostics on this issue and was able to reproduce it on one of my machines (now equipped with a CB1 that I just bought for the occasion). What I've found is that it happens when the SOC start to get very hot and get above the throttling temperature, which is by default at 60 degrees in the latest Raspbian images I found, but it's also set to 70 degrees sometime on some other images. I think that when the SOC starts to throttle, all cores (and their running process) are slowed down to avoid overheating, this doesn't affect S&T much, but causes problems for Klipper, which expects very precise timing.
So my current solutions that fixed it on my machine are:
- Put a proper heatsink and fan on the Pi/CB1 to prevent it from getting too hot.
- Adding
temp_soft_limit=70(or even a bit higher if needed) to the/boot/configfile to increase the throttling temperature to 70 degrees, as this is still a safe value for the SOC and will avoid too much trouble, especially today as it is summer (at least where I am) and getting over 60 degrees can happen quite easily. - Or as suggested by @fbrzozowski, increase
TimeoutStopSecin the Klipper service, but I would do this as a last resort as this also means that other problematic timer too close errors might be missed...
On my side I'm still looking for a solid solution to reduce the computing power needed for S&T... Or a solution that would avoid throttling the Klipper core and only S&T or... whatever. If anyone here has an idea, I'm totally open!
Also in the meantime, can you monitor closely your Pi temperature when running S&T and when the timer too close errors happens in order to validate this hypothesis?
@Frix-x Hi and thanks for checking this out.
I currently have 2 machines with a Raspi Pi Zero 2 W running the latest version of Klipper and S&T. One is a Voron 0.2R1 with a CAN board on which the Pi is mounted. This one also has active cooling on the Mainboard and the Pi. Here I only get the shutdown sometimes during the calculation at the end after the measurements where taken. So this seems to be fine. Temperature here is never above 55°C. Second one is a Vyper that has been modded to a Switchwire where the Pi Zero 2 W is mounted externally with a USB/Ethernet HAT. Only small heat sinks are possible with this configuration. The case for the combination has as much air flow as possible. Operation temps after hours of printing are around 50 - 55°C. On this machine I can't get a single run completed (since the upgrade to the 4 version), it always shuts down during the frequency measurement. I replaced the cable for the ADXL345 as well for the tool head board. Even on a fresh start of the Raspi.
I'll check the temps on some S&T runs and will set the threshold in the Config.txt as suggested and will get back to you after I did this.
I have had issues with TTC during an extended Vibrations run. Originally with a CB1 but updated to a CB2 on a Manta M8P V2. It's not temperatures for me. I had a heatsink and fan on the CB1 (never exceeded ~45C) and now I have a heatsink and fan on the CB2 (never exceed like 42C). Yet I still got TTC when trying a 600mm/s max 2mm/s step vibration run. It was almost always an SPI_transfer_response error that showed up in the logs. I consistently got these two errors:
Traceback (most recent call last): File "/home/biqu/klipper/klippy/mcu.py", line 71, in _do_send return xh.get_response(cmds, self._cmd_queue, minclock, reqclock) File "/home/biqu/klipper/klippy/serialhdl.py", line 327, in get_response raise error("Unable to obtain '%s' response" % (self.name,)) serialhdl.error: Unable to obtain 'spi_transfer_response' response
and
Traceback (most recent call last): File "/home/biqu/klipper/klippy/extras/bulk_sensor.py", line 62, in _stop self.stop_cb() File "/home/biqu/klipper/klippy/extras/adxl345.py", line 289, in _finish_measurements self.set_reg(REG_POWER_CTL, 0x00) File "/home/biqu/klipper/klippy/extras/adxl345.py", line 232, in set_reg stored_val = self.read_reg(reg) File "/home/biqu/klipper/klippy/extras/adxl345.py", line 227, in read_reg params = self.spi.spi_transfer([reg | REG_MOD_READ, 0x00]) File "/home/biqu/klipper/klippy/extras/bus.py", line 98, in spi_transfer return self.spi_transfer_cmd.send([self.oid, data], File "/home/biqu/klipper/klippy/mcu.py", line 75, in send return self._do_send([self._cmd.encode(data)], minclock, reqclock) File "/home/biqu/klipper/klippy/mcu.py", line 73, in _do_send raise self._error(str(e)) gcode.CommandError: Unable to obtain 'spi_transfer_response' response
I think I found a fix for it though... I looked at the .py files for S&T and tweaked two values which seems to have worked.
In the accelerometer.py, I modified line number 16 to FILE_WRITE_TIMEOUT = 20 # seconds (was 10).
In the create_vibrations_profile.py, I modified line number 82 (maybe not necessary) and 137 to toolhead.dwell(0.75) # was toolhead.dwell(0.3).
Not sure if it was one or both that did the trick. And the values might be too big, though I did still get a TTC with the timeout at 15 and dwell at 0.5. I'm still testing but it seems to work. I think the system needed a bit more time to finish writing/transferring files. I had considered trying to write my first Pull Request, but since you're discussing it here and now, I figured I'd jump in.
Also, on a somewhat related note, I found that I needed to increase the timeout value in [shaketune] timeout: 600
Otherwise it would error out during the graph generation phase.
In my troubleshooting journey, I also messed with the CPU affinity and priority/nice values. That didn't help much at all and I haven't backed out those changes yet. I kinda doubt it will make much of a difference one way or another.
Edit... I spoke too soon. Even with the above settings I just got an SPI error. I'm trying now with an additional toolhead.dwell(0.5) added after each move section. We'll see...