[solved!] Smoothieboard becomes unresponsive after G28 (both USB or RJ45) ---> default config requires a Z axis!

My board becomes totally unresponsive after a G28 (homing). I cannot even get a M119 or “Motors Off” to work after that. Both in USB or Ethernet, the link is down to the point only a reset works. Note that the <axis>_limit_enable are commented out by default in the config (but I tried to set them to false to make sure, in vain).

Strangely, it does work when I issue a G28 Y0 followed by G28 X0. It works also when I send a G28 X Y (but then I do not get my required Y-then-X order of course!).

My printer has no Z nor Z stops for now, so I could understand that the default G28 fails (still, I would expect a timeout from the printer instead, if it cannot home Z!?). But even after I changed homing sequence from YXZ to YX, it will never finish G28! I am simply stuck with the need to use two separate G28 Y then G28 X. Why?

(Also, I am pretty sure I was able to get bare G28 to work when we installed the 2 homing microswitches 3 weeks ago on another prototype, because it was the time we determined we had to user YXZ sequence order. So what? Floating input pins for the respective axes?)

Nb: with the web interface I tried to upload a 2.8MB gcode file after such a G28 “freeze”, but progress is stuck at (0%) and I have no way I can cancel it. No feedback after ~1 minute so I rebooted. But surprisingly, the SD card did save the first ~6KB of the file, so was the board really stuck?

Imported from wikidot

Solved…

I had to rewrite “nc” to the respective end stop for gamma axis. It makes sense! My bad
(still I don’t get it how we managed to test the homing weeks ago)