Unload distance metering inconsistency

[ningpj]

HH encoder tracking of load/unload distances appears to be consistently out by approx 38mm with my setup and suspect HH tracking may not be accounting for the same distances/offsets between load and unload. It makes no difference to the operation of the MMU however (Tradrack).

Direction	HH	Binky	Delta	Averages
Load	1182.5	1168.3	14.2	Avg load delta 14.11
Unload	-1180.2	1128.1	52.1	Avg unload delta 53.23
Load	1187.6	1169.3	18.3
Unload	-1182.8	1128.1	54.7
Load	1190.5	1175.1	15.4
Unload	-1184.4	1130	54.4
Load	1189.9	1171.2	18.7
Unload	-1187.1	1135.7	51.4
Load	1194.5	1183.7	10.8
Unload	-1189.1	1136.7	52.4
Load	1189.2	1177	12.2
Unload	-1188.8	1135.7	53.1
Load	1191.7	1176	15.7
Unload	-1188.5	1136.7	51.8
Load	1186.8	1173.1	13.7
Unload	-1185.9	1130.9	55
Load	1182.4	1168.3	14.1
Unload	-1183.9	1130	53.9
Load	1187.4	1175.1	12.3
Unload	-1188.6	1133.8	54.8
Load	1191.6	1178.9	12.7
Unload	-1190	1137.7	52.3
Load	1193.2	1180.8	12.4
Unload	-1191.5	1138.6	52.9
Load	1193.8	1180.8	13
Unload	-1191.8	1139.6	52.2

Variations in distances for the same type of operation (different filament/lanes) are expected, just not the consistent size of the delta between distances reported for load & unload. Running Tradrack with selector filament endstop and binky encoder (v-bearing). Delta seems pretty consistent at lower unload/load speeds as well with unload always reporting a larger gap between what it was asked to unload Vs what the encoder reads. stats captured with 350mm/s & 400 accels for buffer operations

HH v2.5.1-33-gf4673ecb

gate_parking_distance: 17.5 		# Parking postion in the gate (distance back from gate endstop/encoder point)
gate_endstop_to_encoder: 28.0

[moggieuk]

Don't forget that the encoder measurement of unload will exclude the initial tip creation so will be shorter than load (which include the movement inside of the toolhead).

How are you reported the encoder movement? Is it what HH reports in the status or are you pulling from MMU_ENCODER command?

[ningpj]

Yes, quick grep encoder\ measured mmu.log to extract and tidy up in excel after splitting to columns. It’s only cosmetic in this instance and is more important for the load to be accurate. Was using it to track drift and encoder consistency over time with different speeds and encoder vanes. Given it’s consistently out it’s still a useful and valid metric. I also traced and fixed a small mechanical issue with the TR servo horn that appeared to be causing some slippage & larger deltas on unload.

Updated metrics. Delta averages Load: 14.32mm and Unload: 37.40mm over 31 iterations

[moggieuk]

I'll have to study the code again to see what accounts for the difference. As I said there are some moves that don't directly map, e.g. tip creation is an great example where the encoder measured is much larger that aggregate extruder movement. Primarily because the encoder only measures in one direction. In order to make the optics in the status message better I do reset the encoder position if I feel I have a deterministic position.

It is possible that the explicit setting of encoder position misses one type of configuration variation... one I get a moment I'll try a few options to see.

For others reading this, this is purely a cosmetic output rather than a core logic bug.

[ningpj]

No drama. low priority backlog item

[moggieuk]

Still no time to do a deep dive on this, but I will soon :-)