Changed out my skr for jackpot yesterday
did X than Y test
X and Y move and home smoothly and at about same speed as the skr does
the Z up and down moves are at good pace, but when press Z home it flies to the top and hits the stops with force , picking this isn’t normal
xy says 1000mm/m
z say 100mm/m
in box below jog control
I changed z movement from 100 down to 50 mm/m, it slowed jog speed but home is still at warp 9, the force it hits stops is crazy
if i was to take a guess id say its travelling about 1500mm/m to Z home
i changed xy speeds to 500 tha 1500 , to see if their homing speeds changed and they did correspond with the numbers i tried
That only affects the jog speed using the WebUI controls. Homing speed is based on the config.
The setting /axes/z/homing/seek_mm_per_min is the speed at which it homes for the first contact. The default Lowrider config has this set to 800. Mine is set to 1500 and works fine.
The setting /axes/z/homing/feed_mm_per_min is the speed for the second, more accurate contact. The default Lowrider config has this set to 200. Mine is set to 300. http://wiki.fluidnc.com/en/config/axes#homing
Based on that last image, it looks like it was able to home Z successfully?
since i wrote the initial post haven’t turned it back on till today, and today its homing a lot slower now about same as what the skr was not longer slamming into z stop , so not sure why it was going heaps faster on initial start up, maybe its sorted itself out haha
Hmm, yea that’s odd. I saw a post recently where it had odd behavior if you opened the WebUI immediately while the Jackpot was still initializing. XY are in the config first. Maybe you loaded the WebUI before it initialized the Z configuration. Just a guess. If it happens again, power cycle and give it maybe 15 to 30 seconds before opening the WebUI. That’s the only thing that makes any sense. This wouldn’t be a wiring issue or anything like that.
Also, Ryan was asking version. You have 3.9.1 which is the current recommended version so all good there.
