# Persistent Toolhead Swapping Anomaly Counts

**URL:** <https://forum.snapmaker.com/t/persistent-toolhead-swapping-anomaly-counts/42556>\
**Category:** Feature Requests\
**Tags:** pogo-pins, Firmware, U1\
**Created:** [July 17, 2026, 6:56pm UTC](https://forum.snapmaker.com/t/persistent-toolhead-swapping-anomaly-counts/42556 "2026-07-17T18:56:07Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![CrazyIvan](https://avatars.discourse-cdn.com/v4/letter/c/7bcc69/32.png) [@CrazyIvan](https://forum.snapmaker.com/u/CrazyIvan)\
**Post date:** [July 17, 2026, 6:56pm UTC](https://forum.snapmaker.com/t/persistent-toolhead-swapping-anomaly-counts/42556/1 "2026-07-17T18:56:07Z")

</div>

Toolhead Swapping Anomaly counts should be cumulative (user resettable) and accessible on a report screen in _Settings \> Maintenance_ (not just at the end of a print). Personally, I would also like to see per-toolhead retry and failed retry counts, and failed retry counts as a percentage of toolhead pick-ups.

This would enable experienced users to monitor the performance of the pogo pins and take preventative measures in a timely fashion.

---

<div class="post-metadata">

**Author:** ![CrazyIvan](https://avatars.discourse-cdn.com/v4/letter/c/7bcc69/32.png) [@CrazyIvan](https://forum.snapmaker.com/u/CrazyIvan)\
**Post date:** [July 19, 2026, 7:16am UTC](https://forum.snapmaker.com/t/persistent-toolhead-swapping-anomaly-counts/42556/2 "2026-07-19T07:16:43Z")

</div>

> [@Firmware Wishlist](https://forum.snapmaker.com/t/firmware-wishlist/42536/8):
>
> 1. Could be useful for trouble shooting, but could cause some people to panic when not needed too resulting in not needed support requests (knowledge is a dangerous thing in the wrong hands)

Isn’t the “Toolhead Swapper Anomaly” message at the end of a print already doing that (causing user panic)? Getting detailed stats and putting them in context should/might alleviate some of that panic.

I wasn’t panicking, but I was concerned that I could see retries occurring (at the machine and in the Fluidd console) but was not getting anomaly reports (because I did not understand what counts as an anomaly). Proper stats would have resolved that.

Persistent (rather than per-print) stats are necessary for maintenance interventions.