After reading many (very many) messages about home and limit switches I cannot find a solution for this homing issue. On my EshapeOko I installed NC switches and when I setup the TinyG according https://github.com/synthetos/TinyG/wiki/Homing-and-Limits-Setup-and-Troubleshooting#homing-setup-and-configuration, the carriage moves until engaging the homing switch, and then stops, without backoff. I double checked that the min switch goes to min and max to max, disconnected all other limit/home switches from TinyG.
Coolterm reports: {"er":{"fb":438.02,"st":31,"msg":"Move time is NAN"}} followed by
{"er":{"fb":438.02,"st":28,"msg":"Failed to get planner buffer"}}.
The TinyG board info:
[fb] firmware build 438.02
[fv] firmware version 0.97
[hp] hardware platform 1.00
[hv] hardware version 8.00
New machine, or have you used it for a while, without issues?
You might try a $defa=1, to reset all parameters to factory default.
Alas, you will then have to reset all you parameters, but it seems some units have some non-visible (via $$) issues sometimes.
Hi,
because the same issue popped up just a few days ago, and both had a very low latch velocity, I experimented a bit.
Turns out this problem occurs when both the latch velocity $_lv is ridiculously low, and jerk homing $_jh is ridiculously high. It seems this triggers a numeric underflow and tinyg tries to continue with NaN (not a number).
Solution: Set $_lv higher (>= 50) and $_jh lower (< 1000). If the jerk is too high, the machine can't follow anyway without losing steps, and this somehow defeats the purpose of homing to get a *reliable* position.