Z stepper microstep shift on multi-mcu homing / loadcell / ldc1612

For what it is worth, I’m confused about the different variations you are running. I think we’ll need to identify the exact code you are running before I can give insights on why you did not get expected results.

I am not, but it would be unusual for a neopixel (or similar) update to occur during homing.

IRQs definitely need to be disabled prior to calling that function (either via explicit irq_disable() calls or via irq_save() ).

No, tasks can’t interrupt timers. If a task calls irq_disable() (directly or via irq_save() ) then it can delay future timers, but a task can not inject its actions between timers. As mentioned before, it is possible for the timer scheduler to yield between timers if the machine is overloaded, but the most recent sched.c patch should have made that less likely.

Maybe there is something in the loadcell code - it’s hard for me to say without knowing that code well. I don’t see anything in the mainline sensor_hx71x.c code that could cause an issue - there are irq_disable() calls, but the total time spent in the mainline hx71x_capture_task task should be well under 50us per sample, which should be fine. Task time usage isn’t generally an issue unless multiple milliseconds are spent in a single task.

Cheers,
-Kevin

You patch works fine!

Sorry, PEBKAC… I didn’t add the IRQ fence to my code when I tested the sched.c patch. I’m on-call this week and my brain is probably 5 other places and I got 4 hours of sleep when I tried to test this.

sensor_ldc1612.c needs to have similar IRQ guards added.

1 Like

Eeks! I’ll put together a fix.

Thanks.
-Kevin

The only place trsync_do_trigger() appeared originally is in endstop.c where there is no guard because its inside the timer callback. But I think after this and the load cell code it will be pretty clear what usage should look like.

I have created PR #6717 and PR #6718 for the changes discussed above.

-Kevin

1 Like

Tested both PRs and they work as intended.

FYI, I committed those two PRs.

In accordance with those PRs, the mainline Klipper code will now warn if it detects stepper motors getting out of sync after a probe attempt. If one sees a log message like Stepper 'stepper_z1' position skew after probe: pos -200631 now -200630 it is a result of this new check. If you do get the message, make sure your micro-controllers are flashed to the lasted version of the code. If they are on the latest version of the code, please open a report on Klipper Discourse and be sure to attach the full Klipper log.

Cheers,
-Kevin

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.