sensorless homing tuning hits other end
How should I tune sensorless homing? Now if I set
SET_TMC_FIELD STEPPER=stepper_x FIELD=SGTHRS VALUE=255 and G28 X0, it will detect stall immeditely and then try to move the the mid point of X carriage, which it now thinks is 150/200/250 mm towards the other end of the rail, and might hit the y extrusions. My question is really that how do I stop the override of G28 that moves the head to the middle. Tried looking at "homing_override", but only found reference to that in config/Ratos/klippy/ratos_homing.py, which seems to get registered in ratos-common.sh. However, this started to get a bit convoluted, and might be I am missing something, so I thought to ask.4 Replies
Yeah you're overcomplicating things. Are you on 2.0 or 2.1?
on 2.1 you select sensorless homing in the configurator and instructions to tune it is in the generated sensorless-homing-*.cfg files next to printer.cfg.
In 2.0 you need to copy the sensorless homing template and tune the threshold and currents in there.
It's literally just tweaking the threshold and current. I usually don't recommend people run sensorless homing because there's no way to automate it. It's trial and error until it happens reliable.
This is on 2.1. I understand that it is trial and error, but with the g28 being overridden/expanded such that it moves the head to the middle makes the trial a bit difficult and dangerous, since the move-to-middle is done with full current (not the reduced homing current) and this move can hit the right side y extrusion. And this is why I’d like to be able to run just the klipper original g28, the one without return-to-center. However…. and this is strange.. even if I select sensorless with the configurator, the homing still honors the physical switches. The config is at least partially correct, since the homing current gets lowered ( which I do not think happens with the sensors), but then the homing fails unless the physical switch gets triggered
So, two separate issues: 1) how to run native g28, and 2) how to make sensorless … well … sensorless.
This is on 2.1. I understand that it is trial and error, but with the g28 being overridden/expanded such that it moves the head to the middle makes the trial a bit difficult and dangerous, since the move-to-middle is done with full current (not the reduced homing current) and this move can hit the right side y extrusionThere's no danger here. Motors will just skip. You didn't enable performance mode without making your printer actually work first, did you?
even if I select sensorless with the configurator, the homing still honors the physical switches.It definitely doesn't, klipper does not have the functionality to do that, it's either or. If you have physical switches on there, what are you doing with sensorless homing? Sensorless homing should be a last resort.
The config is at least partially correct, since the homing current gets lowered ( which I do not think happens with the sensors), but then the homing fails unless the physical switch gets triggeredOooh. You didn't set they diag pin jumpers correctly, did you? 😄 you can override
gcode on [ratos_homing] although there's really no reason to. Sensorless homing requires it own set of macros, it doesn't work with klipper out of the box.This is going to be tl;dr, but it seems I have a bit of defending to do :). I did verify the workings of the printer before enabling performance mode, but that was with mechanical switches. Then I did IS tuning and found an anomaly at 65 Hz. Found that x switch rattles, so I wanted to get rid of. Turned on sensorless homing, checked diag pins (but could have made errors, I am human, believe it or not), and followed the instructions in Ratos and klipper for tuning the sensorless homing. Those instructions include setting the threshold low and doing g28. Did that, which resulted in the head travelling to the right side of the gantry with full current. Yes, at this stage I had not removed the performance mode, something a more experienced operator might have done. But in my defense that was not part of the instructions. Anyway, whether banging with full current to the rails os dangerous or not is debatable: I spent an inordinate amount of time tuning the belt tensions and the gantry squareness, and I am not sure how the tuning will survive the collision. So, I have the switches there, i want to make sensorless working before I physically remove them. Does that in any way make my wreckless behavioir understandable. I am not trying to make it sound acceptable, but just understandable, i.e. there is some logic behind my actions,
I’f say the need to modify the G28 functinality is a matter of opinion. Of course it is not absolutely needed, few things are; after all some people do not even pay taxes. However, when tuning tuning sensorless homing, IMHO it is easier and less of a surprise to have the head stop after a detected stall, and not have it start a move to what the printer now thinks is the mid of the gantry.
I am aware that need you a macro/override to lower the current during homing, and I do not want to change the g28 functionality permanently, but just for the time I tune sensorless homing.
An even easier way would be to call the klipper-original non-overridden g28 during tuning, but I do not yet know what it is called now in Ratos.
Anyway, the strange situation that I seem to have now is that while I have configured sensorless, the homing really (yes, really) reacts to the mechanical switches. I verified this by setting both x and y sensorless and homing y. Homing stops when I close the y switch, without touching the gantry, after which the gantry gets returned to the now-incorrect center position. So, something is off, I will debug further. And re-check the diag pins 🙂
Yep, it is those diag pins, made an error there