Z-axis jog function unusable
I've completed installation of a powered table using the z-axis.
Measuring the movement of the table per stepper revolution, I see 1 revolution moves the table about 1 mm. Assuming there are 200 steps per rev (I need to confirm this but it doesn't matter for this report) and as I'm configured for 16 microstepping, that means 3200 steps per mm.
My relevant config is:
Homing works ok taking a few seconds, perfectly reasonable, and of course leaves the table a long way from where it needs to be for use.
The bug is that using the focus buttons. The distance shown on the LCD moves about 2 mm per second, but in actual reality the table moves a fantastically small amount. It's definitely moving at a fairly constant rate but so slow it would take hours to move where it needs to. I timed things and estimate the stepper has moved about 1/4 turn in 1 minute (about 0.25 mm movement of the table).
Looking briefly at the code (sorry, never done C++) it looks like the z-axis is incremented/decremented by the 'speed' variable each loop through LaosMenu::Handle. This is interesting because the similar X/Y movement case inc/decs by 100*speed and maybe is the clue.
Am I on the right track?
#3 Updated by TheGuv over 6 years ago
Thanks, that looks feasible and maybe your firmware results in more stable movement of the z-axis, but the movement is so small it's difficult to tell.
I have noticed though, that movement of the X or Y axis by the movement buttons on the I2C module also results in movement of the z-axis - ironically at a reasonable speed...
#4 Updated by t-oster over 6 years ago
Hi. Somebody I know also told me Z was moving together with X/Y, but I can't find the issue by just looking at the code.
However, I changed the code to use 100*speed as for x/y. Please test http://files.thomas-oster.de/laos-fix-z-jogging.bin
#5 Updated by TheGuv over 6 years ago
I remember that as well but spent the last hour looking for it without success. I seem to remember that it was the order of a bunch of variables that fixed things but can't remember what.
I tested the movement of the z axis when x/y is moving from the buttons some more and the 'Move:' debug output to the serial port shows the z-axis is not incrementing at all while in reality it is physically moving.
I'm beginning to think there may be a runtime issue with variable handling...
Many thanks for the new firmware. The z-axis doesn't seem to move at all from the focus buttons with it though.
#6 Updated by t-oster over 6 years ago
as you see in the commit, I didn't change anything except the speed. So the only thing which I can think of is, that you z-min and z-max is not correct, so it just clips the values.
I remember some weird bugs when initializing variables as:
v1 = v2 = v3 = 0;
when any of those variables correspond to pins. Maybe you look for such variables in the code and just update it to
v1 = 0; v2 = 0; v3 = 0;.
Since I do not have a z-axis, it takes much time if i step by step change the code, send it to you and you test it.
#9 Updated by TheGuv over 6 years ago
I'm stuck now.
Sending a simple job via TFTP that moves just the z axis end to end. I can see with a few additional printf's in plan_buffer_line() that the z-axis remains static, but the z-axis most definitely physically moves. Same with a simple move of the y-axis.
I have no idea really of what's going on, not being a C++ programmer. I'm kinda hoping someone will send the clue bus for me :)